Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding the Origins and the Evolution of Vi and Vim

pikuma.com

Post reply on HN
Print view View original

61–70 of 128 posts

Re: Understanding the Origins and the Evolution of Vi and Vim

#61

Post by chongli »

flomo wrote: post #54
sudahtigabulan wrote: post #45

Earlier quoted context omitted.

> It's incredible how good of a design Vi is. It's interesting how this design was forced into existence by the extremely limited hardware at the time: TFA>> It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. That's why we got commands lik…

That's a great point. On modern systems, there's a false economy where editor stunts are not going make most people a significantly faster programmer. (Although some ppl just like them, e.g thinking they are "more powerful".) But on a very slow terminal, these things really did make a huge difference.

For people who love vi/vim, it's not really about being "a significantly faster programmer." It's about reducing friction between the changes you want to happen and them happening on screen. Editors with a lot of friction (that make you do lots of intermediate or repetitive steps to accomplish a task) can be really annoying to use. For some people, minor annoyances can be very distracting to the point where they take you out of your comfort zone and break your concentration.

Having your concentration broken when you're trying to solve a tricky problem can be a huge productivity drain. So in the end, an editor which may only save a keystroke here and there on average can end up being very productive for some people.

Re: Understanding the Origins and the Evolution of Vi and Vim

#62

Post by bakul »

Animats wrote: post #44

The ancestor of all those full screen terminal editors is the RAND editor, which was on Unix around 1974.[1] Few people outside the DoD research community saw it, because it wasn't free and only worked on some terminals. Functions were triggered by dedicated function keys, not key combos or a command line, and it was customary to use something with 8 to 10 function keys, such as the HP2645A. You could split the scree…

I used the rand editor in early 80s & loved its “infinite” quarter plane model. Dave Yost enhanced it quite a bit and called it the Grand editor. But it was hard to maintain as it relied on K&R C. Eventually I gave up and went back to vi.

Re: Understanding the Origins and the Evolution of Vi and Vim

#63

Post by eimrine »

sudahtigabulan wrote: post #45
qsort wrote: post #6

It's incredible how good of a design Vi is. Try this experiment: Busybox includes a tiny clone of vi with a reduced feature set. It's very stripped down when compared to Vim or even other vi clones, but as a pure text editor it's still more powerful than most modern day IDEs . I love my Jetbrains IDEs, but you can take my Vim plugin from my cold dead hands :)

> It's incredible how good of a design Vi is. It's interesting how this design was forced into existence by the extremely limited hardware at the time: TFA>> It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. That's why we got commands lik…

> That's why we got commands like d), d{, D, etc. Trying to achieve the goal in one go, without any intermediate redraws.

This is 1/2 of explaining why vi family is the GOAT. The remaining explanation is that vi family is the only text editor which is able to be used completely without looking at the keyboard or touching the mouse even once. You can not achieve this if you have to use accord commands which are typically binded to what is selected by mouse. No vim-less text editor can ever provide one-click analog of o command (make a new line under the cursor from wherever column the cursor is at the moment of clicking).

Re: Understanding the Origins and the Evolution of Vi and Vim

#64

Post by gustavopezzi »

ngcc_hk wrote: post #2

I was surprised to see this on pikuma… I guess “ Also... Emacs sucks! ” is ok to end the blog entry. To me it is just hard to use 2-3 figures and it seemed hard for inventory as well. That sucks.

Author here! I remember struggling with the decision of adding that last sentence or not. But at the end I was sure most readers would get that it is obviously a joke. Maybe a bad one but still a joke.

Re: Understanding the Origins and the Evolution of Vi and Vim

#65

Post by codesnik »

arbitrandomuser wrote: post #57
sudahtigabulan wrote: post #45

Earlier quoted context omitted.

> It's incredible how good of a design Vi is. It's interesting how this design was forced into existence by the extremely limited hardware at the time: TFA>> It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. That's why we got commands lik…

This imo is a shortcoming of vim on modern systems, the action precedes the selection. I would like to select first have a visual feedback of what I selected before taking action on it . Helix and kakuone have got this right . I often find myself going to visual mode to emulate this.

it's not "emulating", it's exactly what you describe. And it's just one additional "v" away, can't be shorter than that.

Re: Understanding the Origins and the Evolution of Vi and Vim

#66

Post by flomo »

