Steve Egge: dynamic languages are back
The notorious Steve Egge published a transcript of his report at Stanford University. He touched upon a number of issues that were recently actively discussed at Habré: optimization of program code, "non-traditional" programming languages, etc. In addition, for those who are "in the subject," the report contains links to interesting publications on compilation and optimization methods.
Below I tried to make a squeeze of a very voluminous text. Places with deliberately provocative, in the spirit of Steve, statements.
')
It is believed that:
We will try to refute these statements.
History knows examples of very good optimizing compilers for dynamic languages: Common LISP, Strongtalk (Smalltalk extension with optional static typing), Scheme, Self. Nobody uses them, they are not known to anyone. No matter how good the idea and even the implementation, without marketing it means nothing.
Small teams of researchers achieved a ten-fold increase in speed from their prototype compilers. At the same time, Sun spent ten years at HotSpot VM. No one knows how fast dynamic languages can be if they are seriously addressed.
Inertia is too great: a lot of money is invested in marketing. No enthusiast can push through using LISP or Haskell, or Erlang in a corporation. Millions of programmers around the world do not intend to learn a second language. As a result, in the foreseeable future we have to be content with what we have. This is very sad, but this will have to accept.
Favorite argument of opponents of dynamic languages:
- You can not rename the method in the IDE!
- Given that this opportunity first appeared in the Smalltalk environment, no problem.
- But he will miss something!
- Java IDE is not less often wrong: they can not always look into XML configuration files, in SQL, in reflection lines, etc.
Development environment for dynamic languages, including with support for refactoring, is no more difficult to make than for statically typed ones.
The code in dynamic languages is not always dynamic in its essence. In most cases, static analysis is possible, and simulating the execution of the code allows for even more accuracy.
Programmers like to do micro-optimizations, because it requires less mental effort than working through the architecture.
It is necessary to understand how the system works as a whole. Small systems are not just easier to optimize - only they can be optimized for real. So most performance talks are nonsense. The main thing is the size of the system.
How, nevertheless, can accelerate dynamic languages?
Increasing the complexity of client applications in Javascript will result in it becoming one of the fastest languages. Seriously.
That's what happened: with this AJAX revolution, the industry began to seriously try to optimize Javascript. And this was the impetus for serious shifts in research on the optimization of dynamic languages.
Optimizing dynamic languages is cool again. This is the main conclusion of this report. Cool in the sense that you can get venture capital investments and research grants. Cool in the sense that it will help those who write Mario clones in Javascript.
If you understand programming languages and compilers, go for it. There is plenty of work in this area, including one that no one has yet reached.
I am pleased to accept comments and suggestions on what else can be included from the original report. It would be great to translate the whole thing, but more than 70 thousand characters - for me personally, this is work for a week at least.
Below I tried to make a squeeze of a very voluminous text. Places with deliberately provocative, in the spirit of Steve, statements.
')
It is believed that:
- Dynamic languages are slow in nature.
- For them, you can not create a normal development environment.
- Large (millions of lines) projects in dynamic languages are difficult to maintain.
We will try to refute these statements.
Marketing
History knows examples of very good optimizing compilers for dynamic languages: Common LISP, Strongtalk (Smalltalk extension with optional static typing), Scheme, Self. Nobody uses them, they are not known to anyone. No matter how good the idea and even the implementation, without marketing it means nothing.
Small teams of researchers achieved a ten-fold increase in speed from their prototype compilers. At the same time, Sun spent ten years at HotSpot VM. No one knows how fast dynamic languages can be if they are seriously addressed.
Languages will no longer change every 10 years.
Inertia is too great: a lot of money is invested in marketing. No enthusiast can push through using LISP or Haskell, or Erlang in a corporation. Millions of programmers around the world do not intend to learn a second language. As a result, in the foreseeable future we have to be content with what we have. This is very sad, but this will have to accept.
Development environments
Favorite argument of opponents of dynamic languages:
- You can not rename the method in the IDE!
- Given that this opportunity first appeared in the Smalltalk environment, no problem.
- But he will miss something!
- Java IDE is not less often wrong: they can not always look into XML configuration files, in SQL, in reflection lines, etc.
Development environment for dynamic languages, including with support for refactoring, is no more difficult to make than for statically typed ones.
The code in dynamic languages is not always dynamic in its essence. In most cases, static analysis is possible, and simulating the execution of the code allows for even more accuracy.
Performance
Programmers like to do micro-optimizations, because it requires less mental effort than working through the architecture.
After graduating from the University of Washington, I worked for Geoworks. For five years, I wrote in assembly language. In Geoworks, we wrote the whole operating system, libraries, drivers, applications - in general, the whole desktop operating system in 8086 assembler! [...]
We even liked it to some extent. We had Object Oriented Assembler. [...] We knew that we could overtake any compiler - because then we really could.
What happened? Geoworks went bankrupt. Why? I’ll probably say something that no former employee of this company agrees with, I am the only one who believes in it. Because we wrote fifteen million lines in assembler 8086. We had great tools, some of the best in the world, believe me. But at some point ...
It is necessary to understand how the system works as a whole. Small systems are not just easier to optimize - only they can be optimized for real. So most performance talks are nonsense. The main thing is the size of the system.
How, nevertheless, can accelerate dynamic languages?
- Language improvements: optional static typing, concurrency support.
None of the currently popular dynamic languages has normal capabilities for creating scalable applications. Flows in them work in such a way that it is better not to use them in real tasks. - Virtual machine improvements: generational garbage collector, asynchronous I / O ...
- Advanced compilers.
Javascript
Increasing the complexity of client applications in Javascript will result in it becoming one of the fastest languages. Seriously.
That's what happened: with this AJAX revolution, the industry began to seriously try to optimize Javascript. And this was the impetus for serious shifts in research on the optimization of dynamic languages.
Optimizing dynamic languages is cool again. This is the main conclusion of this report. Cool in the sense that you can get venture capital investments and research grants. Cool in the sense that it will help those who write Mario clones in Javascript.
If you understand programming languages and compilers, go for it. There is plenty of work in this area, including one that no one has yet reached.
I am pleased to accept comments and suggestions on what else can be included from the original report. It would be great to translate the whole thing, but more than 70 thousand characters - for me personally, this is work for a week at least.
Source: https://habr.com/ru/post/31557/
All Articles