The Regenerate Web

I just read Bob on development's post On Software Development Fashions  which is a riff on this post  from "Ed Johnson" the Hacknot blog.  The basic idea of the original post is that there is no evidence of one programming language engendering higher productivity than another, with the specific issue that the current crop of dynamic languages (Ruby, Python, etc.) being the primary topic.  There are many, many proponents of these languages, and I have come into contact with a few.  Languages (and editors) tend to become a religion with some developers.  I would also say, that some programmers tend to become "high priests" of whatever programming language they are currently using.  You will never convince a high priest that his or her religion is not "true".  

What both articles fail to recognize is that there are organizations who have spent a significant amount of time documenting the difference in productivity between languages, not so much as a means of selecting a development tool, but as a way of validating estimates.  Back in the '70's the group who created Function Point Analysis actually started ranking languages in terms of level, and specifically levels were based on how many SLOC (source lines of code) were required to complete a function point - with the idea that the less lines of code the more function points a developer could build in the same period of time, give or take.

There is a language level table that has been published and revised over the years to include many (hundreds) languages.  Unfortunately Ruby and Python are not on this version.  So, Ed, there is a community that is focused on software metrics that does try to empirically measure the productivity that each language brings - simply in terms of the number of lines of code per some defined chunk (function point).  Unfortunately, they are also a religion, and it appears that one cannot get the current table without a paid subscription to one of their sites.  I, not being a true believer in that religion, do not have access.  

That said,  I agree with both Ed and Bob that it is unlikely that any language gives a 10-fold (90% reduction in code) increase in productivity to the developer.  or even a 5-fold (80% reduction in code) increase.  What I have seen is that the best developers, when working in their chosen paradigm, outproduce the average by that same factor of 5 or 10.  That is a smart coder, working in a language that he has truly mastered, and likes, can outproduce me and you by a factor of 5 or 10.  When I find the language that lets me code like that, I will convert to it's cult, and try to become a high priest.  Why, because it feels really, really good, to be supremely productive.  When your teammates look at you as if you were a god, that is a form of programming nirvana.  

But Ed's beef was specifically around dynamic languages.  I want to speak to this, because the first (and only) language where I approached true mastery is a dynamic language.  Interestingly, there are interpreted (normal) and compiled versions of this language, and working in both, I didn't notice a tremendous productivity difference, because the compiled version had an interpretive run-time engine built in, so it "simulated" interpretation.  This is necessary to be able to execute code out of a string at run-time.  The power of this language came from it's underlying paradigm, the dynamic typing was something that allowed one to introduce errors unintentionally, and one actually had to write extra code to test variables to ensure that they had the right properties.

The true power of this language was the ease with which one could build data-driven applications.  The language primitives contained some powerful string manipulation functions that could be combined to great advantage in dealing with complex string manipulation applications like interfaces or messaging.  The language supported code and data indirection, so that one could hide the name of a variable or database record in a variable and refer "through" like pointers but not nearly as abstract.  One could also drop executable code in a variable and move it around then execute when desirable.  Is that self modifying code?  No - that would mean that the original program modified itself in memory.  This is merely an additional form of dynamism.  Slurp code out of the database, then execute was as simple as locating the code, and a single line of code to execute.  

Does that sort of power make programs complex? Difficult to maintain? Hard to understand? Hell yes!  Does it mean that we shouldn't use those language features?  Hell no!  With this caveat - you need to carefully control how these features are used in a production system, and ensure that there is adequate documentation for those who come behind to understand how you wrote an XML parser in 200 lines of code, or some other amazing feat of programming wizardry.  

One thing about interpreted languages (I currently use python, and php the most) is that they let you write code from the inside out and test it without much hassle - that is, I write functions and test them long before I write the main.  Because of the interpreter, I can get a command line from which I can call my function like a verb  and see the result:

   print ( object->method('test1', 123, 345));

That allows me to get a considerable way down the path before I worry about larger chunks of code than functions or methods.

Working with unit test harnesses gives me much the same ability but I have to build first in a compiled language, which even if it takes a minute, means I am going slower than interpreted mode.  In interpreted mode, I close the editor, execute the function, and see the result.  Bam!  I have even baked a script where I have the unit tests baked into the edit cycle, so that I close the editor, and the editor script automatically runs the unit tests for the file that I am editing when I close the editor, and will prompt to re-open the editor if any of them fails.  That can be done in any interpreted language with a little workstation automation.  There is a tremendous power to the immediacy of this idiom, code-test-repeat-until-done.

Each language brings with it certain primitives that were pre-existent in the mind of it's author, that when the fully resonate in a developer's mind, they create power and productivity.  Any language that one picks up, it pays well to sit at the feet of a high priest or at least a true believer and understand deeply where the power comes from.  I had this experience with Python recently, and took a simple desktop automation script to the local high priest for review.  After he looked at my crappy code, he recommended some more efficient ways of doing the same thing that took more advantage of Pythons capabilities.  He asked me how long I had been using Python, and when I told him that this was my first script, he said - not bad for a first try.  Supreme validation for a novice from the high priest - maybe I can convert to this religion...