chongli wrote: post #61
flomo wrote: post #54

Earlier quoted context omitted.

That's a great point. On modern systems, there's a false economy where editor stunts are not going make most people a significantly faster programmer. (Although some ppl just like them, e.g thinking they are "more powerful".) But on a very slow terminal, these things really did make a huge difference.

For people who love vi/vim, it's not really about being "a significantly faster programmer." It's about reducing friction between the changes you want to happen and them happening on screen. Editors with a lot of friction (that make you do lots of intermediate or repetitive steps to accomplish a task) can be really annoying to use. For some people, minor annoyances can be very distracting to the point where they take…

Absolutely, some people just love vi. Sometimes it fits their mental model, other times someone told them "real programmers use vim/emacs" and so they internalized and studied it. That's why most modern editors still have a vi mode. Obviously it works for people.

But if the 1980s UI Scientists came back with their stopwatches, I don't think the median vi-mode user would "win". Unless they were using a really slow terminal. (obv, we probably have some 1%ers on HN)

Re: Understanding the Origins and the Evolution of Vi and Vim

#67

Post by Izkata »

chongli wrote: post #61
flomo wrote: post #54

Earlier quoted context omitted.

That's a great point. On modern systems, there's a false economy where editor stunts are not going make most people a significantly faster programmer. (Although some ppl just like them, e.g thinking they are "more powerful".) But on a very slow terminal, these things really did make a huge difference.

For people who love vi/vim, it's not really about being "a significantly faster programmer." It's about reducing friction between the changes you want to happen and them happening on screen. Editors with a lot of friction (that make you do lots of intermediate or repetitive steps to accomplish a task) can be really annoying to use. For some people, minor annoyances can be very distracting to the point where they take…

I don't think it's even so much about keystroke count as it is the "commands" are more like a language that you can keep getting better in. For example, from above:

> d), d{

That's not two different commands, it's one action (delete) and two different motions (forwards one sentence, backwards one paragraph). Motions work on their own for moving the cursor, but can be combined with different actions and repetitions to multiply the sentences (commands) you can make. As you increase your vocabulary over time (there are a lot of motions and selectors (which are slightly different but used similarly)) you can keep reducing that friction between thought and screen.

Re: Understanding the Origins and the Evolution of Vi and Vim

#68

Post by Izkata »

codesnik wrote: post #65
arbitrandomuser wrote: post #57

Earlier quoted context omitted.

This imo is a shortcoming of vim on modern systems, the action precedes the selection. I would like to select first have a visual feedback of what I selected before taking action on it . Helix and kakuone have got this right . I often find myself going to visual mode to emulate this.

it's not "emulating", it's exactly what you describe. And it's just one additional "v" away, can't be shorter than that.

It's the same for selections, but motions are a little different. To use an example from above, d) is "up to" the next sentence (excludes the first character of the next sentence), while v)d moves the cursor onto that first character and so includes it when deleting.

Re: Understanding the Origins and the Evolution of Vi and Vim

#69

Post by nottorp »

sudahtigabulan wrote: post #45
qsort wrote: post #6

It's incredible how good of a design Vi is. Try this experiment: Busybox includes a tiny clone of vi with a reduced feature set. It's very stripped down when compared to Vim or even other vi clones, but as a pure text editor it's still more powerful than most modern day IDEs . I love my Jetbrains IDEs, but you can take my Vim plugin from my cold dead hands :)

> It's incredible how good of a design Vi is. It's interesting how this design was forced into existence by the extremely limited hardware at the time: TFA>> It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. That's why we got commands lik…

That's the only reason I know some vi commands to be honest.

It's unbeatable when editing files on a remote server in a hurry and from random places that may or may not have good latency and/or bandwidth.

Re: Understanding the Origins and the Evolution of Vi and Vim

#70

Post by nikanj »

qsort wrote: post #6

It's incredible how good of a design Vi is. Try this experiment: Busybox includes a tiny clone of vi with a reduced feature set. It's very stripped down when compared to Vim or even other vi clones, but as a pure text editor it's still more powerful than most modern day IDEs . I love my Jetbrains IDEs, but you can take my Vim plugin from my cold dead hands :)

As a pure cutting tool, a traditional saw is more powerful than a chainsaw.

That doesn’t mean it’s actually the fastest tool for the real job. Programming is not text editing

Post reply on HN