My good buddy Steve Yegge posted quite an article yesterday. It’s the transcript of a presentation he gave at Stanford a few days ago, and the overall idea is that dynamically typed languages are on the rise and statically typed languages are on their way out.

I highly recommend reading the entire transcript, it’s very entertaining and, like a lot of the stuff that Steve writes, filled with insight and provocative thoughts. Unfortunately, this time, just like a supervillain, Steve put his fantastic observation skills and remarkable breadth of knowledge to serve a lost cause. There’s no easy way to put it, Steve, but you’re just wrong 🙂

I sent him a reaction email shortly after he posted his article, and he encouraged me to make it public in an attempt to document our two opposing viewpoint publicly. I’m happy to be the Luke Skywalker to his Darth Vader.

Evil shall not prevail.


First of all, I was initially very excited about Scala until I realized that two features were close to being deal breakers for me: implicits and pattern matching.

Have you taken a look at implicits? Seriously? Just when I thought we were not just done realizing that global variables are bad, but we have actually come up with better ways to leverage the concept with DI frameworks such as Guice, Scala knocks the wind out of us with implicits and all our hardly earned knowledge about side effects is going down the drain again.

As for pattern matching, it makes me feel as if all the careful data abstraction that I have built inside my objects in order to isolate them from the unforgiving world are, again, thrown out of the window because I am now forced to write deconstructors to expose all this state just so my classes can be put in a statement that doesn’t even have the courtesy to dress up as something that doesn’t smell like a switch/case…

About the difficulty to impose a non-mainstream language in the industry

this in the beginning: this is 80% politics and 20% technology, right? You know.

I find this very disingenuous. Steve, you know it’s not true, right? Most of the people around you would love to be able to use the language that they really like, but the cost for the company just doesn’t make sense. I would therefore revise your break down as follows: the reason for not using a non-mainstream language in a big company is 10% politics 10% technology and 80% common sense.

Let me turn the table on you and imagine that one of your coworkers comes to you and tells you that he really wants to implement his part of the project in this awesome language called Draco. How would you react?

Well, you’re a pragmatic kind of guy and even though the idea seems wacky, I’m sure you would start by doing some homework (which would show you that Draco was an awesome language used back in the days on the Amiga). Reading up on Draco, you realize that it’s indeed a very cool language that has some features that are a good match for the problem at hand. But even as you realize this, you already know what you need to tell that guy, right? Probably something like “You’re out of your mind, go back to Eclipse and get cranking”. And suddenly, you’ve become *that* guy. Just because you showed some common sense.


Not harder to build dynamic tools than for static languages, just different.

I still strongly disagree with that. It is different *and* harder (and in some cases, impossible). Your point regarding the fact that static refactoring doesn’t cover 100% of the cases is well taken, but it’s 1) darn close to 100% and 2) getting closer to it much faster than any dynamic tool ever could. By the way, Java refactorings correcting comments, XML and property files are getting pretty common these days, but good luck trying to perform a reliable method renaming in 100 Ruby files.


I no longer bother trying to understand why complex Generic examples are so… well, darn complex. Yes, it’s pretty darn hard to follow sometimes, but here are a few points for you to ponder:

  • 90% of the Java programmers (including myself) only ever use Generics for Collections.
  • These same programmers never go as far as nesting two Generic declarations.
  • For API developers and users alike, Generics are a huge progress.
  • Scala still requires you to understand covariance and contravariance (but with different rules. People seem to say that Scala’s rules are simpler, I’m not so sure, but not interested in finding out for the aforementioned reasons).


I’m actually surprised you spend so much time defending the performance of dynamic languages, because I don’t think it’s worth it. Yeah, they’re slower overall but in the same margin as Java used to be slower than C++, and we know how that turned out. Not much to argue about here in my opinion.

What will keep preventing dynamically typed languages from displacing statically typed ones in large scale software is not performance, it’s the simple fact that it’s impossible to make sense of a giant ball of typeless source files, which causes automatic refactorings to be unreliable, hence hardly applicable, which in turn makes developers scared of refactoring. And it’s all downhill from there. Hello bit rot.

I hate giving anecdotal evidence to support my points, but that won’t stop me from telling a short story that happened to me just two weeks ago: I found myself in this very predicament when trying to improve a Ruby program that 1) I just wrote a few days before and 2) is 200 lines long. I was staring at an object, trying to remember what it does, failing, searching manually in emacs where it was declared, found it as a “Hash”, and then realized I still had no idea what the darn thing is. You see my point…


Javascript is on the verge of becoming part of the assembly language family, and toolkits like GWT are making sure that this will happen before too many developers join the pool of low level language victims. I’m sure you can relate to that stigma.

Also, I think you are vastly overestimating how the optimization work on Javascript is going to advance the science in that area. I’m sure thousands of very smart researches are busy doing that right at this moment, but come on: Javascript has become very much good enough for a lot of apps.

And what’s interesting is that, as opposed to Java, Javascript has an upper bound where it no longer matters to make things go faster, because there is only so much you want to do on the client anyway. Gears is even showing us that we can do a decent amount of processing on the client, but so few applications need that that I think the backdoor tricks that GWT uses (such as image bundles) are much more clever and much more useful than any of the stuff that you show in these slides.


You know, even Emacs has to evolve.

No: it’s Emacs users who have to evolve.

Error messages

And the weird thing is, I realized early in my career that I would actually rather have a runtime error than a compile error.

You probably already know this, but you drew the wrong conclusion. You didn’t want a runtime error, you wanted a clear error. One that doesn’t lie to you, like CFront (and a lot of C++ compilers even today, I hear) used to spit in our faces. And once I have a clear error message, I much prefer to have it as early as possible, thank you very much.

Trace trees

The PDF link is broken.

The dynamic nuclear winter

And everybody else went and chased static. And they’ve been doing it like crazy. And they’ve, in my opinion, reached the theoretical bounds of what they can deliver, and it has FAILED.

Quite honestly, words fail me here.


Finally, the largest flamewar that I ever witnessed involving Stallman was when he dissed XEmacs on comp.lang.emacs and it quickly turned out in the discussion he hadn’t even launched the darn thing. Get your history facts straight!


Interestingly, I am currently working on a brand new presentation on this very topic that I’ll be making at Jazoon next month. I’m still working out the details, but this presentation will take a quick tour of the dynamic landscape, contrast it with Java and argue that statically typed languages in general and Java in particular have never been in a stronger position to remain the language of choice for large scale software for the decade to come.

Hope to see some of you there!