开发者

(strongly vs weakly) typed AND (statically vs dynamically) typed languages and Moore's law [closed]

开发者 https://www.devze.com 2022-12-08 18:18 出处:网络
Closed. This question is off-topic. It is not currently accepting answers. Want to improve this question? Update the questi开发者_高级运维on so it's on-topic for Stack Overflow.
Closed. This question is off-topic. It is not currently accepting answers.

Want to improve this question? Update the questi开发者_高级运维on so it's on-topic for Stack Overflow.

Closed 9 years ago.

Improve this question

I do not know how many faces this problem. If I do programming in weakly/dynamically typed language like python,php,javascript for few days I lose touch with strongly typed languages like c++,Java,.net. I recently heard languages like python and ruby which people loved programming in.

It is very easy programming in weakly/dynamically typed languages, but there is a danger of losing touch with languages like c++,Java. Processors now becoming very powerful and according to Moore's law it will increase speed with time exponentially. So efficiency may not be issue as similar thing happened when we shifted from embedded to high level languages like c++,java.

  • So is the world shifting toward weakly/dynamically typed languages?
  • Will the weakly/dynamically typed languages replace strongly typed languages in future?
  • Are there any fields in which strongly typed language is a must use and cannot be replaced current time as well as near future?


First, Moore's law is only an empirical observation. Sooner or later, the laws of physics will mean that it is no longer possible to keep increase uniprocessor speed. Moore's law is not a useful predictor of the future in the medium to long term, and possibly not even in the short term.

Second, strongly and weakly typed languages are EQUALLY affected by Moores law.

Third, Moore's law is about uniprocessors. We're well into a world where increases in raw computing power are coming through multi-processing, but there aren't the software tools (e.g. languages) around yet that help the average Joe programmer to write programs that take advantage of multi-processing. However, functional languages offer more promise in this area than procedural ones.

Fourth, I think you are really comparing statically typed versus dynamically typed languages. (The terms "strongly typed" and "weakly typed" have become so confused due to conflicting definitions that they are no longer meaningful.)

I guess your argument is that Moore's law means that efficiency matters less, so we can "get away with" using less efficient computation paradigms; e.g. dynamically typed languages. (And if we are talking about interactive tasks, the computer only needs to keep up with the user's speed of asking for things and mentally processing the answers.)

The flip side of that argument is that people are wanting their computers to do more compute intensive things; e.g. each generation of computer games requires more power to do the graphics. Online business wants to do more things (e.g. serve more web requests) faster with hardware that is cheaper to run. In short, there are lots of situations where efficiency does matter, and this will always be the case.

So what you find is that in places where speeds is important, we tend to use efficient computing techniques, and where it is unimportant we use techniques that minimize software development and maintenance costs.


UPDATE

On rereading my answer, I missed something. If we taken it as read that Moores law is breaking down, and that future increases in computing "power" will come in the form of more cores, etcetera, then there will be an increasing role for functional languages.

Anyone who has tried to exploit parallelism in an imperative or OO language will recognize that it is a tricky problem, fraught with pitfalls. By contrast, in a pure functional language, parallelism is much simpler. Since the state of data structures doesn't change, you don't need to worry about threads synchronizing over the use of the data structures. Furthermore, it is simpler for the compiler or runtime system of the language to spot that a particular part of your program could be done in parallel ... and just do it. Or at a higher level, the FP language IDE (or whatever) could find / suggest opportunities for large scale transformations to aid parallel execution.

IMO, this is what is behind the (slow) rise in popularity of functional languages ...


Moore's law is in danger, as the processor speeds can't speed up at the moment, so they just put more cores on each die (more processors/processor chip).

Which is why functional programming is becoming popular again.

If you are working in critical environments, such as a nuclear power plant, or avionics on airplanes, a weakly typed language won't be used, as it can't meet the requirements imposed by these areas.

The world continues to move toward the language or framework that best solves the problem. Some people may try to force using a particular language, but, over time, if it is seen that there is a better language for that problem, the migration will be toward the better language.

It is important to understand both though, I believe, as there are areas where a weakly typed language works best, for example, having javascript applications, where you can send code as data, then execute it. That can be very powerful.

Strongly typed languages will remain the primary language for enterprise apps, as the compiler can help determine if there are errors due to a mismatch of data types that are hard to troubleshoot in weakly typed languages.


You are correct that compilers for statically typed languages can do optimizations to execute faster. But efficiency in executing the software is not the only concern in static vs dynamically typed languages.

The compiler does a lot of checking for you in statically typed languages that you have to do with unit tests (or other run-time techniques) in dynamically typed languages.

Because the type of an object must be known at all times IDEs can provide powerful refactoring and "auto completion" features. This saves a lot of developer time in refactoring or navigating bigger code bases.

It is not clear in which way the scales will tip. To make things even more interesting, there are some statically typed languages (have a look at scala) that do type inferencing. This makes statically typed languages become almost as concise as their dynamically typed brothers.

Static languages will probably not be "replaced" by dynamic languages. There will be a mixture depending on the domain.


Python is actually not weakly typed, it's just dynamically typed. Computer programming languages will continue to evolve and come in a variety of flavors. I think there will always be a demand for strong typing, but also dynamic typing.


Moore's Law is not an axiom. I.e. you can't be sure whether it will hold true next week.

Further I don't think your choice of strongly/weakly typed languages should depend on Moore's law or processor speed. I think you should be thinking about where you want to apply what you've learnt.

Better think about some of these factors which should matter more than Moore's law to you:

  • Will you find gainful employment working in the language you've chosen.
  • What are the prospects of growth.
  • Can you make what you plan/want to make in the language you've chosen.
  • How much documentation/community help is available for it.

Processor's are already fast enough to make it matter very little whether you choose Ruby or Java.

That said I think it would probably be a good idea to keep one leg on each side of the divide. It is indeed possible and recommended for one programmer to learn multiple languages. :)


Just a little note, I've noticed the same thing. I came from a C++ background, so stepping into Python was very different. However, I've started to realize that while there are many benefits to strongly/statically typed languages, they are much slower in development than more dynamic languages. There are situations where static & performance-oriented languages are still desirable, but for most projects the goal is to solve a problem.

If you have a problem that can be adequately and appropriately solved in a short amount of time with Python, and if it takes you less time to create that solution in Python, then there are compelling arguments to just stick with that. As programmer's we tend to try to optimize and worry about performance at every step. However, with the 80/20 rule it makes more sense to make something work, then tweak the parts that need it most until performance is good.

If I were writing software for an embedded device, then I'd stick with lower-level performance oriented languages. However, if I'm writing a image resizing service that will be run sparingly on a web server, I'll write it the highest-level language I have until I have a compelling reason to optimize it. What I've realized is that while I have tons of ideas on how to optimize code for better performance, often that work would be completely unnoticeable and therefore be a waste of time. The only difference is that my code would be marginally faster in places that don't matter, and the bill to my employer (or client) would be much faster. A simplification would be that cpu's are cheap, but programmer-hours are expensive.

So yes, I think languages that promote RAD-style development will be more popular and useful than older lower-level languages, with good reason. Not for all situations, but definitely for a lot of them.

0

精彩评论

暂无评论...
验证码 换一张
取 消