Cloning Vi Using Haskell | Hacker News Reader

Cloning Vi Using Haskell

blog.objectmentor.com

26 pointsfogus14 comments

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.

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.

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

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

Yi is more of a Vim/Emacs hybrid. It's supposed to take the good from both, and hopefully come out with something nice.

From the little I used it, the frontends are supposed to be transparent replacements for Vim/Emacs. It is, however, a work in progress.

Should probably be a good idea to move from String to Ropes. http://scienceblogs.com/goodmath/2009/01/ropes_twining_toget...

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

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.

Yeah, Vi is most likely full of clever optimisations as to how text is stored and drawn on the screen. Why reinvent the wheel?

this stuff is not reinventing the wheel. it is just building your own wheel, to better understand how it works. and other people (like i.e. me) like it, because then they don't have to write C, when they want to hack a little bit into the programs they use.

Sorry for saying that!

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.

It's a rite of passage.

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.

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.

Without premature optimization, there isn't much of anything interesting going on. This program reads a key, copies the string up to the pointer, appends the character that was typed, and then prints that string to the screen.

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.

Reply on news.ycombinator.com