http://qs1969.pair.com?node_id=501881

Comparing programming languages is fiendishly tricky. Many hold that it is not valid to do it at all.

Here is some material that I have come across recently that strikes me as useful:

Colourfully titled essay discussing some flaws of comparing languages: The Computer Jihad (Ovid)
Insight into how and why a startup might choose a programming language: Beating the Averages (Paul Graham)
Two tables comparing the availability of selected features in a range of languages: 1 2

The final one is the report of some fascinating research. It attempts to allocate a level to a langauge based on the number of lines required to achieve certain Function Points:

http://www.theadvisors.com/langcomparison.htm

I find this last one particulary interesting because it looks at the effectiveness that a language delivers to the developer rather than a simple comparison of features. For example, the designers of Java and C++ chose to be strict about features for valid reasons, but it turns out that the result of that strictness is much more developer effort. Agile languages such as Perl, Ruby and Python score well on this metric as many would expect (Lisp didn't score well but Eiffel did). What I wouldn't have expected until recently was for Objective-C to score so well. While Objective-C relies on very simple extensions to the standard C syntax (which scored 2.5), the concept behind it is so powerfull that it scored 12. Almost as high as the agile languages at 15.

What this means is that you can write (a certain class of) programs in Objective-C with a similar number of lines to what would be needed in Perl or Ruby. Yet Objective-C is all the things that people say are missing in Agile languages (like the speed and obfuscation of native compiled code for example).

As Ovid said (see the first link), there are valid reasons to choose different languages in different situations. After browsing a lot of analysis of features and effectiveness, it is hard to see how Java or C++ could ever be the right choice (with the exception of Java for binary distributed cross platform gui applets).

NB: This is a re-post from my developer blog: http://mark.aufflick.com/dev-blog/archive/2005/10/

Update: As per comments below, some scores seem unusual. SQL, for example, scores higher than Perl. Let's think about that: the measure is of how many lines of code are taken to do a thing. Imagine an sql query joining 5 tables with a sort, a group by and a sub-select. It's only 5 lines of code, but imagine doing that in Perl with hashes - even being smart with map, grep etc. it would be more than 5 lines. Of course you wouldn't do it in Perl, you would do it in SQL. I think a reasonable way to read the scores would be to compare languages that attack a similar goal.

Perl outscores C++. QBE and SQL score the same. Those are valid comparisons. HTML outscoring C++? Well sure, HTML (in it's "runtime") require less lines of "code" to display a document in a sans-serif font than a compiles C++ application, but it's hardly a fair comparison.

Replies are listed 'Best First'.
Re: Comparing languages
by GrandFather (Saint) on Oct 21, 2005 at 04:15 UTC

    When a project is large and requires more than a tiny number of developers languages like C++ pay big dividends. I can't comment on Objective-C in this regard because I simply don't know the language.

    It is interesting to note that SQL scores rather well in table 2, better than Perl in fact. Should we be using SQL instead of Perl?

    Update:Note that BoeingCalc scores a massive 50, but take a look at this. :)

    Perl is Huffman encoded by design.
[reply]
      Wait, there's more! HTML has one of the highest scores. We should all start "programming" in HTML!

      They forgot to add a column that rates the scope of the language (including the question "can it actually be used for programming"?)

[reply]
Re: Comparing languages
by spiritway (Vicar) on Oct 21, 2005 at 05:11 UTC

    This table is eight years old. Among other things, Lotus 123 for DOS scored 50. While I might find a spreadsheet useful for math, I'd hate to try to build, say, a Web browser with one...

    I think that how languages compare depends on how you decide to score them, and you can pretty well get any results you want if you choose your criteria well. You can consider lines of code, programmer-hours of development time, maintainability, CPU cycles, write/compile/debug cycles, and who knows what else. Like anything else, how a language measures up depends mostly on what you consider important.

[reply]
      I added an update mentioning that certain comparisons were probably not valid, otherwise we should all be programming word processing suites in SQL and weather modelling in HTML :)

      I also agree with your comment "how a language measures up depends mostly on what you consider important", but I think it's fair to say that the things considered important by both a Ruby and Python developer are very similar (except semi-colons perhaps ;). Or a C programmer and Pascal programmer.

      Different languages are "more" supported in certain environments and certain developers are "easier" to hire etc. (the decision points are almost infinite), but where there is a choice, a more developer-efficient language will need less developers to be hired, less time to market and faster features added & bugs fixed.

      My feeling is that few considerations outwiegh those ones.

[reply]

      I don't know about a web browser, but it appears that it is possible to create games in Excel (and no, I did not look at the code, I don't want to loose what's left of my sanity!).

[reply]

        Come to think of it, I do recall seeing something about Conway's "game of life", implemented on a spreadsheet... Like you, I avoided looking at it...

