Erlang for desktop applications?

[Jacobo G. Polavieja]

Richard A. O'Keefe wrote:
> 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.
> 
> 

Your message was very clarifying, thanks.

	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.

I just put the slow "fact" based on what is said on the FAQ:
http://www.erlang.org/faq/x1088.html#AEN1288
As I said I don't have any programming experience with Erlang so I'm 
trying to see if it could fit my interest in developing desktop apps.
I'll look for that thread you've mentioned :).


	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.

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?


	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.

You said it, "some". But how about being the main or unique language in 
desktop developing apps?
My main fear is that, as I have very little experience, I can't thing of 
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 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.

Thanks for all the patience with the newbie...

Cheers.