
Cloning Vi Using Haskell - fogus
http://blog.objectmentor.com/articles/2009/08/14/vih
======
ewjordan
Anyone else getting real tired of these "Clone of XXX, Using HASKELL!!!"
threads? I'm not impressed that people are able to complete straightforward
programming tasks using a certain programming language; if the users of said
language think I _should_ be, then IMO there's something pretty deficient
about the language.

Edit: Just to be clear, I have no particular problem with Haskell, but it
seems like there's an awful amount of language envy coming from its users, and
a lot of attempts to prove that you actually can program normal things in the
language; but I'd greatly prefer to see examples of what Haskell can do that
would be difficult in Java, Ruby, Lisp, etc., rather than examples where with
great difficulty you can achieve what is trivial in any other language.

~~~
tdavis
Hear, hear. I already have a general-purpose programming language that allows
me to do most things relatively trivially. I want to know why I should add
Haskell to my toolbox, not replace my perfectly good hammer with it. For
instance, I learneda while back that stable, asynchronous, distributed
networking applications are made trivial by the likes of Erlang. That's a good
reason to learn that type of language.

Haskell seems like a nice language, but I'm not yet convinced it is worthy of
a slot.

------
tamas
Also nice Vim-ish editor in Haskell: <http://www.haskell.org/haskellwiki/Yi>

~~~
jrockway
This is the one to look at if you are interested in sane data structures for
representing editable pieces of text.

------
krishna2
Should probably be a good idea to move from String to Ropes.
[http://scienceblogs.com/goodmath/2009/01/ropes_twining_toget...](http://scienceblogs.com/goodmath/2009/01/ropes_twining_together_strings.php)

A short snippet: What works extremely well is to take the basic idea of a list
of mini-buffers (that is, smallish character arrays), and tweaking it, so that
instead of keeping a list of sub-buffers, you put the sub-buffers into a
binary tree. The result is a structure called a rope. To the best of my
knowledge, ropes were invented by Hans Boehm (of garbage collection fame).
Ropes are a simple, elegant data structure that's excellent for representing
large string-like data structures. (The name is a pun: a real-world rope is
made by twining together lots of smaller strings. A data-structure rope
tangles together data-structure strings.)

------
cninja
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.

~~~
viraptor
I don't applaud that. I think that he missed one important step in the design
of a text editor... There's premature optimisation, as in:

"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.

~~~
cninja
Don't confuse "premature optimization" with "no optimization". As you and
jrockway wrote, there certainly are more exotic data structures that are more
appropriate for a text editor, but until there is enough of a text editor to
do actual tests with, then choosing one of the options is premature.

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.

