When you don't know what you don't know...
I see that Cedric Beust still doesn't know what he doesn't know. Here's a link to his recent presentation on language trends (PDF); reading through it, it's clear that he still has no idea what he's talking about with respect to dynamic languages. He fears them, that much is clear - here's a snippet from one of the later slides in his talk, explaining a "problem" with dynamic languages:
Little help from tools (hardly any refactoring, primitive browsing and auto completion, "code change fear")
It's hard to even know where to start with that nonsense. Here are a couple of points though:
- Refactoring tools were invented in Smalltalk, and continue to be refined there
- Code changes are not only not feared, they are something people expect to be easy to do in Smalltalk
We get to the root of the problem a few slides later, when Cedric says that dynamic languages do this to him: "It makes me afraid to change code"
Note the personalization of that. Cedric has reached his personal limits; dynamic languages are, to be blunt, a bridge too far for him. That's ok; he can stay in the Java kiddie pool, playing with the toys that lack sharp edges. The rest of us will be using tools that let us tackle harder problems with less fear. All we need from Cedric is for him to admit his personal failings and stop trying to pass them off as anything else but FUD.
See this response as well. Randal Schwartz chimes in as well.
Technorati Tags: smalltalk, java, ruby, dynamic+languages, stupidity
Comments
it's harder in strongly/statically typed languages
[ Troy Brumley] July 14, 2008 9:51:42.816
Comment by Troy Brumley
I spend my time fully immersed in Visual Studio for .NET. I fear making changes here far more than I ever did in Smalltalk. There are a few of reasons for this:
There are changes I'm hesitant to make because I know they carry a heavy time penalty. In Smalltalk or another dynamic language, I just make the changes and things just work.
[Dean Ness] July 14, 2008 11:50:29.123
I'm constantly surprised how Smalltalk fans keep claiming how superior their language is to everything else and yet refuse to learn from the simple lesson that Smalltalk completely failed to impose itself in the mainstream.
As for your point about refactoring, yes, Smalltalk invented the concept, but in a very primitive way. Eclipse and IDEA are doing refactorings that are light-years ahead of anything Smalltalk has ever been able to do. This shouldn't come at a surprise, since you need full static type information for some of these refactorings, so it's not a weakness of Smalltalk per se, it's just a consequence of its design.
Finally, the only thing that makes Smalltalk refactorings decent is the fact that a Smalltalk program *is* the IDE. And you need to ship it with your application. The practicality of this aspect notwithstanding, the fact remains that no dynamically typed language today uses this approach, which is why today's dynamically typed languages are not even an option for large-scale software and why refactoring on Ruby or Python are nothing more than search-replace.
Re: When you don't know what you don't know...
[ James Robertson] July 14, 2008 12:03:15.788
Comment by James Robertson
Dean
You're projecting. Read my post, and tell me where I claimed in it that ST was superior. I like Smalltalk a lot, and I do think it's better than, say, Java. That wasn't my point though.
As to refactorings, read Troy's comment.
[Greg M] July 15, 2008 1:33:09.568
@Troy: perhaps you mean "explicit typing", not "static typing"?
definitions
[ Troy Brumley] July 15, 2008 7:46:56.842
Comment by Troy Brumley
@Greg: I'm not sure I see a significant distinction between explicit and static typing. A quick Google and visit to C2 and Wikipedia shows me a lot of debate over how to categorize non-dynamic type systems. We have a shop standard of explicitly defining all variables and assigning them meaningful types, not "Object", and Visual Studio seems happiest with that. Could you say why you think the distinction is important?
[] July 15, 2008 8:14:57.519
See http://duckdown.blogspot.com/2008/07/why-smalltalk-is-still-irrelevant.html
Heh
[ James Robertson] July 15, 2008 9:07:55.831
Comment by James Robertson
I should create a post on why Enterprisey Architects are actively harmful, and sadly not irrelevant
Re: When you don't know what you don't know...
[Dave Buck] July 15, 2008 13:57:10.706
In an earlier comment, Dean Ness made a lot of incorrect claims about Smalltalk refactorings versus Eclipse. The Eclipse refactorings are certainly not "light-years ahead" as he claims. If you take the set of Eclipse refactorings, eliminate the ones that deal with type declarations (which Smalltalk doesn't need) and compare to Smalltalk's refactorings, you find that Smalltalk has several refactorings that Eclipse doesn't have. These include Extract To Component, Move to Inner Scope, Convert to Sibling, Create Suibclass and Inline all Self Sends. On top of that, Eclipse doesn't check during an Extract Method refactoring whether another method with the same functionality exists already and offers to link to it. Smalltalk does. The only refactoring which Eclipse has that Smalltalk doesn't is Introduce Factory which is simply an Extract Method refactoring in Smalltalk so it isn't necessary as a separate refactoring.
Second, we don't ship our IDE with the application. The IDE is removed and only the application classes are shipped.
Finally, Eclipse has similar problems as Smalltalk method renaming when it comes to refactoring Generics. Because of the structure of Generics, it's not possible to figure out all the time which implementation needs to be renamed so it renames all of them.
So much for "Light Years Ahead".