Programming Languages in Joy and Sorrow

Most of us (programmers) know, and need to know, many programming languages. Some aren’t even perceived as programming languages any more (Shell-Scripts), some make us a living (Java, C# etc.), some are hard to replace (JavaScript), and some are just fun to play with (make your choice).

What makes programming languages differ is not syntax, syntax is nothing more than a mechanical translation, much like a cipher: back and forth without gaining or losing information.

General purpose language don’t even differ in what they’re able to express. All of them are “Turing Complete”1 and hence are equally potent.

What makes a difference is how programming in these languages feel like. Even though Assembler and JavaScript are equally potent (in theory), they are two very different beasts.

What appeals to me are just a handful properties of a language:

  • simplicity,
  • expressiveness,
  • performance,
  • productivity.

Simplicity

If a programming language is complicated by itself, programs become brittle, programmers are distracted, there is no uniform structure etc. C++ is a wonderful and very expressive language, but it has so many ways of doing things, so many features to learn (and distract) that I would not care to use it again.

Simplicity was one of C’s big appeals, the language is very lean and has a small set of features. The language features were carefully chosen to be general enough to not be too restrictive.

Expressiveness

How much code do I need to write to get a job done? How good are the means of abstraction (how often do I need to repeat myself)?

Assembler doesn’t have much abstraction capabilities (mostly jumps), whereas functional languages offer powerful ways of separating, combining, and reusing code blocks.

A simple and expressive language is easy to understand, and has few, but powerful, means for abstraction.

Performance

Computers used to get faster every year for some time, currently we’ve reached a plateau and instead of scaling up, we’re scaling out by adding cores and machines.

Our programs don’t get faster by waiting for a better machine anymore. We need to actively take additional cores into consideration. The future (and probably the present) is distributed!

I think performance is still a major merit of today’s software. If your service can’t scale to “internet scale”2, you’ll lose. If your competitor offers the same set of features, but twice as fast, you’ll lose.

So a modern programming does not need to be the fastest one on a single machine and a single core, but it should be reasonable fast and scale easily to threads and processes.

Productivity

Computers have become insanely fast, but programmer productivity stayed the same. Sure, we can’t call Intel for a brain-upgrade, but we can choose and provide the right set of abstractions to support us.

Besides the simplicity and expressiveness of a language, productivity involves the available libraries, the community and the culture of the community. Java, for example, has a very active Open Source culture, quite untypical for a business related language.

“Academic” (or, let’s call them “non-mainstream”) languages are often very beautiful and expressive, but their lack of practical libraries makes it hard to get up and running quickly. We’re in an age of quick-fixes and easy gains – what’s the point of choosing the newest language du jour if we can’t deliver faster (in the long run)? What’s the point of “engineering” if, in the end, we need even more time than by hacking3?

Productivity, for me, heavily affects the fun in programming and mostly subsumes simplicity and expressiveness.

Language assessment

In a business setting you rarely have a free choice of weapons, but for personal or pet projects, you can do that. Most people I know stick to the language from work because it is well known. Some are increasingly unsatisfied with their day-job language and set out for the search of their “own” language. I can’t tell you what the best language is. Everyone is different, like Yukihiro Matsumoto said here:

No language can be perfect for everyone. I tried to make Ruby perfect for me, but maybe it’s not perfect for you. The perfect language for Guido van Rossum is probably Python.

You are different from everyone else. Embrace the difference. Use your brain and make you own choice.

Of course, given the sheer amount of programming languages, making an educated guess is crucial. Taking only the 100 most popular languages into account is surely not too far off.

Go Philosophical

Languages are divided into a few categories concerning programming paradigm (object oriented, functional, procedural…), typing (strong, weak, static, dynamic) etc.

My personal preference is with statically typed functional languages because they provide very good abstractions and safety through the compiler.

Look for a language with good interop functionality.

We’ve invested a lot of time in building libraries, helpers, utilities etc. Of course starting from scratch is fun, but it’s rarely economical.

If you used to program in Java, start looking for JVM languages for example.

Read some code before diving in

Typing.io is a nice starting point for some languages, and of course, there is always github.

Do you feel comfortable with the layout, the language, does it feel natural? Do you even understand some of it?

Enough with the subjective assessment, show me something objective!

Here is an unbiased and objective survey of a few programming languages I’m interested in. It’s totally foolproof and you certainly should start a multimillion dollar company on it!

This chart shows the ratio of the number of search results for

"c programming" "sucks"

and

"c programming" "rocks"

as returned by Yahoo!.

That is, "c programming" "sucks" returns 20800 results, "c programming" "rocks" returns 222000 results, hence a ratio of 10.6731 in the chart. Thus, everything below 1 means, there are more “sucks” results than “rocks” results.

Since Haskell, Clojure, and Scala completely dominate the chart, here a version with the obvious winners removed:

The numbers were computed using Google Docs - Spreadsheets and its awesome ImportXML function:

=ImportXML("http://search.yahoo.com/search?p="&C4,"//span[@id='resultCount']")

Cell C4, referenced in the above code, contained the URL encoded search-string, for example %22c programming%22 %22rocks%22. Try it with prolog ;-).

  1. Even some configuration files are considered Turing Complete, like sendmail’s.

  2. Whatever internet scale is in your domain.

  3. You’ve got to measure the whole lifetime of a project, it doesn’t help to get something working very quickly but with huge amounts of bugs, hard to change etc. I guess that’s a topic for a whole book on its own.

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
— Bill Gates