4 ms·

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 regener

by cninja 17y ago

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.

zandorg 17y ago
Yeah, Vi is most likely full of clever optimisations as to how text is stored and drawn on the screen. Why reinvent the wheel?
- erikb85 17y ago
  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.
  - zandorg 17y ago
    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.
    - spudlyo 17y ago
      It's a rite of passage.
viraptor 17y ago
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 17y ago
  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.
jrockway 17y ago
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.

by cninja 17y ago

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.

zandorg 17y ago

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

erikb85 17y ago
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.
- zandorg 17y ago
  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.
  - spudlyo 17y ago
    It's a rite of passage.

viraptor 17y ago

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 17y ago
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.

jrockway 17y ago

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.