Complexity Shock Horror II: the Sequel (was Re: MD5 in erlang .)

Chris Pressey <>
Mon Mar 31 21:35:03 CEST 2003

On Mon, 31 Mar 2003 14:50:43 +0200 (CEST)
Joe Armstrong <> wrote:

>   If we generalise over non-integer  bases to can easily make (say) an
> avoirdupois converter, so that:
> 	integer_to_list([20,4,2,14,16,16], 456789)
> would then convert 456789 drams to 
> (tons,quarters,hundredweight,stones,pounds,ounces,drams)
> and so on ... *very* useful for calculating with common units -
> think about it for a few micro-Fortnight's ....


Despite your slightly facetious tone I think you have touched on one of
the biggest blind spots in software engineering, something that has been
a thorn in my side for more than a couple of years.  So of course I'm
going to rant about it.

I have yet to see a programming language that doesn't model basic
numbers as scalar values (or matrices or sets of scalars).

Yet, I don't see *any* scalar values in the world around me.  They *all*
have units of measurement.

But, you may well say, what's the big deal?  We *have* to make some
concessions to translate a model from the real world onto a computer -
why is dropping the units of measurement not justifiable?

Two reasons: the Gimli Glider[1] and the Mars Climate Orbiter[2].

The latter resulted in an immense loss of property; the former would
have resulted in the loss of life, had the pilots not been as skilled as
they were, and had the Gimli airstrip not have had the foresight to be
located in Gimli.

Looking at these mixups you may well conclude, we should simply abandon
imperial measurement in favour of metric (good luck!)

Unfortunately, that would only help mitigate the problem; it doesn't
help solve it.  Think of how many times you've had to look up the timer
manpage to see if a given parameter is in milliseconds or microseconds.

If the basic numeric type of Erlang (or in fact any other programming
language) was rich enough to include the units of measurement, there
would be no need for such confusion and doc-hunting - and I submit that
the language would become that much more expressive:

    {update_distance, D} when D is_in m ->
      {ok, whatever(D)}
    after 5 sec ->
      {error, timeout}

For a while I tried designing a new language around measurements.  It
was only a partial success, and I was encouraged to modify an existing
language instead, for correctness issues - but when trying that with
Erlang, I was discouraged from modifying the existing language, for
familiarity / predictability issues.  I'm not sure which path I'll take
next time.



More information about the erlang-questions mailing list