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. :)
如果我正在为嵌入式设备编写软件，那么我会坚持使用较低级别的面向性能的语言。但是，如果我正在编写一个在 Web 服务器上少量运行的图像调整大小服务，我将使用我拥有的最高级别的语言编写它，直到我有充分的理由来优化它。我意识到，虽然我对如何优化代码以获得更好的性能有很多想法，但通常这些工作是完全不引人注目的，因此是浪费时间。唯一的区别是，我的代码在无关紧要的地方会稍微快一些，而且给我的雇主（或客户）的账单会快得多。简单地说，CPU 很便宜，但程序员的时间很昂贵。
所以，是的，我认为促进 RAD 风格开发的语言将比旧的低级语言更流行和有用，这是有充分理由的。并不适合所有情况，但绝对适合其中的很多情况。
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.
发布评论
评论（6）
首先，摩尔定律只是一个经验观察。迟早，物理定律将意味着不再可能继续提高单处理器速度。从中长期来看，摩尔定律并不是对未来的有用预测，甚至在短期内也可能不是。
其次，强类型语言和弱类型语言同样受到摩尔定律的影响。
第三，摩尔定律是关于单处理器的。我们已经进入了一个通过多处理来提高原始计算能力的世界，但是还没有软件工具（例如语言）可以帮助普通程序员编写利用多处理的程序。然而，函数式语言在这个领域比过程式语言提供了更多的前景。
第四，我认为您实际上是在比较静态类型与动态类型语言。 （“强类型”和“弱类型”这两个术语由于相互冲突的定义而变得如此混乱，以至于它们不再有意义。）
我猜你的论点是摩尔定律意味着效率不那么重要，所以我们可以“侥幸逃脱”使用效率较低的计算范例；例如动态类型语言。 （如果我们谈论的是交互式任务，计算机只需要跟上用户询问事物并在心理上处理答案的速度。）
该论点的另一面是，人们希望他们的计算机执行更多的计算密集型工作事物;例如，每一代计算机游戏都需要更多的能力来处理图形。在线业务希望使用运行成本更低的硬件更快地完成更多任务（例如，服务更多网络请求）。简而言之，在很多情况下效率确实很重要，而且情况永远如此。
所以你会发现，在速度很重要的地方，我们倾向于使用高效的计算技术，而在速度不重要的地方，我们使用最小化软件开发和维护成本的技术。
更新
在重读我的答案时，我错过了一些东西。如果我们认为摩尔定律正在被打破，并且未来计算“能力”的增加将以更多内核等形式出现，那么函数式语言的作用将会越来越大。
任何尝试在命令式或面向对象语言中利用并行性的人都会认识到这是一个棘手的问题，充满了陷阱。相比之下，在纯函数式语言中，并行性要简单得多。由于数据结构的状态不会改变，因此您无需担心线程在数据结构的使用上同步。此外，对于该语言的编译器或运行时系统来说，更容易发现程序的特定部分可以并行完成......然后就可以执行它。或者在更高的层面上，FP 语言 IDE（或其他）可以找到/建议大规模转换的机会，以帮助并行执行。
IMO，这就是函数式语言（缓慢）流行的背后原因......
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 ...
摩尔定律正处于危险之中，因为处理器速度目前无法加快，因此他们只是在每个芯片上放置更多核心（更多处理器/处理器芯片）。
这就是函数式编程再次流行的原因。
如果您在关键环境中工作，例如核电站或飞机上的航空电子设备，则不会使用弱类型语言，因为它无法满足这些领域的要求。
世界继续朝着最能解决问题的语言或框架发展。有些人可能会尝试强制使用某种特定的语言，但是，随着时间的推移，如果发现有更好的语言可以解决该问题，那么迁移就会转向更好的语言。
不过，我认为理解两者很重要，因为弱类型语言在某些领域效果最好，例如，在 JavaScript 应用程序中，您可以将代码作为数据发送，然后执行它。这可能非常强大。
强类型语言仍将是企业应用程序的主要语言，因为编译器可以帮助确定是否存在由于数据类型不匹配而导致的错误，而这些错误在弱类型语言中很难排除。
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.
您是正确的，静态类型语言的编译器可以进行优化以加快执行速度。但执行软件的效率并不是静态类型语言与动态类型语言唯一关心的问题。
编译器会在静态类型语言中为您执行大量检查，这些检查必须在动态类型语言中进行单元测试（或其他运行时技术）。
因为必须始终知道对象的类型，所以 IDE 可以提供强大的重构和“自动完成”功能。这可以节省开发人员在重构或浏览更大代码库时的大量时间。
目前尚不清楚天平将向何种方向倾斜。为了让事情变得更有趣，有一些静态类型语言（看看 scala）进行类型推断。这使得静态类型语言变得几乎和它们的动态类型语言一样简洁。
静态语言可能不会被动态语言“取代”。根据域的不同，会有混合。
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 实际上不是弱类型，它只是动态类型。计算机编程语言将继续发展并呈现出多种风格。我认为总会有对强类型的需求，但也有动态类型的需求。
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.
摩尔定律不是一个公理。也就是说，您无法确定下周它是否会成立。
此外，我认为您对强/弱类型语言的选择不应取决于摩尔定律或处理器速度。我认为你应该考虑一下你想在哪里应用你所学到的知识。
最好考虑一下其中一些对您来说比摩尔定律更重要的因素：
处理器的速度已经足够快，因此无论您选择 Ruby 还是 Java 都无关紧要。
也就是说，我认为在分水岭的每一侧都保留一条腿可能是个好主意。一名程序员学习多种语言确实是可能的，也是值得推荐的。 :)
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:
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. :)
只是一个小注释，我也注意到了同样的事情。我有 C++ 背景，所以进入 Python 是非常不同的。然而，我开始意识到，虽然强/静态类型语言有很多好处，但它们的开发速度比动态语言要慢得多。存在静态和静态的情况。面向性能的语言仍然是可取的，但对于大多数项目来说，目标是解决问题。
如果你有一个问题可以在短时间内用 Python 得到充分、适当的解决，并且如果你用 Python 创建该解决方案所需的时间更少，那么就有令人信服的理由坚持下去。作为程序员，我们倾向于尝试优化并担心每一步的性能。然而，根据 80/20 规则，让某些东西发挥作用，然后调整最需要它的部分，直到性能良好为止更有意义。
如果我正在为嵌入式设备编写软件，那么我会坚持使用较低级别的面向性能的语言。但是，如果我正在编写一个在 Web 服务器上少量运行的图像调整大小服务，我将使用我拥有的最高级别的语言编写它，直到我有充分的理由来优化它。我意识到，虽然我对如何优化代码以获得更好的性能有很多想法，但通常这些工作是完全不引人注目的，因此是浪费时间。唯一的区别是，我的代码在无关紧要的地方会稍微快一些，而且给我的雇主（或客户）的账单会快得多。简单地说，CPU 很便宜，但程序员的时间很昂贵。
所以，是的，我认为促进 RAD 风格开发的语言将比旧的低级语言更流行和有用，这是有充分理由的。并不适合所有情况，但绝对适合其中的很多情况。
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.