It's the libraries, stupid
Jeff Atwood has a nice piece on the productivity of different programming languages (go read it). His sums up with the following:
*Given ..
1). the abandonment of C++ and C for mainstream programming
2). the huge influence of individual programmer skill
- the slow but steady adoption of scripting/dynamic language conventions in Java and .NET*
*.. maybe all modern programming languages really are the same.
Ole Eichhorn has already taken Jeff to task in the comments about his definition of mainstream, and Jeff has responded here so I’ll leave that one alone for now ;) Several people picked up on the relative unfairness of using lines of code as a productivity measure, so I’ll leave that one ;) which leaves me with something I’ve been meaning to write about for a while…
Another comment on the original posting, this one from Matt, hits the nail on the head for me. It’s the quality (or at least coverage) of the libraries that ship with modern languages that make the most difference in productivity for all programmers. I’d like to take this further and say that it’s the libraries that some programmers put together themselves, creating further, more focussed, abstractions, that help some programmers appear vastly more productive than others. I have statistics to back this up, it just feels right ;)
The .Net languages all have access to a vast library. This provides all manner of functionality in, often, quite usable abstractions. This is functionality that in many other, older, languages you’d have to put together for yourself. These libraries obviously help immensely with real programming problems; it’s much faster for anyone to write a TCP server in C# than in C++ because of things like System.Net.Sockets.TcpListener. However, it’s possibly even faster for ME to write a high performance TCP server in C++ because of the libraries that I’ve written. Likewise I have lots of reusable code in my “JetByteTools” libraries and this means that I very rarely have to work at the lowest level of abstraction that’s available to me in C++. The important thing, for me, at present, is that I can choose to work at that lower level if I need to. Sure sometimes I’m forced to work at the lower level because I haven’t worked on a particular “thing” before, but it usually only happens once per “thing”.
In my opinion the approprite use of library code is one of the major causes for the, often vast, difference in productivity between programmers. Even on a ‘from scratch’ project where all programmers are given the same set of libraries and tools, some will naturally wrap up collections of calls into useful objects or helper functions and some will write code as if it was a blob of MSDN sample code. It’s not surprising that some programmers are more productive. Some of us only write the error handling once because we create thin abstractions that suit our current requirements and then reuse them. Likewise, these “productive” types do pretty much everything this way. And before someone chimes in saying that it’s more work and takes longer, it isn’t and it doesn’t and people who work like this do so without needing to think about it a great deal, it’s easy and natural for us. Practice the principles of “DRY” even if you don’t expect to ever need to repeat what you’re doing; you will and when you do it’s easy.
As Matt says in his comment, if one of the languages under test had provided the following public void ReadFileAndWriteToConsole(string fileName) then the programmer would have been viewed as being the most productive… The most productive programmers dont let the fact that the language doesn’t provide stop them from providing for themselves.
