I applaud his efforts to avoid premature optimization. It's amazing how fast computers have become; storing the buffer as a string and that string gets regenerated every time a key is pressed.
"I'll use a nice, buffered storage split in chunks that can be written back to disk to save memory... Even if it's going to be used for a field that accepts max 1KB of text."
And there's proper design:
"I'm writing a program which main/only purpose is to operate on text efficiently. That means I'd better create a good file/text abstraction up front, because otherwise I'll have to rip the whole thing apart and reassemble once people start using it for something longer than 1MB"
There's another haskell editor with vi-keymap and command-mode available - Yi. I think they're using the rope concept to deal with big files.
From what I read, the programmer's intent was not to write the most efficient editor, but to write an editor and see how the internal program structure will evolve as it becomes more efficient and/or feature rich. That knowledge and experience is sometimes more valuable then knowing what data structure to use.
Yeah, it's Haskell, but who cares? Of course it's easy to write simple programs in Haskell.
When you start using more exotic data structures, like ropes (or difference lists), that's where Haskell really shines, and would actually be interesting.
For me, the most interesting thing about this article is that it's on the Object Mentor website.
I too wrote my own editor in Lisp 2 years ago, and also wrote one for the Z80-based Z88, but that was too slow, although the Lisp version was okay. But the Z88 (6Mhz Z80) would have required a lot of optimisation and it was my lesson about how what can seem easy requires tons of special cases.
But writing an editor is a good way to learn some things about computer science.