[erlang-questions] erlang for programming a text editor

[Michael Turner]

"Good design never just happens."

Great bumpersticker line!  Copyright it immediately.

The main useful purpose I can see for using Erlang to implement a
text-editor-cum-general-purpose-shell-programming-environment (Emacs
being exemplary) is to make a promotional statement about Erlang: your
success says, "Look, Erlang is not just great for what it was designed
for, it's also quite adequate for other purposes."

Wings3D already does a pretty good job in that department, though. 
Offhand, I can't think of a good reason to write a 3D modeler in Erlang
specifically.  What Wings3D says, in effect, is that if you just want to
write something complex for fun and learning value, you shouldn't worry
that Erlang would hamper you significantly -- it might make some things
harder, but not prohibitively so.

Wings3D is better than some hypothetical Emacs clone in another
(promotional) respect: your average *user* can relate to it better. 
Emacs grew up in the glass tty days, it's got a face (and a raison
d'etre) that only a programmer could love.  Most people these days
don't even know what you mean when you say "text editor", any more
than they know what you mean when you say "Erlang is Turing-complete."

-michael turner



On 11/3/2009, "Richard O'Keefe" <ok@REDACTED> wrote:

>
>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.
>
>
>________________________________________________________________
>erlang-questions mailing list. See http://www.erlang.org/faq.html
>erlang-questions (at) erlang.org
>
>