Skip to content

Comparing programming languages

You may ask Why should I compare programming languages? and mean to indicate I’ve been coding for years in that programming language, why should I bother? You may be right but chances are you could improve: Increase your applications‘ speed, increase maintainability, decrease time spent developing your application, increase your understanding of programming in general and such things. Languages evolve. The number of languages increases (see HistoryLanguages). Time to look around…

There are quite some pages out there dealing with the comparison of programming languages (PL). I’ve callected some at LanguageFights – ehm – LanguageComparisons. 😉 I’ve always liked the if programming languages were cars-approach for describing the different traits of PL. Comparing PL to women is not unintuitive, either. I even like to shoot myself in the foot.

Those characterizations cannot help in business-decisions, though. More meat has to be provided. So let’s flesh it out…

I think the simplest metric for comparing PL is speed of execution: Start a program that solves a particular problem with a particular algorithm and see how long that takes. Do this with other programs written in different languages. Compare how long each run took. Simple! Simple? Should the time it takes to start the VirtualMachine be counted toward the execution-time or should it be excluded? That may be a philosophical discussion. Intuitively I’d vote for inclusion. Leaving this decision aside I’d like to point out that this metric is simple in two directions:

  1. It’s simple because it’s easy to determine speed of execution.
  2. It’s simple because it does not help at all.

Heck, I am a hard one for the second one. I think nowadays speed of execution is no longer the main criteria for choosing a PL. It was, back in the old days but in the times of ObjectOriented, TestDriven development of complex (huge) applications other features have to be emphasized. Having read some of PaulGraham’s essays I was convinced that succinctness is the true power. Being able to express one’s ideas in shortest space (i.e. Lines of Codes (LoC)) is it. Using Abstractions provided by a PL will help here. A carefully designed PL is therefore necessary for being able to write programs in less code. That’s why DomainSpecificLanguages exist. One can have succinctness with general purpose languages, too, though.

Succinct languages, enabling shorter programs, exhibit some important advantages of which I want to name a few.

  1. Less code may reduce the number of bugs in the code.
  2. It’s easier to understand what’s going on.
  3. Programmers may understand succinct code written by others faster than longer code. Succinct does not mean dense, here, though (see below).
  4. It may be easier to learn a succinct language than a language with an abundance of features (or syntactic sugar).

So what I think is more important than speed of execution is speed of development. A PL with good Abstractions will assist in writing MaintainableCode quickly, increasing CodeQuality. I came to the conclusion that LanguageComplexity should be minimized. It seems necessary, for a tool, that a PL hides (or abstracts away) the problem from the developer as much as possible. It seems languages like C++ that bug the developer with memory management, pointers, and such things give away productivity in exchange with optimization. PrematureOptimization.

As PaulGraham points out LoC is not a good metric for the succinctness of a language, though. It’s fantastic what can be compressed into just a few lines of code. So instead of using the LoC necessary to solve a given problem as a meassure of succinctness of a PL one may use the AbstractSyntaxTree generated by some parser of the PL to represent the algorithm. More on this can be found on Succinctness is Power by PaulGraham.

Keeping this in mind the comparisons gathered under LanguageComparisons are very interesting, still. Especially the new The Computer Language Shootout Benchmarks is well worth a visit.

The length of a program that solves a given problem can be reduced – as far as I can see – in two ways:

  1. Make the PL less succinct. Increase the number of features in the core of the language. It seems like Perl follows this route.
  2. Maintain succinctness of the PL by adding features by means of code-libraries. Java would be an example of this approach were it succinct.

This should lend itself as an introduction to the topic. More importantly writing this should help clear my mind. 😉 I plan to write more on the subjects scratched here at some other time. Please feel free to add information, critique and insights here as comments or directly to the wiki-pages linked above.

{ 2 } Comments

  1. Emerentia | 2005/6/20 at 10:02 | Permalink

    I would agree with you that the shorter the code the better the PL. But I also think it much depends on what problem you’d like to solve by your programm. Actually I have to write a driver to make the microprocessor responsible for a LCD. It would be unmanageable and maybe impossible to do this by a high-level programming language like Pearl or Java. So, I think some porblems first narrow the set of usable programming languages down – and within this set you can choose your favourite language (if the set isn’t empty or singleton). And second they also determine sometimes the metrics for PL-comparison, i.e. for real-time issues speed of execution and not length of code or speed of development is first class, isn’t it?

  2. Steffen | 2005/6/20 at 03:10 | Permalink

    Very clearly it must be Choose the highest language possible that is available to solve your specific problem.. Not all languages exist for all platforms…

    It goes without saying that some problems cannot or can only hardly be solved by some languages. Those languages simply are not amongst the language you can choose from for solving that problem.

    Additionally it’s not just Choose the highest language.. This is an over-simplification. It should be Choose a language in which your problem can be expressed most naturally. This will result in denser, shorter code which is easier to maintain. Code, that still solves your problem (of course!).

    If your problem is speed of execution you still want a language that expresses your problem briefly and most abstract giving you less opportunities for making mistakes and shortening the process of development. That’s where DomainSpecificLanguages come in handy.

    So, in my opinion speed of development always comes first. Surely, one has to adapt to the concrete circumstances.

    CPU-cycles are cheap, people-cycles are not.


{ 1 } Trackback

  1. […] e the only true criterion for PLs.
    So, I thought, what else might be the noble goal? Some comments already showed, that […]

Post a Comment

Your email is never published nor shared. Required fields are marked *