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

81–90 of 128 posts

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

#81

Post by teo_zero »

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.

I don't think it's fair to talk about "shortcomings" and "getting it right": it's a different approach and we must agree that personal preference will diverge.

Personally, I tend to use action-selection for small changes (1 to 3 objects), and selection-action for larger ones (as my brain, I've learned, becomes slower at counting above 3). So "delete 2 words" will be "2dw", but to delete the next 5 words I'll reach out for "v".

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

#82

Post by bsenftner »

Harvard University used to teach an assembly language class back in the 80's, taught on a mainframe - a VAX 11/780 or similar I seem to recall. This was an open enrollment class, available to evening and summer students. That class was, well it as Assembly, so it was difficult. The homework assignments were odd, seemingly unrelated. At the midterm, the professor handed out a makefile that combined every assignment to date, and if you did your homework correctly, a mini version of Vi was produced. The rest of the class with polishing that version of Vi, all in assembly 11/780. Taught me one hell of a lot!

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

#83

Post by teo_zero »

drbig wrote: post #28

Reminded me of CygnusED, which apparently has even a working website[1]. I really wish the core idea of ARexx had become popular enough. 1: http://www.cygnused.de/index-en.php

There was another editor for the Amiga, possibly only known to the users of Matt Dillon's DICE compiler, that integrated so well with ARexx that at a certain time I suspect ARexx code surpassed the core C code. The name's DME and the source is still available.

I can't agree more on the beauty of a OS-endorsed scripting language embeddable in every application! Lua might take that role one day...

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

#84

Post by porridgeraisin »

bsenftner wrote: post #82

Harvard University used to teach an assembly language class back in the 80's, taught on a mainframe - a VAX 11/780 or similar I seem to recall. This was an open enrollment class, available to evening and summer students. That class was, well it as Assembly, so it was difficult. The homework assignments were odd, seemingly unrelated. At the midterm, the professor handed out a makefile that combined every assignment to…

If you can recall, what were the individual assignments? Would love to understand how the modules added up

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

#85

Post by bsenftner »

porridgeraisin wrote: post #84
bsenftner wrote: post #82

Harvard University used to teach an assembly language class back in the 80's, taught on a mainframe - a VAX 11/780 or similar I seem to recall. This was an open enrollment class, available to evening and summer students. That class was, well it as Assembly, so it was difficult. The homework assignments were odd, seemingly unrelated. At the midterm, the professor handed out a makefile that combined every assignment to…

If you can recall, what were the individual assignments? Would love to understand how the modules added up

Now you've got me digging through archives, I've got all the homework assignments stored. I need to find someone with an exabyte tape reader...

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

#86

Post by chongli »

flomo wrote: post #66
chongli wrote: post #61

Earlier quoted context omitted.

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 ter…

That may be true because 1980s UI scientists were most concerned with building efficient and intuitive UIs for the vast majority of people, not for 1%ers.

I know that I, personally, would not have been able to take some of the notes I took in university if it weren’t for vim and its affordances. Trying to keep up with a fast-writing math professor while typing a complete set of notes in LaTeX would not have been possible otherwise!

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

#87

Post by davemp »

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.

I’m not sure. Command based editing opens more doors than just optimizing keystrokes. There are edits I somewhat regularly do with Vim macros that save me minutes of typing and cognitive burden of examining refactor locations. It’s probably not going to be make or break, but I do think it’s significant in a p > 0.05 sense.

I imagine Vim is only just a local optima too. There are newer editors [0] that are more AST aware that I haven’t been able to fairly evaluate yet (not in the boring corp approved software list).

[0]: https://helix-editor.com/

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

#88

Post by ykonstant »

kzrdude wrote: post #27
behnamoh wrote: post #19

Earlier quoted context omitted.

> ... lua is a game changer... Am I the only one who absolutely hates Lua? Its syntax, the fact that variables are global by default unless you local them, `foo = nil` isn't variable assignment but instead variable unassignment!, etc. There are far better scripting languages than Lua.

well, you could warm up to it by using vimscript first

vim9script is much more approachable while still being native to Vim's internals and idea of text editing. I don't know about using it for things like LSPs though, perhaps an expert could chime in.

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

#89

Post by fuzztester »

ChuckMcM wrote: post #37
ajross wrote: post #29

Earlier quoted context omitted.

TECO was just a DEC line editor, not entirely unlike ed/ex. The idea of TECO managing a display terminal (i.e. the environment in which emacs was written as a bunch of macros) came much later, and really only existed at MIT. Glass TTY terminals were very new in the early 70's. TECO was primarily written to the "Knight TV" system, which was a fancy MMIO framebuffer array hooked up to a PDP-10 that would multiplex a bu…

I was a TECO user on RSX-11M, then switched to FINE (Fine Is Not EMACS :-)) on Top 10 & 20. When I started at Sun I started using vi but on the Amiga I continued to use MicroEMACS which felt a bit like FINE[1]. After Sun I pretty much stuck to vi because it was so much faster over a remote X11 connection than EMACS was. Also used PFE32 for a while on the Amiga, sad that the source for that never made it out. [1] I st…

>Also used PFE32 for a while on the Amiga, sad that the source for that never made it out.

I also used PFE32 (on Windows), and for those who may not know, the acronym stood for Programmers File Editor, IIRC :), and the 32-bit version, probably. It was a nice lightweight text editor. One feature it had, that not many other editors might have had at the time, was the ability to open fairly large text files (for that time, at least).

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

#90

Post by makeitdouble »

teo_zero wrote: post #80
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…

>> 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 Can we learn that if you design something for a constrained environment, it will shine when the limitation is lifted?

We're only seeing the rare examples that worked out well.

For instance you don't want to code in assembly Facebook's backend. Blender would also be a completely different program if it was primarily optimized for the 68000. You usually will want different tradeoffs and architectural choices when the target platform drastically changes.

Post reply on HN