Mercury's "Time to Hello World"

There's an interesting metric for language accessibility (and therefore, by extension, often its popularity) called "Time to Hello World". Mercury's "Time to Hello World" is abysmal. In this blog entry I will analyse both why it is so bad and what can be done to improve it.

I make no secret of the fact that I really like the Mercury language.  The reasons for this are myriad and will be covered in a language information article someday Real Soon Now™, but some hints of these can be found in an older blog entry I wrote.  Unfortunately, as much as I like Mercury, it suffers very much from "research language disease" and is thus doomed to be an almost disregarded language with no real community and no real future unless something can be done about its absolutely terrible "Time to Hello World" (THW) metric.  (Among other problems, I mean.)

"Time to Hello World?"  Dude, WTF?!

The THW metric is a very simple one: given someone who has a passing interest in language X, from the point of first encounter how long will it take to get a "Hello, world!" program running?  For purposes of this article I will be simplifying the world somewhat and assuming that the user in question is running on a fresh, minimal install of a Unix-like operating system.  Here are a few samplings of THW for various languages:

 

Awk
Approximately fifteen seconds.
C
Approximately a minute.
Python or Ruby
Approximately two minutes.
Prolog
Approximately two to thirty minutes.
Erlang
Approximately thirty minutes.
Haskell
Approximately two hours.
Mercury
Approximately six to fifty hours. (!)

 

Explain, please?

Well, Awk has two things going for it: it's an interpreted language and it's Posix standard.  Any Posix-compliant system must have a functioning Awk.  Thus THW for Awk is a matter of how long it takes to transcribe awk 'BEGIN{print "Hello, world!\n"}' to a console.  C is not necessarily a Posix requirement but it might as well be for this metric.  Anybody who's looking to program won't be using a Unix-like system that doesn't have a C compiler on it.  THW is longer than Awk's, however, because you have to edit a file, enter the code (which is a bit more verbose), compile it and then run the executable.  Python and/or Ruby are popular scripting languages and, as such, usually have a relatively current implementation in the software repositories for most Unix-like systems.  THW is thus a factor of how long it takes to install the language from the repository, to launch the relevant REPL and to type print "Hello, world!\n".  Prolog has a very popular implementation that is in most software repositories.  It is often quite a bit out of date in said repositories, however, so it's often a better idea to compile from source.  Installing from the repository is fast (two minutes) but compiling the world can take a while depending on what you want active, what support libraries you have to install first and how fast your computer is (thirty minutes on the outside for a decently semi-modern machine).  Erlang exists in many repositories, but almost invariably in a stupid form that's also way out of date.  Most Erlangistas strongly recommend that people not use said versions but that people instead download the distribution source and compile from scratch to get a usable and up-to-date version.  This takes about 30 minutes, factoring in all the support libraries you'd have to install from your repositories.  Haskell's GHC compiler has similar issues.  Installing from source is the only credible option—especially if you want to use any current library version.  To do this, however, you'll need to install a boatload of support libraries, you'll need to wait forever for GHC to bootstrap itself and you'll have to contend with a bunch of really bad development tools that plague the environment before you can finally run ghci and type "Hello, world!" into the interactor.  (If anything my estimate of two hours is a bit on the low side.)

 

That leaves Mercury.

 

Wow.  The newbie experience to Mercury is disheartening.  It's not in any software repository (for all meaningful definitions of the term).  You will have to build from source.  Further, the default configuration used when you do the traditional Unix ./configure && make && sudo make install cycle builds a whole bunch of "grades" that are completely unnecessary to the casual user.  The --help flag on the configuration script does contain deep within its bowels some options to disable this, but it doesn't say anything there at all about the implications.  The result is that people who stumble over Mercury from other venues do what any sane distribution would require (the three-step install line above) and then wait.  And wait.  And wait.  And wait.  And wait.  I have had Mercury builds that took over two days (!) on an earlier machine I owned (a single-core, 1.6GHz laptop) and even on my newer (dual-core, 2.2GHz laptop) it still takes a minimum of 6 hours to do the "default" build.

 

This is exactly the kind of experience that drives people away from Mercury (and other languages with similar problems).  The assumption is that if it takes that long to build it must be slow to compile.  Which is actually dead wrong.  Mercury isn't a speed king of a compiler by any means, but it's a decently-performing one.  Compiling Mercury is faster than compiling heavily-templated C++ in my experience.

 

I submit that Mercury's insane THW actively drives it out of consideration for most people who stumble over it.

Strategies to manage THW

There are several strategies to decrease THW (and thus reduce the barrier to entry):

  1. Have the language become a (possibly de facto) standard.  (Awk, C)
  2. Have the language packaged in a variety of binary and source repository formats for easy installation.  (Python, Ruby)
  3. Have the language's build system be conveniently quick even in the case of people having to build from scratch.  (Prolog, Erlang)
  4. Have the language's community act as cheerleaders pushing the language as a panacea for all programming problems.  (Haskell)

#1 is not a plausible option.  Of the literally thousands of programming languages out there, very few have ever become a standard (de facto or otherwise) on a major platform.  (You could probably count all current "standard" assumed-to-be-present languages on your fingers.)  Mercury cannot possibly reach this point in the forseeable future.  Further, to reach this forseeable point the other points would have to be addressed.

 

#2 is plausible but requires, at this point, one very skilled, very knowledgable person to be dedicated to the task for each packaging format.  (Trust me: you do not want to have to support, as an individual, APT, YUM, Ports, Emerge, etc. etc. etc.)  This person would have to know how to package the various grades independently (or quasi-independently) of the core components and how to install things from the various grades so that they won't clash.  Either that or this person will have to maintain one huge mega-package that includes every conceivable grade and then explain why a single programming language's repository package is so damned large (over a GB?).

 

#3 is something that could be worked on right now by a whole bunch of people interested in easing up the newbie experience.  Taking the build time down to, say, under an hour for the default ./configure && make && sudo make install cycle would be ideal; an hour is tolerable if the resulting language is fun to program in.

 

#4 requires a larger community than Mercury has.  As an alternative it requires a community of people who are a lot more pushy and arrogant than the current community has proven to be.  (I'd prefer we lean in the direction of the former over the latter.)

A modest proposal

I submit that the following road map is a good one to reduce Mercury's THW and commensurately increase its popularity.

  1. Fix the build system.  Have a default ./configure && make && sudo make install that (ideally) takes under an hour to complete so that the out-of-the-box experience is streamlined to the first "Hello, world!" showing up on the screen.
  2. Start evangelizing Mercury after this point.  Be up-front with its (many) current problems in the process, but attract the more thoughtful and experimental programmers out there with its strong points.  Use this expanded community to drive…
  3. A cheerleading program where a now-stronger Mercury experience is suggested to a broader potential user base.  Attract enough talent this way to…
  4. Start building binary and source repository packages for various operating systems and distributions.

TL;DR

I like Mercury a lot.  I wish it had a larger user base so that it could be used for more and more real-world applications out of the box.  Mercury's humongous "Time to Hello World", however, severely impedes the growth of its user base (in my opinion).  There are things we could be doing to reduce the THW (and thus the barrier to entry).

 

Let's start doing them.