Invasion of the dynamic language weenies?
Hacknot has published a contrarian paper on Python, Ruby, and other dynamic languages called “Invasion Of The Dynamic Language Weenies”. Its an interesting read, with the central premise being that dynamic language partisans (like me) haven’t empirically proven any of the benefits they tout. I think this is a fair criticism, albeit one taken to a ridiculous extreme in this article. I do find it odd that he spends so much time pointing out the lack of empirical evidence and the use of biased and/or anecdotal evidence on the pro-dynamic language side of the debate, but then turns around and makes exactly the same mistakes on the con side of the argument:
Actually, I had trouble imagining how it might be true even within limited domains. Though I’ve principally used Java for the last 10 years or so, and C/C++ for five years preceding that, I have a basic familiarity with Python, having written a few utilities here and there with it. Reflecting on those experiences I could see no basis for such a startling claim to code brevity.
In other words, “I can’t imagine it and haven’t experienced it, therefore it must be false…”
Can dynamic typing result in a reduction in code volume of 80 to 90 percent? It seems highly improbable to me. Suppose I had a piece of Java code and went through it removing all the type qualifications. Would that reduce the code volume by 80 to 90 percent? No, I don’t think so. Maybe there are other omissions that dynamic typing would make possible, such as obviating adapter-style classes and some interfaces. But even including such omissions, claiming an 80 to 90 percent code saving seems a bit rich.
He dismisses actual studies where people have compared static and dynamic languages as being overly biased, then does a “mental exercise” to prove his own side of the argument.
On the whole, no matter how hard I tried, I simply could not convince myself that dynamic typing and runtime code modification, either individually or in concert, could produce a code base that was “10 to 20 percent” the size of its static equivalent. Either the quote was inaccurate, had been taken out of context, or Deibel was engaging in some fairly outrageous marketing hyperbolae.
Again, “I can’t imagine it and haven’t experienced it, therefore it must be false…”
I recall doing maintenance and extension work on a system written in C containing approximately one million lines of code. To build that entire system from scratch took several hours. But that didn’t mean that every test/debug cycle we performed was punctuated by that same delay. There were large parts of the code base that we were not involved in changing, and they were built into libraries once at the beginning of the project, and thereafter we just linked against them. The net result was that in each test/debug cycle we were compiling only a small fraction of the code base, then linking against the pre-built libraries. This took seconds, not hours. It’s part of basic build management when working with a static language that you only recompile what you have to. The DL weenies would like you to believe that a burdensome compile/link time is an unavoidable downside of using static languages when in fact, it is not.
“This wasn’t true on one system I worked on, therefore it is universally untrue”
I could go on, but you get the idea. So here’s my challenge to hacknot: you seem awfully certain about things. Why don’t you back up your side of the argument with some hard and fast empirical data of your own?
Shebanator 
It is up to the person making the original claim to back it up with facts.
I too doubt the claims of that dynamic languages add much. The C++ to Java transition saves some work due to the addition of garbage collection. I would guess 30% in a typical application. It is also easier to learn as it is simpler.
I don’t see removal of typing to be that helpful. Perhaps it is too write quick and dirty apps but I suspect that it is an easy way to create lurking bugs that can’t easily be eliminated. For large projects, the confidence that strong typing gives is essential, IMHO.
Paul Topping.
[Andrew says] I agree that the person who makes the original claim must back it up with facts. But sauce for the goose is sauce for the gander – if you make counterclaims, you too have the obligation to prove those claims. In other words, the logical fallacy occurs when you go from “you have not definitively proved your hypothesis” to “thus your hypothesis is inherently false”. The original article did the latter, as I’ve shown via numerous examples. I want to point out, as well, that I’m not making the same mistake: I’m only pointing out only that nothing has been proven sufficiently on either side of the issue.
I made a rather lengthy reply to the linked article here.
Basically, I think that the author mis-identifies the sources of dynamic language productivity, and I individually refute each of his “claim/reality” points.
I think that many of the big wins that dynamic languages have in terms of productivity come from ideas that have been borrowed from functional programming (high-order functions in particular) and powerful built-in types.
And of course there’s evidence required for the claims of productivity. And of course such evidence, both objective and subjective, exists and is dismissed by the author. Unfortunately for the credibility of the author, it is not sufficient to dismiss the existing evidence as “flawed” and call that lack of evidence without producing some evidence of your own.
Anyway, if you want to read more, you can read my article, and I’ll stop taking up comment space.
Hi Andrew,
That is a fine collection of strawmen you’ve assembled there. Nobody light a match!
In other words, “I can’t imagine it and haven’t experienced it, therefore it must be false…”
The article makes no such claim. Your “in other words” is precisely what the article is not saying. Equivocation is expressed frequently throughout. The certainty you imply exists simply does not (except in the “Conclusion for weenies”, which deliberately eschews equivocation for rhetorical purposes). The piece uses words like “perhaps”, “I don’t know”, “seems” and you’ve misrepresented these as categorical statements.
Again, “I can’t imagine it and haven’t experienced it, therefore it must be false…”
Again, the article makes no such claims. You’re resurrecting the same strawman. The piece says “I can’t imagine it, so I’ll go looking for evidence. First stop, the people who make these claims”
So here’s my challenge to hacknot: you seem awfully certain about things.
You’ve clearly read a very different article from the one I wrote. How do you suppose you managed that? There’s not too much that I’m certain about, except that there are a lot of people in software development who seem to be very certain about things, when they have no adequate justification for it.
Why don’t you back up your side of the argument with some hard and fast empirical data of your own?
The claimant carries the burden of proof. The DL advocates are the ones making the claims, it’s up to them to prove themselves right, not for me to prove them wrong. I don’t have “a side” to prove – I’m simply pointing out that the DL weenies have not come close to satisfying the burden of proof, but carry on with a degree of conviction that implies that they have. The piece is about the damage that hype does to the field, and the absence of critical thinking. It’s not about “I’m right and you’re wrong”, it’s about “I don’t know and neither do you” and “we probably never will unless we stop carrying on with all this religious fanaticism and put our energies into more worthwhile pursuits”.
I thought this was stunningly obvious.
[Andrew says] See my response to the previous comment. I do think you may some good points in there, and I don’t know that you are wrong. But you made some claims of your own in your article, and your burden of proof is just as real as theirs. Perhaps your intent wasn’t to make those claims – I’ll take you at your word. But when you structure your argument as “they claim x, but I can’t imagine that to be true, and once I experienced something contrary” – well, that IS a counterclaim based primarily on opinion and anecdote. That is what I’m complaining about here and I’m not the only one who noted the extreme nature of your rhetoric.
To say that static typing is adequately represented by C, C++, and Java is far more ridiculous than the zealous excesses of the Ruby community.
If you’re going to talk about static typing, could someone at least include a token language that doesn’t suck ass? One that’s type inferenced and fast, like most of the ML family languages?
Here’s an orthogonal claim: not all static languages are created equal. C is terrible for anything besides device drivers, realtime graphics, operating systems, and stuff like that. Scala, Haskell, and OCaml are lovely. (And all three of them give you a REPL and/or an interpreter in addition to compilation.)
Here’s another claim: I can do stuff in 400 lines of Haskell that would take King Blub 500-2000 in C. Want an example? http://www.xmonad.org/ – 2000 lines of C, 400 in Haskell. And if it involves tons of allocation and deallocation, Haskell will probably be faster. Deal with it.
I’ve written lots of code for big and small systems in PHP and Python. I’ve written even more C and C++ code, and plenty of Pascal, Fortran, and COBOL if you want to go back through my resume far enough. For the last few months I’ve been writing mainly Python after a year of PHP at my day job and C++ on the side.
I am skeptical of head-to-head “shootouts” of programming language productivity because it is not possible to control for the big variations in programmer ability; those variations have been well-documented. Without searching too much I found one credible comparison of programming languages that includes Python, C, C++, and Java: see An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl.
I think Hacknot deliberately ignores some of the obvious advantages of languages like Python and instead insists that removing type declarations and adapter classes and using self-modifying code can’t possibly eliminate enough code to make Python programs significantly smaller than C++ or Java programs. I don’t think a serious programmer would make such simplistic arguments, but the sneering tone of Hacknot’s article tells me that he’s not engaging in serious argument.
I won’t say that my Python programs are 10% or 20% the size of an equivalent C++ or Java program, but 50% is probably about right. The main reasons I write less code faster in Python have nothing to do with not having to write type declarations or writing self-modifying code (something I never do anyway). The big wins are:
Better built-in data types, like strings, lists, and dictionaries (hashes)
A rich and tested standard library that is 95% identical across platforms (Windows, Linux/Unix, OS X)
Not having to spend the time thinking about and defining class hierarchies and inheritance trees and interfaces in advance of writing code
An interactive interpreter for trying out snippets of code
Garbage collection
Looking at the C++ code I’ve written recently a lot of it is devoted to strings and lists and hashes, which I write with STL containers. Having “real” strings is a big time saver and cuts way down on lines of code, if your code happens to do lots of text manipulation. As nice as the C++ STL is it’s pretty clunky compared to Python’s sequences, maps, and iterators, and I don’t have to know any tricks to make a list that has strings, numbers, objects, and other lists in it. When the language gives you more abstract data types and operators to work with you don’t need to spend your time writing lots of code to simulate them with primitive types.
There are lots of good libraries for C and C++, but few of them work on more than one platform, and none of them are as complete (and free) as the Python standard library. I can write an HTTP server or a web page template engine (for example) in just a few lines of code, because most of the pieces I need are written for me, included in the Python distribution, and well-documented online and with built-in help. Hacknot writes: “[A] static language benefits from such libraries just as much as a dynamic language would. So we can’t claim any such savings as an inherent benefit of Python in particular, or DLs in general.” True enough, except Python comes with just such libraries, for free, but C and C++ don’t. There are plenty of libraries for Java, and it’s probably possible to assemble a collection of Java libraries as complete as Python’s standard library, but not for free, and not without a lot of work resolving incompatibilities.
As for the static typing vs. dynamic or “duck” typing debate, Hacknot willfully gets the whole argument wrong to continue beating a dead horse. The important difference is not whether types are declared for the compiler or not, but whether I have to design and define a consistent system of types (classes) and their relationships in advance of writing code. I can’t remember working on a non-trivial C++ system that didn’t require multiple re-workings of classes and their relationships; that doesn’t happen in Python programs because the requirements for creating a new type are a lot looser. I was indoctrinated in the Wirth way of thinking early on in my programming career so getting my types defined correctly before writing code seems the right way to do it. However, with Python I find that I rarely need to define my own types because I can use the built-ins. A typical C++ program has lots of classes that inherit from library or platform base classes. A typical Python program has calls to library functions that accept lists or dictionaries. It’s really more like Stepanov’s original generic programming ideas only without the compromises C++ imposed on the STL.
Sometimes I miss having type declarations in function definitions, but not often. The Python community has gone back and forth on optional type declarations several times. If I really missed them, or thought the lack of type enforcement was a significant source of hidden bugs, I could write one-line asserts to enforce the correct types. Those kinds of bugs are just not as common as C++ and Java programmers think they are, again because in Python et al. you don’t need to build elaborate type/class systems. Complementing dynamic language programming with unit tests and TDD helps, too, and I write defensive code that compensates somewhat for the lack of strong typing. I’ve written several thousand lines of production Python code in the last two months, and mismatched types just didn’t come up. I had more trouble getting the XML output templates right.
I can understand Hacknot’s skepticism — some of the claims he refutes are hot air or at least not representative of enough programs to cite as proof. However the tone of Hacknot’s article and his use of straw men (“What Is A Dynamic Language?”) to support his dismissal of dynamic languages work against him. I’ll be the first to agree that PHP is dumbed-down enough to let amateur programmers get something bad to work, but that doesn’t mean PHP is a horrible language (though it is pretty bad), nor does it mean only amateurs use dynamic languages. I’ll be writing more C++ soon because Python isn’t appropriate for everything, but I won’t ever write a web server application in C++ or Java if I can choose Python, or even PHP, instead.
1) “…Reflecting on those experiences I could see no basis for such a startling claim to code brevity.
…
Andrew wrote: In other words, “I can’t imagine it and haven’t experienced it, therefore it must be false…”
You’re putting words into his mouth. I read that as – I can’t see why it would be true. The extra step – “therefore it must be false” – is yours not his.
2) Andrew wrote: He dismisses actual studies where people have compared static and dynamic languages as being overly biased…
He dismisses the one and only study that had been suggested as evidence by Stephen Deibel.
3) … no matter how hard I tried, I simply could not convince myself that dynamic typing and runtime code modification, either individually or in concert, could produce a code base that was “10 to 20 percent” the size of its static equivalent.
…
Andrew wrote: Again, “I can’t imagine it and haven’t experienced it, therefore it must be false…”
You’re putting words into his mouth. I read that as – I can’t see why it would be true. The extra step – “therefore it must be false” – is yours not his.
(Incidentally, if we actually look at the LOC measurements in Prechelt’s paper – the mean for Python programs is ~1/3 the mean for Java programs, not 10 to 20 percent.)
4) To build that entire system from scratch took several hours. But that didn’t mean that every test/debug cycle we performed was punctuated by that same delay.
…
Andrew wrote: “This wasn’t true on one system I worked on, therefore it is universally untrue”
You’re putting words into his mouth. I read that as – this wasn’t true of one system I worked on, therefore it is not universally true.
5) Andrew wrote Why don’t you back up your side of the argument with some hard and fast empirical data of your own?
What do you think his “side of the argument” is?
afaict his whole argument is that extravagant claims are being made without supporting evidence.
[Andrew says] As I’ve said in response to previous comments, I think it is perfectly fine to criticize dynamic language proponents for not sufficiently backing up their claims. If he had just done that I wouldn’t have said a peep. But hacknot went well beyond that point without bringing any objective evidence to the table.
I read your previous comments before commenting myself.
If Hacknot had made claims in the way you suggest then you should be able to show those claims in his words. You haven’t done so – you have put words into his mouth.
If you wish to criticize Hacknot, ask if he really did publish “Invasion Of The Dynamic Language Weenies”, edit the text and then republish without noting how or why the document had been changed.
[Andrew says] I don’t agree that I put words in his mouth, but I clearly didn’t do a sufficiently good job of it to convince you. So be it. As for hacknot’s post, i wasn’t aware he had changed it since I haven’t been back to his site. Thanks for the tip.