[erlang-questions] erlang for programming a text editor

[Richard O'Keefe]

On Nov 2, 2009, at 3:54 AM, Joe Armstrong wrote:

> On Sun, Nov 1, 2009 at 6:54 AM, Jayson Vantuyl <kagato@REDACTED>  
> wrote:
>> Ted,
>>
>> Well, if I were doing this, I probably wouldn't do it in Erlang.   
>> Text
>> handling in Erlang is byzantine at best, so an editor very well  
>> could be an
>> exercise in pain.
>
> I beg to differ.
>
> In my opinion Erlang is brilliant at handling text - text is stored in
> lists and list processing is blindingly fast and there are large
> numbers of library functions
> that work on lists. A very unpainful experience.

For what it's worth, ermacs has a 'cords.erl' module written by
Luke Gorrie that stores a document as a tree of binaries.

The thing very few people realise is just how very LITTLE help
strings give you for text processing.  For example, back in 1979
a friend of mine wrote a batch text editor for IBM mainframes.
(Think of it as an MVS version of sed(1), but a *lot* dumber.)
It took him 150 pages of PL/I, and he had to fight PL/I strings
every step of the way.  When I started at Edinburgh and had to
learn C, I wrote a version of his program in C, *with* undo,
and it took me something between 10 and 15 pages of C (I no
longer recall precisely).  Why was C so much better?  Because
it DIDN'T have strings.  It had completely general purpose
data types (like arrays), and while it didn't actually help me
much, it didn't get in my way either.  It gave me the _building
blocks_ I needed.

Edinburgh had a succession of text editors written in Pop-2.
There was the "77 editor" written by Boyer and Moore (of Boyer/Moore
theorem prover fame).  The architecture of that was later written up
as a Xerox report that I have somewhere.  Then there was the Pop
Editor, which became the Display-Oriented Pop Editor (DOPE), which
was rather Emacs-like.  (If by any chance Dave Bowen should read
this, hi!)  What data structure did that use?  A list of records,
each with a block of characters and some counters, plus an overflow
area for type-in.  Not strings, as such.
>

> A text editor hardy needs concurrency it should be way fast enough  
> on one core -
> there is no "natural concurrency in the problem" - emacs used to run
> blindingly fast
> on a 40Mz PC with 128KB of memory - it's *not* a difficult problem  
> making
> something like emacs run fast enough (unless you want to use emacs  
> to search
> through GBytes of data, in which case you're probably should not be
> using emacs anyway)

Grepping the R12B-5 sources on a 500 MHz CPU, 84 MHz memory machine
took 20 seconds.  Grepping a 500MHz file took 24 seconds.  On a 2.2 GHz
CPU, 667 Mhz memory machine, the same grep took 6 seconds.  The same
search would take maybe a second using Informatio Retrieval techniques.
The limiting factor on the fast machine seems to be how fast the data
can be pulled off the disc, and more cores would not help.

One of the programs hanging around on my disc is SubEthaEdit,
which is a collaborative editing program.  Every so often I accidentally
invoke it and am reminded of its existence.

What about collaborative editing?

What about fusing version control and collaborative editing?

For code, isn't testing going to get a bigger payoff from multicore?