Erlang for desktop applications?

[Richard A. O'Keefe]

"Jacobo G. Polavieja" <jacobopolavieja@REDACTED> wrote:

	That's my main point of view and what drove me to consider a better 
	language for programming concurrency. I truly believe is going to be 
	like that in the future. So, do you see Erlang is the/one of the most 
	best positioned to take advantage of that future fact?
	
People have been designing concurrent languages for years.
Burroughs Algol, back in the 60s, had coroutines and concurrent processes
(and even ran on true multiprocessor hardware in the 70s).
Simula 67, famed for introducing Object-Oriented Programming, was
also important for offering (simulated) concurrency.
We've had Concurrent Pascal, Concurrent C, C++ originally came with
a Simula-inspired threads package, Ada, Occam, you name it.

Of the many ways to look at these languages, one of them seems to me
to be the most useful for our present topic:

    - is the language "business as usual PLUS threads" (like Java)
    - or is it designed from the ground up to support correct concurrent
      programming?

This is not quite the same question as "is thread support integrated into
the language" (as it is in Ada) or "is thread support pretty much a bolt-
on-the-side library" (as it arguably is in Java, and if you don't believe
me, browse around in java.util.concurrent some time -- I'm sure tentacled
monstrosities from the outer darkness were involved somewhere there).
The question is rather "was the language so designed that it is easy for
a compiler or other tool to PROVE that a wide range of concurrency problems
simply cannot occur?"

Concurrent Pascal and Occam (up to Occam 2.1, which was the last Occam I
really understood) have rather strong limitations, precisely to make it
easier to reason about concurrent programs and make it obvious that many
problems (notably one thread trampling on another's data, but there are
others) couldn't possibly exist in a program.

While Java looks to have concurrency support built in, it is fatally easy
for two threads to trample on the same data, and it is fatally easy to
_think_ you are protected from this when you aren't.  In contrast, in Ada
it's really quite hard to get yourself into that kind of trouble, and if
you stick to the "safe" features of the language, I don't think you can.

C# and the whole .NET framework falls into the same "mostly business as
usual" bucket as Java.

Make no mistake.  People have developed useful concurrent applications
using Java and C# and will continue to do so.  (Especially if they are
savvy enough to use verification tools like ESC/Java2.)

    BUT

"mostly business as usual" language make it easy for people to keep on
thinking and programming sequentially.  This makes it harder for them
to exploit multicore machines and easier to make mistakes.
	
	many "actions" taken in desktop apps that are very concurrent or just 
	concurrent. I mean... all I can think about that could benefit from 
	Erlang's concurrency is a mail application (to retrieve mail), P2P 
	application (interconnect users)... which are very "networky" (where 
	Erlang is strong).

I'm not really sure what a "desktop app" is.  I suppose it includes
    - e-mail
    - word processor
    - spread-sheet
    - data base
    - web browser
    - drawing/diagramming tool
    - photo display, capture, and edit
    - music playing, recording, and editing
    - video playing, recording, and editing
    - games
    - virtual pets
    - telephone and fax

Concurrency can be found in surprising places.
For example, consider searching for a word or phrase in a word processor.
Chop the document up into N pieces and have each of N processors look in
its piece.  Only really useful for large documents.  But change your
perspective:  what if a document isn't something nailed to a particular
machine?  Think about SubEthaEdit, for example.  Collaborative document
editing over the web.  That's a desktop application right now.

Data base?  The epitome of concurrency.

Photo rendering and editing?  Lots of this is embarrassingly parallel.

Games?  Thread per player, at least.  If it's in a forest, think of
simulating the motion of each tree at the same time (not all trees are
the same).  Think of route planning.  All sorts of stuff.

I've got an application right now, document clustering, where I could
*easily* exploit 16 processors if I had them.


	I just don't now if a chat program, or a web browser, or a file manager, 
	or a document viewer, a game, a multimedia player and all the usual 
	desktop applications need lots of concurrency and can benefit from 
	Erlang or if it would be better to use some thing like C# with the 
	little concurrency it implements.
	
	I think I'll have to learn Erlang and finish my PThreads
	studying, make typical desktop programs with both... and then
	compare :-|. Ocaml is a candidate too from what I've heard.
	
Ah, there's your mistake.  TYPICAL desktop programs already exist!
We already have more word processors than the market really wants.
What we need are NOVEL desktop programs; ones that do useful and interesting
things that don't have saturated markets, and that exploit the new machines
to do things that nobody ever thought of before.

If I could think of such things, I wouldn't be scraping a slender living
as a University lecturer.
	
OK, here's an idea, but I don't think it's a good enough idea to make
money.  Think about someone writing the Great New Zealand Novel on their
computer.  They have a local copy of the Wikipedia (we do have such a
copy here, as part of our information retrieval work) and everything
from Project Gutenberg (I don't have that, but I could if I wanted to).
While they type, the computer is "mentally" chopping their novel up into
"topical" pieces and adding links to relevant stuff in the Wikipedia and
Project Gutenberg.   (We have a masters student who we hope will work on
adding Wikipedia links; this is stuff that can be done *now*.)

The thing here is that the actual text editing doesn't need much computing
power.  What we _really_ need here is fault isolation.  The information
gleaning stuff is *helpful* to the author but not essential; the one
absolutely crucial thing is that if the helpful stuff crashes, it MUST NOT
take the main stuff with it.

Oh, so here's another thing that's happening at the same time.  The changes
are being backed up over the local (wire or wireless) net to one or more
other machines in a P2P sort of way, while the work being done on those
machines is similarly being backed up to this machine.  Again, this is
*today's* technology.  (I warned you I wasn't much good at thinking up
novel stuff.)

Look for opportunities concurrency and you will find them.

Look for opportunities for fault isolation and you will find them.