[erlang-questions] erlang for programming a text editor

[Richard O'Keefe]

On Nov 2, 2009, at 8:20 PM, Alpar Juttner wrote:
>      * Several years ago, I had gave up using a Emacs-RMAIL, because
>        fetching new mail took a long time on our environment and this
>        process blocks the whole emacs.

I use "Mail" version 3.6 on a 2.2GHz intel Mac running MacOS 10.5.7.

I can assure you that l o  n   g     pauses to fetch new mail are
by no means confined to Emacs.  Activity Monitor reports that Mail
is using 12 ... no wait ... 11 threads, no wait, it's 12 again.
So simply having and using concurrency is no guarantee that you won't
get long waits.

Our sysadmins made a unilateral decision to move everyone's files off
their local machines onto a file server.  There are now frequent
jarring waits while Mail waits for a file server in order to touch
some file I don't particularly want it to touch at that time.

The fundamental issue is *system design*.  It's thinking about what  
kinds
of delays there might be and arranging for the program to let you do
something else (such as compose a message) while that's happening.  For
this, threads are a great help, but not a necessity.  (Well, you _could_
write the whole thing in assembly code (:-) (:-).)
>

> An inherently concurrent design would immediately eliminate all of  
> these
> issues.

Mail is evidence that an inherently concurrent design *as such* need not
eliminate *any* of these issues.  Concurrency makes it *easier* to  
create
good designs, but good design never just happens.