[reply]
      I wonder how one would score or rate artistic techniques. One would presumably debate the usefulness, speed, and quality of:
      • oil paints
      • spray can
      • crayons
      • pens
      • throwing food at a wall and so forth

      I guess art comes in many forms and perhaps we're all forgetting that, in many ways, programming is an art?

[reply]
        spray can would score high for efficiency.

        throwing food at a wall would score low for maintainability :)

[reply]
Re: Comparing languages
by dragonchild (Archbishop) on Oct 21, 2005 at 13:50 UTC
    The only useful metric of a language (or any other tool, for that matter) is how well can you/your team get your project done with that tool. Period, end of story. Remember - every programming language is Turing-complete, so anything you can write in one language, you can write in another.

    A few illustrations - ASM is a perfectly good fit for some projects, because of what that project's requirements are. COBOL can be a perfect fit. I know several excellent programs where the developer(s) chose to use languages like Fortran over C/C++/etc, because of the problemspace.

    Me? I use Perl, both because I'm good at it and because it's a good fit for the problemspaces I usually work in. I also use Javascript a lot, for the same reasons.

    As for Lisp, I think that Lisp has the best set of codepoints for all projects, because you get to define how Lisp is going to work for your project in a way that few other languages can do.

    Another thing to think about - some languages are endoskeletal (C/C++/Fortran) and others are exoskeletal (Perl, Ruby, SQL, HTML). If a language is endoskeletal, the programmer has to do more work, but the program can work without the framework needed to build it. If a language is exoskeletal, the programmer does less work, but with the restriction that the framework must be available.

    Here's yet another thought - Perl5 can be considered a minilanguage within a C program. Does that change your viewpoint?

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
      I really like your exo/endo-sekeletal idea. It would be great to start using that terminology instead of scripting versus compiled (which is often used to make exactly the differentiation that you more clearly state).
[reply]
Re: Comparing languages
by neniro (Priest) on Oct 21, 2005 at 07:45 UTC
[reply]
Re: Comparing languages
by blazar (Canon) on Oct 21, 2005 at 09:29 UTC
    It may be of some interest to this meditation this thread from yesterday, although my own reply there is on a less serious ground that what's being discussed here. Another good link for language comparisons that occurs to me now is programming languages study -- italian monks please do not mind the host name, the content is excellent... ;-)
[reply]
      I don't find that a useful comparision at all. It mostly focusses on the program size of trivial programs. That's like doing a comparison of vehicles, and concluding that skateboards are the best vehicles, because they're the fastest on the driveway between the garage and the road.
      Perl --((8:>*
[reply]
Re: Comparing languages
by pg (Canon) on Oct 21, 2005 at 05:42 UTC

    It only makes sense to compare languages within the context of a project and its requirements. Even within that context, there still will be multiple languages that satisfy your requirements. Can you really rank them? you cannot, and you end up just picking one that you LIKE.

[reply]
      I would disagree. You may validly choose a less efficient language for a valid reason. Or you may validly decide that you feel more comfortable with a language even though there are others that are slightly more efficient. But when a language takes significantly more developer time and effort than languages with a comparable application, I can't see why you would choose it without some really compelling overriding reason.

      There have been many attempts to classify and compare languages empirically, and different measures have different levels of flaw and merit. Is there any empirical evidence that comparitively measuring programming languages is fundamentally flawed? I'm not saying there's not, in fact if anyone is aware of any I would be very interested in reading it.

[reply]
        But when a language takes significantly more developer time and effort than languages with a comparable application, I can't see why you would choose it without some really compelling overriding reason.
        I can. Developer time is only one aspect of choosing a programming language, and IMO, not the most important one. Resource usage (CPU, memory, disk space) of the running application is a major consideration as well - you might decide it's not important, but you should consider it. Portability might be an issue. Stability certainly is - Perl does have an impressive list of open bugs. It's years ago that I had to code around a bug in a C compiler (be it gcc or a commercial compiler), but I do encounter a bug in Perl several times a year. (And, it being open source software, some get fixed, others have been open for many years). Another issue might be standardization. C has a standard, and there are many suppliers of C compilers - Perl doesn't have a standard, and there's only one "vendor". It's not always clear what is a bug, what is a feature, or what is an implementation artifact, which can cause headaches when upgrading. (Recently I had a case where an application failed at a customer. They were running Perl 5.8.1 as we said they should. But they were running Activeperl build XXX instead of the (slightly older) Activeperl build YYY we had tested with. Not that Perl was at fault, but it did things differently and some other server couldn't cope with that). As for developers, you will have to adapt your language of choice to you developers as well. If you have Java developers in house (because for the previous project, Java was the 'perfect' choice), you might be better off choicing Java or a similar language for your next project, even if Perl would be a 'better' choice when purely looking at the language angle. And if your developers absolutely loathe using Python, you'll have to make pretty good arguments to force it upon them.

        Developer time is one aspect. But it's just one of many. And it has never been a reason for me to pick Perl for a task. I pick Perl for different reasons.

        Perl --((8:>*
[reply]

Back to Meditations