Erlang for desktop applications?

[Richard A. O'Keefe]

Jacobo =?ISO-8859-1?Q?Garc=EDa?= de Polavieja Aguilera
<jacobopolavieja@REDACTED> asked:

	But, do you see Erlang suitable for developing future (more than
	5 years from now) desktop applications?  I know it wasn't
	designed for this, and that there are very important actions
	like string functions which are slow in Erlang... 

ARE they?  Have you measured them?

We had a lengthy thread not so long ago where I pointed out that
there is more than one way to represent a string, and that for
many applications the traditional packed-array-of-bytes is a rather bad
representation.  (For example, for Information Retrieval a list of
word numbers may be better.)  And it is much easier to experiment with
unusual text representations in a language like Erlang than in a language
like C++ or Java.

A colleague and I are teaching a 4th year "advanced object oriented
programming" paper.  He and I agree about lots of things, some of which
other people in the department don't agree about.  One of them is that
in 10 years time if you can't write reliable highly concurrent code you
will probably be out of business.  (Assume Moore's Law keeps going, but
with respect to total performance of multicore systems rather than
per-core performance, and in 10 years time we'll see kilocore machines
on the desk top.  They will probably be running some sort of virtual
reality sex game.)  So last week he spent a lecture on Occam (which to
my pleased surprise is still around even though Transputers are dead;
KROC is even freely downloadable and installed without any problems).
This week I'm going to spend a lecture on Erlang.

Let's assume an 18-month doubling time, and let's take 4 cores as the
starting point.  (I have a copy of "Dual-Core Update to the Intel(R)
Itanium(R) 2 Processor Reference Manual, and Sun's Niagara is 8-core,
so I'm taking 4 cores as a sort of midpoint.)  In five years, we'll
expect there to be desktop machines with 32 cores.

(Ooh, I just noticed this from InfoWorld back in 2004:  NEC developed
a cellphone chip, the MP211, with three ARM cores plus a DSP, so that's
a four-core chip in your hand.  Hmm.  There's an "image processor" on
the chip as well, according to the NEC web site.  What I can't find is
a price for these things.)

	but then I also ran into EX11 and similar projects which seem
	like a little light for my future purpose.  Could be erlang efficient
	with desktop related stuff?

It all depends on what you do on your desktop.  Did you see the
article someone mentioned recently about decoding some sort of video
format in Erlang?  If you are doing something like music or video
editing on your desktop, perhaps what really matters for performance
is the DSP or GP, not the "steering" code.  If you are doing information
retrieval or data mining, heck, people even do that in Java (although
I do *wish* that the NCSA ALG group would spend some time producing
usable documentation for their program; I would cheerfully accept something
10 times as slow with a manual just 2 times as big if it had the right
stuff in the manual), because if you have good data structures it's
probably I/O bandwidth that matters rather than CPU speed.  (We have
a student looking at information retrieval on a multicore machine, and
it's not clear that there's going to be a result other than "I/O
concurrency is the right kind".)

	If not, could you recommend other
	functional languages that fit best that objective?  I'm looking
	forward to efficiency on future multicore processors and easy
	concurrency management.
	
There's always ML.  As a happy Haskeller, I do find the syntax of SML
clunky, and O'CAML even worse.  Sadly, O'CAML is one of the fastest
systems around.  Although Mlton (no typing mistake, it really is m l
t o n) is a darned good batch compiler for SML.  And although concurrency
isn't officially standard in ML, both SML/NJ and Mlton support the CML
extensions.  The SML Basis Library includes particularly good support for
substrings, if string hacking is important in what you do.
	
There are also concurrent versions of Haskell, and Haskell these days is
doing some *awesome* things with generic programming (think "type safe
programming ON the language IN the language" and "automatic derivation of
large chunks of code").  Clean generates pretty darned good code, and a
somewhat different version of generic programming, but they've dropped
concurrency support, for now at least.

Then there's Mercury, which gives you logic programming and (strict)
functional programming and constraint programming all in one strictly
typed and heavily checked box.  (The compiler will even try to figure out
whether procedures must always terminate, although the Halting Problem
result means that it can't always be sure.)  People are using that for
desktop stuff.
	
Given Erlang's support for interfaces (CORBA, ASN.1, C, Java, you name
it) it's difficult to think of any likely desktop application where
Erlang couldn't have _some_ practical use.