Invasion of the dynamic language weenies

  • 577 views
Uploaded on

The blogs "Dynamic Language Weenies Victorious After All (http://diagrammes-modernes.blogspot.com/2007/07/dynamic-language-weenies-in-default.html)" and "Invasion of the dynamic language weenies? …

The blogs "Dynamic Language Weenies Victorious After All (http://diagrammes-modernes.blogspot.com/2007/07/dynamic-language-weenies-in-default.html)" and "Invasion of the dynamic language weenies? (http://blogs.adobe.com/shebanation/2007/03/invasion_of_the_dynamic_langua.html)" are based on “Invasion Of The Dynamic Language Weenies (http://www.hacknot.info/hacknot/action/showEntry?eid=93)”. Unfortunately http://www.hacknot.info/hacknot/action/showEntry?eid=93 is no longer easily accessible. I could manage to retrieve the article from Internet Archive (http://www.archive.org/).

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
577
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. "Hacknot: Essays on Software Development" contains 46 essays published on this site between June 2003 and October 2006. Soft copies of the book may be downloaded for free. Paper-back copies are now available. Free Magazines: Profit Magazine: Is distributed to more than 110,000 C-level executives* and provides... Subscribe Free! SD Times: Is The Industry Newspaper for Software Development Managers.... Subscribe Free! Infopackets Windows Email News Daily: Get MS Windows and Tech News: Daily... Subscribe Free! PDFmyURL.com
  • 2. ThinkGeek Invasion Of The Dynamic Language Weenies 26 Mar 2007 Permalink Printable Weenie: Noun 1. a frankfurter or similar sausage 2. informal: one who displays a degree of enthusiasm for some subject or activity disproportionate to the import that most would afford it. I thought I had become inured to it. And yet it still takes me by surprise whenever I come across further evidence of the near total absence of critical thinking in the software development arena. The notion of "evidence" seems to be considered naive and outdated by most programmers. It seems you can make just about any claim that you want and the programming public will eat it up and then later regurgitate it as if it were a self-evident truth. There appears to be no difference between truth and marketing. Research, reason and rationality have given way to bluster, bravado and bull. Such were my thoughts upon reading a piece in the February 2007 edition of IEEE Computer entitled "Programmers Shift to Dynamic Languages" 1 by one Linda Dailey Paulson. The article's basic premise is that dynamic languages (DLs) are experiencing something of a renaissance at the moment. Even though DLs such as Perl and PHP have been around for many years, with the recent advent of Ruby, DLs have become the hot new thing. All the kids are using them. The article has a few select quotes from some of these kids, regarding the near supernatural power of dynamic languages. There's a token skeptic, professor Les Hatton of Kingston University, who supplies what little reasoned thought this puff piece can lay claim to, and then the brochure — I mean article — ends. This was also the point at which I reached for a bucket. I've watched with increasing amusement and irritation as the Cult of Ruby has gathered adherents over the last year or so, smiling as the predictably effervescent enthusiasms of the fan boys frothed and bubbled their way around the urinal of developer discourse. The behavior of the Rubyists is more than a little reminiscent of what we've seen previously from the Extreme Programming crowd. In fact, a number of the most vocal Ruby weenies are former XP weenies. But then, they do say that survivors of one cult are quite likely to later become involved with another. I suppose XP isn't cool now that the buzz has subsided. But for those missing that "born again" spirit that so pervaded the XP movement, despair not. For it is now available in plentiful supply from the Ruby community. To illustrate their fervor, here are a few testimonials from members of the congregation, moved by the spirit of Ruby: PDFmyURL.com
  • 3. I can't put my finger on exactly what I love so much about Ruby, but it makes coding seem cool again.2 Ruby is a fully object-oriented language with a nice, clean syntax, making both development and maintenance faster and easier than in other languages. Ruby brings back the fun into programming! 3 Vitamin R. Goes straight to the head. Ruby will teach you to express your ideas through a computer. You will be writing stories for a machine. Creative skills, people. Deduction. Reason. Nodding intelligently. The language will become a tool for you to better connect your mind to the world. I've noticed that many experienced users of Ruby seem to be clear thinkers and objective. (In contrast to: heavily biased and coarse.)4 Ruby doesn't need to be more safe. It certainly doesn't need static type checking. What we need is to kick the idiots out, and educate those with less understanding.5 Finally, languages like Ruby (with all its domain specific flavors, such as Rake and Ruby on Rails) are like red wine. Red wine is that special gamut of products that demand incredibly high level of devotion and finesse, thus creating its own breed of aficionados[sic]6 I never thought I'd be able to describe anything related to programming as elegant or beautiful, but sure enough, Ruby on Rails is all of that and more.7 ...the finest and most useful language available today8 If Ruby fever continues to grow unabated, the language will soon be touted as an antidote to poverty, disease and social injustice. Indeed, you can already clothe the needy with Ruby t-shirts9 and lingerie10. One expects such immature tripe amongst the Internet free-for-all. But I expected better, or at least hoped for it, from an official publication such as IEEE Computer . I was therefore disappointed to see unjustified (and in some cases, not even potentially justifiable) claims made by DL enthusiasts being repeated without challenge or comment. What really piqued me was the following quote from Stephen Deibel, chairman of the Python Software Foundation11 and CEO of Wingware12, a company whose principal offering is Wing IDE — an IDE for Python development. In support of the claim that DLs make for more compact code, the author offers the following quote from Deibel: Python would use 10 to 20 percent of the amount of code that Java or C++ would use to write the same application. Upon reading this, I burst out laughing — in response to which my cat, the only other occupant of the room at the time, offered me a very strange look indeed, as if to say "Did I miss something?" The quote is given without qualification which suggests that it is meant to apply in any development context. On the face of it, Deibel seems to be claiming that for any given Java or C++ application, one could realize a functionally PDFmyURL.com
  • 4. equivalent version in Python in one fifth the volume of code or less. I couldn't believe anyone would have the audacity to make so bold a claim. 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. But it's not only this claim made for Python that I find impossible to reconcile with my own experience and reason. I find many of the claims made for other DLs to be equally dubious. I have a basic knowledge of DLs such as Perl and Ruby, and have worked with PHP quite a bit. Reflecting on my experiences with these, I cannot find any support for the grandiose claims made by proponents of some of these languages either. But before considering Python as an exemplar of a dynamic language, let's first consider what it means in general for a language to be dynamic. What Is A Dynamic Language? There is no canonical definition of a Dynamic Language, but some generalizations are possible. A dynamic language generally possesses one or more of the following features: 1. Dynamic typing - Variables need not be declared before use. Their type is not determined until runtime. 2. Runtime code modification - Class hierarchies and other logical aspects of the code's structure can be modified on the fly e.g. methods may be added to classes / objects. 3. Interpretation - Source code is read at runtime, translated into machine code as it is read, then executed. Dynamic languages include JavaScript, PHP, Tcl, Ruby and Python. They are often referred to as "scripting" languages. By contrast, static languages have the following general features: 1. Static typing - Variable and parameter types must be explicitly assigned so that they are known at compile time. 2. Fixed code structure - Classes and other code structures are immutable at runtime. 3. Compilation - Code is compiled into some intermediate form, often machine code, which is later executed. Static languages include C, C++ and Java. Python exhibits all three of the DL features listed above, but only the first two exercise any influence over code volume (NB: To be precise, Python interprets compiled byte-code). So if Deibel's claim was generally true, it must be a result of dynamic typing, runtime code modification or some as yet unidentified Python feature. Which feature, or combination of features, might yield these terrific code savings? 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 PDFmyURL.com
  • 5. including such omissions, claiming an 80 to 90 percent code saving seems a bit rich. As an aside, let me point out that the removal of explicit typing is not without its disadvantages, even though it may reduce code volume to some extent. Consider that when you remove type qualification from the source code, you're also removing some documentation of your intent. Given the paucity of documentation in many code bases, it seems unwise to start removing type-related documentation as well. Consider also — if it's good form to give your identifiers meaningful names to aid in comprehension, isn't it equally good form to explicitly assign them types, for exactly the same reason? What about Python's other dynamic feature, runtime code modification. Can it result in a reduction in code volume of 80 to 90 percent? I find this impossible to assess, as I have insufficient familiarity with self-modifying code. But I might mention that this lack of experience is quite intentional. Even when I find myself using a language that permits runtime code modification, it is a feature I am loathe to use for it seems to me to hold great potential for producing a code base that is hard to understand, and therefore difficult to debug and maintain. Additionally, there is significant cognitive complexity that goes along with dynamically modifying code, not unlike the intrinsic difficulty that accompanies multi-threaded code. In my view, this level of complexity is to be avoided if possible. 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. I figured the only way to find out which was the case was to go directly to the source, so I wrote to Deibel enquiring after the authenticity of the quote and whether it had been taken out of context. Had he really meant to make such a broad claim? If so, what evidence — anecdotal or (preferably) empirical — did he have to back up his claim? After all, if this claim of an across-the-board reduction in code volume were true, we Java developers had some serious thinking to do! Not only that, but Fred Brooks' providence might be in doubt, for he once wrote: Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any - no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware. We cannot expect ever to see twofold gains every two years.13 Deibel responded in short order, confirming that indeed the quote had been taken out of context and wasn't intended to "apply to everything, such as implementing the same sorting or image processing algorithm in Python, C++, and Java." 14 Whew - I knew it must've been a mistake. "However" , he continued, "it is true for many kinds of development when you consider the application as a whole (rather than a particular algorithm)" . Oh dear — so the scope of the claim wasn't all kinds of development, it was just "many kinds of development" . That's not quite the amount of reservation I had hoped for. PDFmyURL.com
  • 6. Deibel offered two primary reasons for the code savings he claims exist: 1. The large number of third-party libraries and modules that are available for Python. He claims that these "make many operations that require a lot of boiler plate code in C++ or Java into a 1-2 line task" . 2. The absence of "static type declaration and syntactic sugar" in Python. "For example," he wrote, " 'duck typing' is often used with no declared interfaces" . Let's consider these supporting claims further. The present IEEE Computer article was discussing the relative merits of static and dynamic languages and Deibel's "10 to 20 percent" quote was offered in support of the ostensible benefits of DLs. But any saving in code that occurs from the use of third-party libraries has nothing to do with the dynamic nature of Python. In fact, 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. That leaves us with the absence of "static type declaration and syntactic sugar" as the only pillar supporting the "10 to 20 percent" claim. Before considering that further, let me point out that Deibel is not the only one enamored of dynamic typing. If the assertions of other DL advocates are to be believed, the savings it offers are quite staggering. Amongst such advocates is David Hansson, creator of Ruby on Rails, who is quoted in the IEEE article as saying: ... the time it takes for static typing to enforce all rules throughout the process can make it unreasonably slow to get projects to fruition. This may be an even bolder claim than Deibel's! While Deibel was content to claim that dynamic typing leads to a reduction in code volume, albeit a large one, Hansson is claiming that dynamic typing makes a difference at the project level, between a reasonable and "unreasonabl[e]" completion time! To point to typing as an issue dominating project scheduling is a pretty magnificent claim. Once again, I was incredulous and felt compelled to question Hansson directly as to the basis for his statements. As Carl Sagan once said "Extraordinary claims require extraordinary evidence" , and Hansson was certainly making an extraordinary claim. Like Deibel, Hansson responded promptly, but in less detail. With regard to empirically derived data, he indicated that he "[was] not aware of any such hard evidence" , but that his statement was based on "personal experience and the experience of others retold" 15. But he added that these conclusions were "very rarely [obtained] through direct comparison" , but came from "the feeling of 'I get more done faster on this project using X than I did on the other project using Y." So we're not even talking about a comparison of static vs. dynamic languages here, but a comparison of entire projects where use of a DL was one of the differentiators. Who knows how many other confounding factors might influence one's perception that work on one project was more efficient than on another? And who knows what factors might've influenced this "feeling" of faster progress? We're not even taking measurements or performing a retrospective analyses of code bases ... we're just talking about a "feeling". Oh dear, I thought. I'm getting a bit of a feeling myself — which is that Hansson's feeling that dynamic typing makes a difference at the project level are no more significant than my feeling that they don't! In other words, neither of us really knows. Somehow I'd imagined that such categorical statements as Hansonn's would not be made without some very solid evidence supporting them. I wonder how many other readers of the IEEE PDFmyURL.com
  • 7. article made that same inference? The need for some corroborative evidence must have occurred to the article's author, I thought. Surely no one could document such bold (and in the case of Deibel, precise) claims and not wonder "How do you know that?" So while I was on a roll, I shot off an e-mail to Linda Paulson to see if there hadn't been some editing of her article that had resulted in the omission of some qualifications and questions regarding these quotes. I got no response. Hmmm. But at least Deibel was able to offer some sort of reply to my request for empirical evidence. He pointed me to a paper by Lutz Prechelt entitled "Are Scripting Languages Any Good?" 16 This paper documents an experiment in which 80 implementations of the same set of requirements were compared with respect to such qualities as run-time performance, memory consumption, code volume, correctness and development speed. The results provide a basis for comparison between individual languages and groups of languages. Unfortunately, like much "research" that goes on in our field, although well intended it is methodologically flawed to such an extent that its conclusions are meaningless. If you read the paper carefully, you will discover such methodological errors as: A self-selecting participant group, which introduces bias to an unknown extent. Data set trimming i.e. exclusion of some participant's entries because "they did not work properly." Participants self-reporting their work times, often by making retrospective guesses of time spent amidst other activities such as watching TV and doing housework. Some participants chose to read the requirements days prior to beginning implementation, while others only read them immediately beforehand. Different instructions given to script and non-script programmers. Script programmers were told the broader criteria that their entries might be judged against, but non-script programmers were told to focus on correctness and not to over-optimize their solutions, but to deliver the first one that had 'reasonable' performance. Highly inefficient non-script entries were sent back to the author for optimization. Script and non-script programmers who misinterpreted the requirements and delivered solutions which failed automated acceptance tests were treated differently. Script programmers were given hints and additional instructions, but non-script programmers were just pointed at a particular sentence in the requirements and told to read it extremely carefully. Script programmers were given the test input and correct output files which would ultimately be used for acceptance testing. Non-script programmers were only given a few such samples, and had acceptance tests run against randomly generated test input files. Although the author tries to excuse these errors in various ways, he does so only by making unwarranted assumptions about the extent of their influence over the end result. Now let's examine some of the specific claims made by dynamic language enthusiasts such as Deibel and Hansson ... Claim: Dynamic Typing Increases Development Speed You'll recall that most DLs are dynamically typed. According to DL proponents, this de-emphasis upon typing has some pretty amazing benefits. You'll recall from the above that both Deibel's claims for DLs rest upon it. But what evidence do we have to support that claim and others such as the following, again from the IEEE article: PDFmyURL.com
  • 8. Dynamic languages let developers get results more quickly, said Blackfriars' Howe. Their code is more compact because, for example, there is no type-declaration overhead, Deibel explained I don't think we can say that it's intuitively obvious that the omission of "type-declaration overhead" results in a reduction in code volume that is significant. As mentioned previously, it certainly isn't obvious to me. I accept that it may well lead to some reduction in code volume, but it doesn't follow that reduced code volume leads to increased development speed (see below, Claim: Reduced Code Volume Increases Development Speed). There are many interrelated factors influencing overall development speed. It's not valid to consider one factor in isolation. To reiterate, the abbreviation that brings ostensible benefit to the original author of the code may be an impediment to other's comprehension of the code. Further, how do we know that the presence of compile-time type checking is not a nasty inconvenience, but an efficient eliminator of even nastier runtime errors caused by unanticipated type coercions? Without a detailed assessment of the negative effects of dynamic typing, how can we possibly determine its net effect on development speed? It seems to me that we can't. But it also seems that many DL enthusiasts are willing to ignore such inconvenient issues, even when directly confronted by them. For instance, I notice that in "Programming Ruby" , at the top of Dave Thomas' list of techniques for debugging Ruby problems 17 is "Run your scripts with warnings enabled" — in other words, examine the sort of information that a compiler would already have given you, were you using a static language! This tendency to exaggerate the advantages of some language feature while deliberately ignoring the disadvantages of that same feature is characteristic of much DL advocacy. For my part, I've long recognized that the weakest link in the development chain is not the tools I'm using, but myself. Compared to the cost of my own mistakes, the cost of the tools I use must be trivial, given that I spend most of my average working day catching problems of my own creation. How did those bugs get there? Sadly, I put them there. I'd be surprised if the experience is much different for other developers, if they're honest with themselves. This knowledge guides my choice of tools. I want tools that are going to be most effective at finding the mistakes I make. Therefore I prefer a statically typed language, because I've found that compiler warnings about type mismatches are generally a sign that I've made some programmatic or conceptual error. I haven't written what I intended to. Indeed, the gap between what I wrote and what I intended is where so many bugs lie, that I have come to appreciate the value of being as precise as possible in specifying my intent. Therefore I use Design By Contract, because each contract is one more opportunity for me to spell out to myself, the compiler, and future maintainers, exactly what I intend and what assumptions I'm making. I like to use static analysis tools like PMD 18, that scour my code looking for likely points of failure — a task that is computationally more difficult to perform on a dynamic language. I prefer to use a language with automatic memory reclamation, because I know from my C/C++ days that I tend to make mistakes with memory allocation and deallocation, and the resulting bugs can be incredibly difficult to find. An awareness of my own limitations is the most significant factor in determining my approach to software development as a whole. That's why the dynamic language features that a weenie would call "flexible" I would call "an opportunity to err". Claim: Interpretation Increases Development Speed PDFmyURL.com
  • 9. Most DLs are interpreted rather than compiled. This means that your test/debug cycle no longer includes an explicit "compile" or "link" step which, DL weenies claim, makes for a "development cycle [that] is dramatically shorter than that of traditional tools." 19 Maybe so, but how significant an impact does that have on overall development speed? You don't have to wait for the compile/link to occur, but you still have to wait for the thing to execute so you can test it, and interpreted languages are often slower to execute than compiled ones. So how much do you really gain overall? And there are other confounding factors. Perhaps the compile-time type checking of a static language serves to catch bugs that a DL won't pick up until runtime, in which case some of your test/debug cycles for a DL will be spent catching type-related problems that a static language would've detected before execution began. I say "perhaps" because I just don't know — I'm only speculating. I don't have the data and so I can only guess as to what the net effect is on development speed. The problem is, the dynamic language weenies don't appear to have the data either; but somehow they've attained surety in its absence. Again we see the advantages of a feature (interpretation) being extolled but its disadvantages being ignored. There also seems to be a recurring straw man used regarding the slowness of the compile/link for static languages. The DL weenies like to tell horror stories of how expensive this operation is so as to make interpretation look even better by comparison. For example: But I've worked in C++ environments where programmers joked about having to "go to lunch" whenever they recompiled their systems. Except they weren't really joking.20 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. Claim: Reduced Code Volume Increases Development Speed Many language comparisons performed by DL enthusiasts focus on concision21 as if it were the sole measure of programmatic worth. However there are many aspects of a code base that contribute to an overall assessment of its condition, volume being only one of them. Structure, commenting, consistency, naming, performance and maintainability all influence the efficiency with which programmers can work on a body of code. I would say the primary influencers are the qualities of the programmers themselves. One of the least influential factors influencing development speed is the amount of typing you have to do. We have IDEs with numerous keystroke- saving mechanisms built in such as smart editors, keyword expansion, templates, macros and so on. If code volume were significant as an influencer of overall productivity, then we would expect touch typists to be at a significant advantage to the hunt-and-peck typists which are so common in our occupation. (I can't imagine "the next big thing" being touch-typing, resulting in IEEE articles like "Developers move to touch typing" , peppered with quotes from Mavis Beacon). So from the perspective of one writing code, code volume is not as big an issue as you might think. PDFmyURL.com
  • 10. But for one reading the code, particularly if they are not the original author, the amount to be read and understood is probably more important — but to what extent we can only guess. Further confusing the issue is that there are numerous factors effecting total code volume other than the terseness of the language's syntax. So how can we justify the claim that a particular syntax will necessarily have a particular effect on code volume, or that code volume in turn will have a particular effect on development speed? We can't. Yet there is no shortage of syntax-obsessed language comparisons22 of the form: Here's a toy task implemented in SSL (some static language). Observe that it takes 20 lines of code to implement. Oh, the humanity! Now here's the same task implemented in SDL (some dynamic language). It only takes 10 lines. Therefore you're twice as productive in SDL as in SSL. Even worse, the examples chosen in such comparisons are often selected so as to deliberately highlight the syntactic strengths of the DL in question. Language design, as with much of design in general, is a tradeoff between opposing design forces. Any particular compromise of these forces results in a language with syntactic strengths in one area, but corresponding weakness in those areas requiring opposing characteristics. So for any DL/SL comparison, you can easily arrive at the apparent "result" that your pre-existing bias dictates by carefully choosing the examples upon which your comparison is based. Claim: Support From Major Companies Legitimizes DLs Some advocates, in an effort to bolster the perceived credibility of their favorite language, look for any sign of support that it may have received from a major corporation as proof that it is not just a passing fad, but is here to stay. Otherwise, they reason, why would this company be investing in it? Let's not be so naive. Corporations are out to make money. They are not interested in advancing the software development field, championing an ideology or improving your productivity, except in so far as those activities will yield some financial return. If a company appears to be hopping upon your favorite DL's bandwagon, they are simply acknowledging "There is money to be made here." Commercial exploitation is not a hallmark of engineering worth. It will be in many corporations best interests to actively fuel the hype surrounding a DL in order to generate sales of their own related products and services. Hence the advent of the execrable job title "Technology Evangelist" . When the dynamic language hysteria dries up — and it surely will — these same companies will eagerly pursue the very next trend to surface, just as soon as they can find something to sell to the niche market it has created. We've seen this same pattern so many times throughout the history of this industry, its reoccurrence is utterly predictable. Recall that when OO first came to the fore, companies everywhere were suddenly remarketing their existing fare as being object oriented. All you had to do was change the terminology employed in your products (and conveniently, just about anything can be labeled an "object") and suddenly your marketing strategy had a new impetus. When XP and Agile Methods came along, it was fashionable for a company to promote itself as "agile"; it made them appear contemporary, as if they were intelligently monitoring advances in the state of the art and applying them quickly to great advantage; although in reality many were just running mindlessly after the latest buzzwords. And now that there's some DL brouhaha, it's inevitable that companies are going to be clambering to get on board and portray themselves as "dynamic". PDFmyURL.com
  • 11. Claim: As the Problems Change, People Use New Languages The present IEEE article concluded with a statement from Carl Howe, principal analyst for Blackfriars Communications, a market research firm. He is also apparently a "longtime Unix coder". He claims: Languages are tools for programmers. As the problems change, people use new languages. I suggest that of all the factors driving the current interest in DLs, a changing problem set is about the least important. Consider the newest arrival in the DL family, Ruby. What sorts of initial efforts are we seeing from that camp, but the reimplementation of solutions to problems already well solved by other languages - some of them dynamic! In particular, there is a rush to build libraries so that Ruby can claim comparable library support to Python, and a scramble to provide execution environments so that Ruby might also claim comparable performance to Python23. Is all this frenetic development activity being driven by domain considerations? Hardly. These developers are playing "catch up" with other languages they perceive as threatening to their beloved. Even in the wider development community, the need to solve new problems is rarely to be found as a force driving adoption. Howe seems to be suggesting that adoption of a new language occurs when a developer finds themselves facing a problem that is not addressed well by existing languages, forcing them to search further a field for something more suitable. I suggest that the exact opposite is generally true. Enthusiasts start with the desired solution in mind — the new toy they want to play with — and go looking for a problem to apply it to. I saw this very effect in action on a recent gig. A particular component of a Java based system was needed to perform some basic data extraction and translation tasks, shuffling data between one set of tables and another in a relational database. These transformations were necessary to satisfy some input constraints of a downstream tool. The implementation vehicle of choice? Ruby. Now why on Earth would you choose an interpreted language, both generally and specifically notorious for poor performance, to perform a processing intensive task such as this? And why introduce a new language into a project that future maintainers will have to know? In this instance, there was no great secret as to the real reason Ruby was selected. The weenie in charge of such things had read one too many blog entries about it and decided he had to "get some of that". Although it introduced a maintenance burden for the company, adding another language into the mix also guaranteed some measure of job security for him — given that said weenie would be the only one on the premises that knew Ruby. Fascination with new toys and a quest for job security - these are the forces I see driving the current wave of dynamic language adoption. The problems being faced have nothing to do with it. Claim: You Can Assess Productivity By Feel One of the features distinguishing fact from delusion is the presence of measurable, reproducible evidence that permits independent and skeptical scrutiny. That's how it is in most domains. But in software land, you don't need data and you don't need measurement. All you need is emotion. Martin Fowler's description of how he assessed Ruby's effectiveness is as good an indictment of our field's maturity as you will ever find. He asked some people nearby how they felt, and decided that his subjective assessment of their subjective assessments constituted a business case: PDFmyURL.com
  • 12. When I ask the question "Do you think you're significantly more productive in Ruby rather than Java/C#", each time I've got a strong "yes". This is enough for me to start saying that for a suitable project, you should give Ruby a spin.24 Of course, as discussed many times previously on this site, there is no end to the ways that people can fool themselves into interpreting their experiences in a manner that confirms their preconceptions. Trying to assess a complex factor such as productivity (however you might define it) on the basis of gut instinct is so naive as to beggar belief. If these were the rules of evidence in court, we'd dispense with the formalities and simply ask the jury "How do you feel about the defendant?" . Claim: Syntax Can Be Natural One of the more desperate claims weenies are prone to making is that their DL of choice has a syntax that is somehow more natural, expressive or intuitive than those of other languages. Sometimes they'll go even further, claiming that the DL syntax is so intuitive that it enables some sort of direct mind-CPU connection. For an example of such metaphysical drivel, consider the following passage from Why's (Poignant) Guide to Ruby: But what do you call the language when your brain begins to think in that language? When you start to use the language's own words and colloquialisms to express yourself. Say, the computer can't do that. How can it be the computer's language? It is ours, we speak it natively! We can no longer truthfully call it a computer language. It is coderspeak. It is the language of our thoughts. Lest you think only Ruby weenies are capable of such twaddle, here's something similar from the Python camp: Power, elegance, simplicity, equality, liberty, fraternity: This is heady stuff, and it explains the evangelical tone of some Python programmers. I promote Python because doing so is the right thing.25 When a syntax is described as "natural", what is generally implied is that the syntax is intuitive. If someone unfamiliar with the language were to read a piece of code written in that language, they would probably be able to work out what the code did. Similarly, if they predicted what sort of syntax would be used to achieve a particular function, they would probably predict correctly. Let's put both these claims to the test with a few examples. If you're unfamiliar with Ruby, see how natural the following code seems to you: [1,3,5,7].inject(0) { |x,y| x + y } Can you tell what it does? It's an expression whose value is the sum of all the elements in the array [1,3,5,7], which is 16. Let's try this exercise the other way around. If you had not seen the above, what syntax would you think Ruby uses to sum the elements of an array? Here's a guess: for every x in [1,3,5,7] { total += x } Why did I guess this particular construct and not any of the infinite number of alternatives? Because this is what might seem "natural" to someone with some programming background. PDFmyURL.com
  • 13. I'm using these rather well chosen examples to illustrate what should be self-evident — all programming languages are arbitrary, artificial constructs which must be learnt. They cannot be intuited. Further, what constitutes a "natural" syntax is infinite in scope and varies dramatically between individuals depending on what languages they have been exposed to in the past, amongst other factors. The language designer chose a syntactic option that was most natural to him at the time. Everyone else will simply have to learn by rote the difference between the designer's conception of "natural" and their own. But if the syntax has to be learnt by rote, wherein lies the magic? Language syntax is no more natural than any other abstract notation, such as mathematical formulae, circuit diagrams or UML. Any claim that a DL has a natural syntax is just an attempt to dignify subjective preference. Any claim that a DL has a more natural syntax that another language is just an attempt to elevate one personal preference over another. Claim: A Strength Of My Language Is Its Community I've never been particularly comfortable with the word "community" when applied in a technical context, even though I use it that way myself, for want of a suitable synonym. Watching the behavior of a group of techies does not put me in mind of a "community" in the sense that most would use the term. I've heard both Python and Ruby weenies lauding the nature of the community surrounding their respective DLs, but can find little evidence to support these claims. Watching the various online forums dedicated to each, I see only the same uninspiring character that I've come to expect from such venues. A few people are helpful, a few people are rude, most are engaging in some tacit game of technical one-upmanship with everyone else, and outbursts of condescension and name calling are frequent. A particularly egregious example of the Ruby community (or some elements thereof) at work appeared recently in an online magazine called " bitwise" 26. Bitwise had the audacity to publish an article that was somewhat critical of Ruby, written by one Matthew Huntbach, a lecturer in Computer Science at the University of London. Huntbach's article, " What's Wrong With Ruby?" 27 was a well-written piece, giving an academic's perspective on the current surge of interest in DLs. It raised some interesting issues, such as the discrepancy between pedagogic value and popular appeal that computer science educators struggle with. Huntbach describes his impressions of Ruby as he learnt to use it. He found it to have qualities very much at odds with the claims made by the weenies. The hype says that Ruby is elegant and intuitive, but Huntbach found it to be ad hoc, with a syntax that was not particularly obvious at all. He also made mention of "Why's (Poignant) Guide to Ruby" (already mentioned here), describing it as patronizing, condescending and "horrid". I thought his comments were quite reasonable and to-the-point. The response of the Ruby community to this article, as evidenced in the comments that follow it, was both revolting and enlightening. I suggest you read them all to see the weenie mentality in full bloom. The specific criticisms that Huntbach made go largely unaddressed. Instead, there is an instant resort to personal insult and emotional invective. "It would have been nice if this article had some real content" , exclaims Jason Watkins. Apparently literacy is not Watkin's forte, for the article had a good deal of content, all of which must surely qualify as "real" . "Dear ghod [sic], I pity your students" opines the no doubt eminently qualified Piers Cawley. "you fascist! It's pricks like you who delegitimize the field of programming and suck the joy out of everything!" says one anonymous respondent with a tendency towards over-generalization. Jake, demonstrating a sound grasp of the self-evident, proclaims "You ask 'how could I teach this to a bunch of first year undergraduates?' The answer is that you explain what is going on." Another anonymous dilettante replies with "This could almost be a poster child for the adage those that do, do and those that can't teach" , apparently oblivious to his embarrassing misquote. "biz" , with a perspicacity that cuts right to the heart of the matter, poses the PDFmyURL.com
  • 14. psychological quandary "Never mind what's wrong with Ruby, what's wrong with you?" Finally Bob puts it all in perspective for us: "The author seems amazingly ignorant of the fact programming languages have a culture around them. Ruby's culture encourages creativeness and innovative test-driven techniques. To truly understand a language, you have to see beyond your initial impressions of its overall features." I wonder if Bob read any of these messages of encouragement from within this culture? There's more — but you get the drift. Some Ruby weenies would say that these reactions are not representative of the Ruby community as a whole. I'd say the comment thread as a whole is pretty much a spot on snapshot of Ruby culture. The beautiful irony here is that the fan boys passionate attempts to defend their object of adoration are actually doing it a huge disservice. I think most people recognize that an emotional response is often a cover for a lack of substantive argument. Were Huntbach's criticisms unfounded, a dispassionate statement of the facts would be enough to counter them. By flaming away at the author, the weenies are effectively declaring "We've got nothing!" This is just an example of one language community in action, but the same observations hold true for any other language community you might name. The beneficent throng, much alluded to in the language hype, is never to be found when you go looking for it. Claim: No Harm, No Foul Perhaps the most disingenuous justification offered for unsubstantiated language hype is the common retort "Where's the harm. At worst, [insert favorite DL here] is just one more tool in your toolbox" , the idea being that any amount of hyperbolae, evangelical marketing and straight out fabrication is excusable, as the worst that can happen is that developers will be aware of one more option when they next come to select an implementation vehicle ... and more options have to be good, right? This is the same milksop argument used by advocates of "Intelligent Design" (the latest marketing term for Creationism) when they try to justify the teaching of ID beside evolution in school science curriculums. "Offer students both alternatives and let them decide for themselves on the weight of the evidence" , they say. When such statements are met with predictable (and justifiable) outrage by the scientific community, they mischaracterise this indignance as scientific controversy and propose that science teachers should "Teach the controversy" . But in truth, there is no controversy. Except for a few crackpots, the scientific community recognizes evolution as one of the most successful and widely supported theories in scientific history. To put the substance-free ID on a par with evolution and the mass of evidence supporting it is a travesty. ID proponents are not harmless bystanders with a minority opinion. They are generally religious zealots determined to use ID as a means of promoting their own religious agenda. Bent on manipulating public opinion, they incur an enormous societal and financial cost by distracting science educators from their real business of teaching science, forcing them to defend their curricula against church infiltration. Then, just as they are caught with their hands in the filing cabinet, they feign indignation and try to portray themselves as weaklings who just want to be heard. I hope you can recognize the similarities between ID advocates and the technical advocates that pollute our occupation. They too are out to push their own agendas (selling books, courses, services, products or ideology) by exploiting the fascination with novelty that preoccupies so many. Sure ... push Ruby onto your next client, because it feels like the right thing to do. Let them bear the consequences of your transient fascination. After all, it's just one more option, right? It's not like there are any ramifications of choosing the wrong tool ... at least, not for you. Conclusion: For Rationalists PDFmyURL.com
  • 15. Language advocacy seems to be mainly an exercise in selective observation. You focus only on the positive effects of the design choices behind your favorite language's construction and deliberately ignore the inevitable negative effects of those same choices. It may sound silly and trite, but it is also extremely common. DL advocacy is just the latest example of this ongoing phenomena. DL advocates exhort the rapid test/debug cycle that comes from interpretation, but ignore the slower execution time which comes along with it. They praise dynamic typing for its convenience to the original programmer, but ignore the loss of documentation for the maintainer. They belabor the benefits of a DL's brevity, and make claims for the commensurate effect on project duration, ignoring the fact that these claims are unsubstantiated by anything but flimsy and unreliable anecdotal evidence, influenced to an unknown extent by the personal biases of the observer. Then along comes a journalist, looking for material for a new article, who adds on their own bias through out-of-context quotation and further selective observation, and suddenly the breathless enthusiasm of fan boys has become a hot new trend in the pages of IEEE Computer . Sad, isn't it? There appears to be almost no demarcation between opinion, marketing, reporting and fact. It all blends together into a meaningless melange of group-think. The most meaningful contribution of the article in question comes from Les Hatton, in relating the fashion-driven nature of software development: They [dynamic languages] will appear, hang around for a while, and then disappear, he explained. "This is what happens when fashion dictates progress rather than engineering concepts such as measurement, validation, root-cause analysis, and defect prevention. Conclusion: For Weenies At eight thousand words, this article requires far longer to read than the attention span of the average dynamic language weenie. I know most of them will have skipped directly to the conclusion to save themselves valuable time; time that could be spent in devoted worship of their favorite DL. In weenie land, knowledge of a criticism is not a prerequisite for self-righteous indignation. I also know that it doesn't matter how heavily I qualify my statements and conclusions, weenies will exaggerate them all into straw man absolutes for the purposes of counterargument. As a convenience to such folk, what follows is an expurgated version of the preceding piece, expressed in weenie-speak (which is characterized by snide, sweeping conclusions and ferocious responses to slights manufactured in the mind of the reader): Claim: Dynamic Typing, Interpretation and Reduced Code Volume Increase Development Speed Reality: No they don't, either individually or together. Development speed is influenced by so many technical, psychological and organizational factors that the effect of a set of programming language features on overall progress can be, at most, minimal. Further, your arguments in favor of these language features deliberately ignore the manifest disadvantages of those same features. Software development is much more than just programming, and programming is much more than coding. Get back in your high chair, from where you might get some perspective. Claim: Support From Major Companies Legitimizes DLs Reality: No it doesn't. Companies know that fan boys like you are easy marks - an enthusiastic and indiscriminate market segment ripe for PDFmyURL.com
  • 16. exploitation. They also know that you might spread your naive enthusiasms into your workplaces, opening up a corporate market for supporting tools. Claim: As the Problems Change, People Use New Languages Reality: As languages change, people remain the same. Software development is now, and always has been, driven by an obsession with novelty, and that is what drives language adoption. If there is a new problem to solve, that will simply make for a convenient excuse. Your misplaced enthusiasm simply perpetuates a cycle of self-defeating behaviour that prevents software development maturing into a true profession. Claim: You Can Assess Productivity By Feel Reality: No you can't. You're just trying to justify personal preference by hiding it behind a legitimate but definitionally complex term. If you've never taken measurements, you have approximately no idea what your productivity is like either with or without your favorite dynamic language. You certainly can't assess the difference between the two. Claim: Syntax Can Be Natural Reality: All programming languages are arcane and cryptic, in different ways and to varying degrees. What is perceived as "natural" varies tremendously between individuals, depending upon their experience and background. Your mischaracterisation of a syntax as "natural" is just an attempt to retro-fit a philosophy to your personal preferences. Claim: A Strength Of My Language Is Its Community Reality: If it it, then you are in deep trouble, for your community appears to be dominated by juveniles who only take time out from self-gratification long enough to wipe the byproducts off their keyboard, then mindlessly flame anyone who does not share their adolescent enthusiasms. Claim: No Harm, No Foul Reality: No Brain, No Pain. References: 1. Programmers Shift to Dynamic Languages – Linda Dailey Paulson, IEEE Computer, Feb 2007 2. Like Rails, Love Ruby – http://www.markmcb.com/markmcb/blog/Like_Rails_Love_Ruby 3. Dynamic Ruby Gets Ready for the Enterprise - http://www.sdtimes.com/article/column-20060701-01.html 4. Why's (Poignant) Guide To Ruby – http://poignantguide.net/ruby/chapter-2.html 5. Java People Must Be Stupid – http://evang.eli.st/blog/2007/1/22/java-people-must-be-stupid 6. Ruby On Rails Is Like Red Wine – http://lesscode.org/2006/01/08/ruby-on-rails-is-like-red-wine/ 7. Why I Love Ruby on Rails – http://v1.garrettdimon.com/archives/why-i-love-ruby-on-rails PDFmyURL.com
  • 17. 8. Programming Ruby – Dave Thomas et. al, Pragmatic Bookshelf, 2006 9. Stuff For Ruby Programmers – http://www.cafepress.com/mathomhouse/6101 10. "I Love Ruby" Classic Thong – http://www.cafepress.com/iloveruby.27352825 11. Python Software Foundation – http://www.python.org/psf/ 12. Wingware - http://www.wingware.com 13. No Silver Bullet: Essence and Accidents of Software Engineering – Frederick P. Brooks, Jr. 14. E-mail to the author – 3 March 2007, sdeibel@wingware.com 15. E-mail to the author – 3 March 2007, david@loudthinking.com 16. Are Scripting Languages Any Good? – L. Prechelt, Universitat Karlsruhe, Germany, 18 Aug 2002 17. Programming Ruby – Dave Thomas et. al, Pragmatic Bookshelf, 2006, pg. 167 18. PMD – http://pmd.sourceforge.net/ 19. Programming Python – Mark Lutz, O'Reilly & Associates, 1996 p. 702 20. Ibid – p. 699 21. Python & Java: a Side-by-Side Comparison – http://www.ferg.org/projects/python_java_side-by-side.html 22. A subjective analysis of two high-level, object-oriented languages – http://twistedmatrix.com/~glyph/rant/python-vs-java.html 23. The Impending Ruby Fracture – http://blog.lostlake.org/index.php?/archives/11-The-Impending-Ruby-Fracture.html 24. Evaluating Ruby – http://www.martinfowler.com/bliki/EvaluatingRuby.html 25. Why I Promote Python – http://www.prescod.net/python/why.html 26. Bitwise Magazine – http://www.bitwisemag.com/ 27. What's Wrong With Ruby – Matthew Huntbach, 16 Mar 2007, http://www.bitwisemag.com/2/What-s-Wrong-With-Ruby PDFmyURL.com