[erlang-questions] erlang for programming a text editor

[Torben Hoffmann]

Hi,

Since
"Look, Erlang is not just great for what it was designedfor, it's also quite
adequate for other purposes."
is part of the reason for wanting to inflict almost infinite pain on
one-self - I mean, writing a text editor is hard work - I would like to
point the attention to the original domain Erlang was supposed to address
(nice form @ http://en.citizendium.org/wiki/Erlang%27s_original_domain):

   1. Handling of a very large number of concurrent activities
   2. Actions to be performed at a certain point in time or within a certain
   time
   3. Systems distributed over several computers
   4. Interaction with hardware
   5. Very large software systems
   6. Complex functionality such as feature interaction
   7. Continuous operation for many years
   8. Software maintenance (reconfiguration et cetera) without stopping the
   system
   9. Stringent quality and reliability requirements
   10. Fault tolerance both to hardware failures and software errors

My argument, as that of many others smarter than me, is that whenever you
have a problem domain that has needs that matches with the above list then
Erlang might be the tool to use.

Web servers, instant messaging and enterprise messaging are other areas that
have similar requirements, and - surprise, surprise - quite a few Erlang
solutions has turned up in these areas.

Final remark: if you are going to invest your time and energy into something
why not solve a new problem and try to make some money in the process?

I love Erlang,
Torben - High Priest of Erlang (self-proclaimed)


On Wed, Nov 4, 2009 at 03:55, Michael Turner <leap@REDACTED> wrote:

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


-- 
http://www.linkedin.com/in/torbenhoffmann