Dynamic Languages Strike Back
steve-yegge.blogspot.com
steve-yegge.blogspot.com
The Smalltalk Refactoring browser is still very impressive, though it has now been surpassed by Eclipse. It predated Eclipse by some years, however. There are other tools that were developed under Smalltalk that have yet to be adopted by other programming communities. Also, the performance of the fastest Smalltalk VMs has been very good for many years now. Bad architecture will swamp even programs in C or assembly. I'd hazard a guess that you were dealing with that.
But you are correct that there are serious problems with many of the Smalltalk implementations. None of these had anything to do with the language, the tools, or the VMs. Rather, there was a legacy of "ivory tower" mentality. Instead of doing very necessary but unglamorous things like polishing the GUI framework (and eliminating race conditions) implementors preferred to do cool things like create new garbage collection options.
Smalltalk suffered because community input was neglected, because the same community fostered an elitist culture, because marketing went for an more closed "boutique" approach, and because implementations weren't polished to true professional standards. It would behoove Ruby, Python, and others to heed these lessons. (And I'd note that they've done many things right.)
He only briefly alluded to it (80% politics, 20% technology), but like so much else that is discussed in terms of tools and technologies, this is a people problem. It's depressing, really.
That's exactly what I want to hear! Let them keep their 600+ page C# spec and their 10+ year java resume - leaves more opportunity for people are willing to "take the risk" and pick the best tools.
Seriously, google "Alt.NET". They're people whose toolchain is not 100% Microsoft, and they're outcasts.
Right now we have 20 years worth of legacy code in ADA. We have a legal obligation to maintain a large percentage of that code to 2075. Our demand for programmers in this location is such that essentially we run training schools to meet demand and would have to do the same in any language.
What _possible_ advantage would there be in moving to a new language for new projects? Before the life cycle is up any new toy would be old and rusty. We have to train programmers anyway. Supporting two languages would double the overhead. Our existing skill base is productive in ADA. Real Software Engineering is only 5% programming at most.
This is of course a bit of an extreme example - but it serves to illustrate the point that in the continuum there will be plenty of companies on the 'don't move' side of the equation, where it is far more profitable to stay with what they already know, at least for now.
Python and Ruby are doing tons of things right on the social/cultural side, but the technology was in many ways a big step backwards from Smalltalk and Lisp. The poor performance serves to reinforce the old dynamic language stereotypes.
Pretty weak argument against type inference. Yegge has used OCaml so i expected better arguments.
And JavaScript 2 is getting type annotations, so the trend is more likely in the other direction to improve performance.
"Rule #2" for what NBL requires is "Dynamic typing with optional static types."
> "... and so all this stuff about having a type-tag saying this is an int – which might not actually be technically correct, if you're going to overflow into a Double, right? Or maybe you're using an int but what you're really using is a byte's worth of it, you know. The runtime can actually figure things out around bounds that are undecidable at compile time."
I got the distinct impression that he wasn't arguing against type inference, merely said that the classic way to do it doesn't always work with dynamic languages, and there are better (newer) ideas regarding how to infer types without resorting to type tags.
A friend of mine implemented some Block Cipher algorithms in Smalltalk a few years back. By working with the VM engineers so he could have a few things (like 32 bit registers with bit-shift and bit-rotate operations) he managed to come close to or BEAT RSA Data Security's reference implementations in C. In once case, the algorithm was 3% faster. (RSA's implementations used malloc/free in a naive way. Great generational GC in Smalltalk was like a custom buffer cache implemented for free.)
A company I worked for once has two Smalltalk implementations. Some work was done to host one inside the runtime of another. The hosted Smalltalk has a compiler written using Yacc & Lex which was compiled C. The host Smalltalk has one written entirely in Smalltalk. It was discovered, that if you took the text notifications out of the Smalltalk Smalltalk compiler, it runs faster than the C Smalltalk compiler.
It's not even limited to dynamic lanaguages. I sometimes find myself defending static languages like Java. Java got a bad rap for being slow... but actually, it’s a lot better these days than it used to be.
Get the facts people!
http://whydoeseverythingsuck.com/2008/05/blaine-cook-writes-...
Thats a bit like a lecture from a physicist confusing gravity and time (unless of course they are talking about inverted universes, maybe a black hole or something).
I threw that last one in just to make sure I was illustrating the point and not trying to be historically accurate or trying to predict the future.
"C is really fast, because among other things, the compiler can inline function calls. It's gonna use some heuristics, so it doesn't get too much code bloat, but if it sees a function call, it can inline it: it patches it right in, ok, because it knows the address at link time."
This statement shows that Steve has no idea how the base of every modern OS works: separate compilation, calling conventions, machine code, shared objects (libraries), etc.
Once I compile a .c file which defines a function into object code, there is no practical way for the linker to "patches it right in" -- that would require actually decompiling the function to get rid of the calling convention implementation as well as tie-in all the argument references in the function body to those in the calling code.
I noticed something similar a while ago in one of his posts about Lisp (I think it was about why Lisp is not an acceptable Lisp). There he made pretty strong statements and when people who actually know and have used Lisp in real world pointed to his numerous mistakes in comments, Steve admitted that he actually doesn't know the subject matter very well.
Like:
int square(int x) {
return x*x;
}
int sum_of_squares(int x, int y) {
return square(x)+square(y);
}
int sum_of_squares(int x, int y) {
return x*x + y*y;
}
Inlining in the same translation unit is possible though its application is too limited to explain why C is faster than dynamically-typed languages.