Cool Code v Working Code
By Martin English | October 25, 2006
Developers and Administrators under the age of thirty have no idea why old farts like me are sceptical of the productivity claims, why we roll our eyes at the hype and buzzwords that sell books and consulting engagements, about the amzing new programming language / technique / methodology du jour. Occassionally, it’s because we’ve seen it all before. IBM systems running multiple operating system instances ? Sounds like good ole MVS to me….
For example, the current state of play is that Sun’s JRuby team (Sun hired key Ruby developers Thomas Enebo and Charles Nutter, back in September) has just released JRuby 0.9.1 for Java, with version 1.0 is expected in due course.
Apparently, going from JRuby 0.9.1 to 0.9.0 apparently brings a 50 to 60 per cent performance improvement (just how slow was it then ?), improves support for Ruby on Rails and for including Java classes in Ruby; delivers various design refactorings; and fixes some 86 Jira bugs. According to Thomas Enebo,
JRuby is going really well.
And Microsoft has just hired Ruby guru John Lam, to help it add dynamic scripting languages to the Common Language Runtime platform. Apparently, he created RubyCLR as an alternative to Microsoft’s C#, so this suggests that Microsoft could soon deliver Ruby as a complement to it’s release of IronPython (which is Python for .Net). There’s certainly a rich choice for dynamic programming enthusiasts these days.
The problem I have is that delivering systems fast is popular, until the business finds out:
- that what it gets doesn’t align with its requirements well,
- that the cost of development pales into insignificance besides the cost of support,
- there’s no traceability
Of course, better dynamic languages may help but they’re still not really the real issue, as far as I can see., For example, customers and employers are thinking about ITIL and IT governance).
The real issue is that there’s No Silver Bullet. It’s an important essay from way back in 1986, by Frederick P. Brooks (he of Mythical Man-Month) that has been repeatedly proven.
Programming consists of overcoming two things: accidental difficulties, things which are difficult because you happen to be using inadequate programming tools, and things which are difficult, which no programming tool or language is going to solve. An example of an accidental difficulty is manual memory management, e.g. “malloc” and “free,” or the singleton classes people create in Java because they don’t have top level functions. An example of something which is actually difficult is dealing with the subtle interactions between different parts of a program, for example, figuring out all the implications of a new feature that you just added.
Improvements in programming languages can eliminate accidental difficulties, but after you’ve done that, you’re left with the actual complexity of software development, so the No Silver Bullet theory basically warns us to expect diminishing returns from new technologies. I’m not really doing justice to Brooks’ argument, so if you haven’t read No Silver Bullet recently, I would highly recommend it.
Topics: Languages, People, Productivity, Work, blogs / podcasts | 2 Comments »
October 25th, 2006 at 11 18 am
You’ve essentially made the case for dynamic languages: they minimize the amount of accidental complexity that you have in your software. Your code is more malleable, which makes it easier to change/support over time.
I’m not sure what you mean about your traceability point. And on the point regarding alignment to what a business wants – that’s all about process, not technology.
So if you mean that technology matters less than the people using the technology, then I’d agree with you. However, assuming that you’ve got good people, then giving them good tools makes sense, no?
October 25th, 2006 at 3 07 pm
I am not exactly sure what your problem is with “new exciting” languages. There is a clear problem with modern popular languages like java or C# that they are designed from the ground up to protect programmers from them self. They constrain programmers in a tight jacket of strict type checking, predefined syntax etc. making them on one hand more friendly to novice while preventing the rest of from expressing programing problems in a most efficient and compact form. There is not much new about Ruby or Python or many other “new” languages as they all ultimately converge to LISP, which cannot really be thought as new. No one is talking about “Silver Bullet” really, these “new” languages are indeed just incremental improvements on what we had until now, but it is also true that they help us to alleviate common sore points
we have developed working with other lower level languages. I think the writing is on the wall. We are moving toward mostly two types of languages, low level once like C and very high level once like LISP, Ruby, Perl etc.