Following a trackback to your own blog entry can be interesting from time to time. Today, for instance, I was led to an interesting blog from quite some years ago on the sys-con site by Michael Yuan entitled “Is Ruby Replacing Java? – Not So Fast”. In his blog, Michael talks a bit about why he thinks Ruby and RoR will not push Java out of the web application development arena. Part of his argument is that each development system tends to etch out a niche for itself, to attain dominance there and to be almost impossible to force out due to the traction it gathers in that niche.

His other argument, I think, is far more interesting and fundamental to the understanding of software engineering. To quote Micheal:

Instead, it matters far more to have better requirement gathering, better customer feedback, better development process, better trained developers, and better development tools (e.g., IDEs). In software engineering speak, the actual implementation of a system using a specific programming language has the lowest value in the value chain, and can be easily outsourced.

To put it another way (a way that I have tried to get many people to understand at different times):

It’s not about the language, people!!!

I’ve sort of talked about this before, from a different angle, in a previous blog. It irks me every time I hear somebody describe a language as being a better development platform than another language because of some feature that saves you somewhere between two keystrokes and two seconds worth of typing. Thinking that language A is a language-B-killer because of that sort of productivity improvement is a sign of inexperience, as far as I’m concerned. Reason being, when you get right down to it: writing software is about modeling. About constructing a useful, flexible, et cetera, domain model and supporting code. Software engineering is about all that plus more, like risk management, managing your team, ensuring communication within and outside your team, requirements management, change management, fill in your favorite feature. If you’re on top of all that, how the model is reflected exactly in the syntax of a language is almost an afterthought. And if you have to rely on the marginal productivity boosts you get from one language over another to save your neck, you might as well not bother.

Just to try and prevent the firestorm of misunderstandings that I know is coming my way: I’m not saying it’s not good to know how to do a particular thing in a particular language. Nor that knowledge of frameworks or a particular development system is not important. But I am saying that relying on

collection.each {|element| do_something.with(element)} (Ruby)

or

[f.c | c <- [1..M] ] (Haskell)

over

for (Element e: MyCollection) { do_something(e) } (Java)

is just not going to make a difference and is no reason to think that one development platform is better than another. Meaningful productivity and flexibility come from a good design of your application. And, by consequence, from daring to refactor and redesign as necessary. Which means it also comes from having project management that is willing to support such development practices and defend them if need be. And from having developers (software engineers) who dare, who can carry off their practices and therefore can be relied on by project managers, enabling them to support and defend. Not from saving on a few braces here or there.

Thanks Michael, your blog is still a great read.

It’s not about the language, people….

4 thoughts on “It’s not about the language, people….

  • January 31, 2009 at 1:12 pm
    Permalink

    Hello Ben,

    I think we think the same on good software. The best software is software that satisfies the customer (or better said: the user) best. Both now (in usage) as in the future (as in being extensible, robust and scalable) .
    Language and compiler design are good subjects to see ‘beyond’ a programming language and tool.

  • January 31, 2009 at 11:32 am
    Permalink

    Gerbrand,

    I sort of agree with you a little bit up to “The best software is developed by the best software developers.” After that you lose me.

    First of all, what do you consider the “best software”? Is that software that was written to squeeze every last drop out of every last feature of its programming language, or is that software that correctly and clearly expresses the problem domain and the solutions within that domain? Is software more readable because it is written clearly, with descriptive names and objects (in a mathematical sense, not an OOP sense) that use the domain language — or because the program is short? If a program requires maintenance due to a threading bug, is it more likely that bug was caused by the multiprogramming model of the language, or because the developer didn’t correctly synchronize the parallel components of the program (and I don’t mean mechanically synchronize in the sense of syntax, I mean that it’s more likely his chosen solution to the problem is wrong)?

    That aside, what gives you the idea that there is something like a “best programming language”? Any problem domain has a set of optimal languages for that domain (i.e. a set of languages optimally suited to solving the problems of that domain). Object-oriented languages happen to be well-suited to business software, which is usually an interaction between business entities. But if I were working on scientific software, at least for the computational core, I probably wouldn’t rely on Java as much as on Haskell. Or LISP, for AI.
    However, as Michael Yuan points out, in software engineering the fact that a language is technically more suited to a problem is not even always a deciding factor. If an organisation has standardized on Java, you will have to use Java to work for them. Even if you happen to feel Ruby is a better language. In other words, software engineering is about more than the concerns of a single program. And that is where you need a software engineer rather than a software developer: you need someone who sees that code quality lives in design and domain expression, not in language syntax.

    Back when I was in university, there was a course on programming language concepts. That course taught us about the different concepts of programming language and illustrated how they were implemented in different languages. The goal of the course was to prepare us to learn any programming language necessary, fast. And the reason for the course is what I said above: it’s ludicrous to think that you’ll never have to deal with more than one language or that one language is the be-all and end-all of things — or even “the best”. I’d go so far as to say that such belief is a handicap to any software engineer.

    Finally, I agree that the best software is developed by the best software developers. However, I think “the best software developers” probably means something different to me than to you. I would consider the best software developers the ones that form the team that has the best mix of experience, is the most willing to learn and consider different ideas and approaches and is the most focused on domain concept (the domain language) rather than on domain implementation (the programming language syntax).

    BTW, I didn’t say the difference between Java, Ruby and Haskell was small. The difference between Haskell and Java is huge — fundamental even, since they are based on different computational models. What I said was that if your grasp of the domain is firm, you will be able to express it in whatever language you happen to be using.

  • January 30, 2009 at 11:15 am
    Permalink

    I a bit of provocative posting. The best software is developed by the best software developers. The best software developers want to develop in the best programming language, using the best tools. So the programming language *is* important.

    Developing good software is possible in any language, but good developers prefer to program in a language that is concise, using software development tools and environments that don’t waste their time.

    I don’t agree the difference between those languages is small. Features as closures, actor-model as alternative for mediocre threading model, ability to program functional, advanced typing system, ability to extend the language allow developers to program software that consists of fewer lines of code and that is much more readable.
    All in all, software development is a continuous process in any company. This means software not only has to be build ‘in time’ and ‘in budget’, but also that software can be extended and maintained easily.

    However, I agree that many problems in current software development can’t be solved by just switching language.

  • January 27, 2009 at 2:15 pm
    Permalink

    Thanks for the excellent post, Ben. It drives some very important points home, and I think many developers would benefit from taking a step back and seeing the big picture to software development, as you describe.

Comments are closed.