Hacker News Reader

Comment by silicon2401 | Hacker News Reader

An immediate flaw with this course is only suggesting VIM. Why not Emacs and Nano? I despise VIM and absolutely adore Emacs, but after getting emacs pinky have transitioned to nano for light editing needs, Sublime for universal productivity, and Intellij for Java development.

If you're only going to teach one editor, why an editor that's so arcane in comparison to something similar to a text editor like Sublime or Atom? If you're going for a terminal-compatible editor, why not Emacs or Nano? If you want the most workplace-ready tool, why not Intellij or VS Code? And my main question, why not at least teach a few and empower the users to really explore and find the best tools for them? To me this smells of people who don't want to help students equip themselves for success and instead want to teach them the "right" way to do things.

View on HN

If you read the article, you'll see their explanation: Vim is the most popular command-line editor (from a Stack Overflow survey) and all of the instructors know how to use it. The course is pretty *nix based so it makes sense to pick a command line editor and focus on it.

Pragmatically, Emacs is usually not installed by default on Linux systems and Nano sometimes isn't. If you had to pick a command-line editor to teach, Vi/Vim is probably the safest bet.

Emacs is where ever I control the base images. But yeah, vi (if not vim) is ubiquitous. And honestly, the "time to be able to edit basic files and do basic stuff" is shorter for vi than emacs. If only because emacs documentation wants you to understand their 1980s conceptual framework before telling you the keystrokes you need.

Emacs is like 10x the size of Vim (and also a lot bigger than nano). It’s rare that I ship a editor unless the OS already had one installed, but I don’t think I’d ship emacs if I needed one.

(Unless you mean for workstations or servers people constantly log into, as I’m thinking of containers).

And that isn't even an issue in practice for emacs users. We're going to use tramp for most things, and are comfortable enough with vi or nano to do any quick edits over shh. But having students try to learn emacs while setting up tramp is a bit much to ask when learning the basics of ssh and vi works just fine. It also doesn't risk students getting confused about the unix fundamentals by throwing emacs–a lisp machine masquerading as an editor–into the mix.

My wife had been a software engineer in the 90s and now is a painter. When we met, she had a brief idea to return to programming (she is PhD physicist also, so certainly smart enough). I had only recently met her, and I was so happy, I set up emacs, scheme, and the Structure and Interpretation of Computer Programs for her and tried to explain how awesome and sensible it all was. Not a good idea, we barely survived that relationship error. She did laugh at it recently (about 7 years later). I still maintain that SICP is essential reading, but only say it at parties.

I learned emacs over some months; I had a job as the IT support guy and I wanted to become a Unix C developer, so I grabbed an unused HPUX workstation, sent all my email to emacs, and then spent months learning how to use it. Probably six months before I was using it decently well.

Yeah, I feel like a lot of us emacs users have been using it for so long that we don't even realize how different even the basics feel to people that are used to doing things the 'new fashioned' way. I picked it up after reading all of Steve Yegge's emacs blog rants, so I already had my interest peaked and had a good idea what I was getting myself into. I also wasn't expecting to get any serious work done with it, I was just curious about lisp and functional programming and wanted to dick around with emacs to see what all the fuss was about. After that I was hooked. I count all the hours of rewriting my emacs configs from scratch or typing in every function from SICP as time well 'wasted', but I fully understand why not everyone considers that type of thing to be something fun to do on a lazy Sunday.

Well, for containers, I'll read the source code/Dockerfiles in my local emacs, and download the logs from where ever, so yeah I don't put emacs into the containers. But I maintain VM base images and they all have emacs. In the container, I like to put in tcpdump and strace and like tcptraceroute and that sort of thing. But hoping for a life where containers never need checking on their compute/network/memory issues.

>If only because emacs documentation wants you to understand their 1980s conceptual framework before telling you the keystrokes you need

which is honestly fair because emacs is essentially a full-on lisp machine with a set of excellent text editing utilities.

The elisp concepts are good, but which things are windows and frames and buffers is just a bit esoteric now. And they are dogmatic in tone that you shouldn't be able to work without passing some sort of worthiness test.

I wouldn't say they're esoteric, but there is a learning curve because they're incongruent with the UI we've been taught by our graphical desktop environments. I do concede the somewhat dogmatic tone, but that's honestly just par for the course with any GNU software, though emacs is for sure one of the worst offenders. I still love it though, but wouldn't recommend it to anyone that isn't already expressing interest in giving it a try.

The point of the course is to teach CS students how to use their tools. Are they expected to only use tools available on every single linux system by default? Are they also expected to not download anything else that isn't universal across unix systems? Not being aggressive, just pointing out how I think it's still a biased choice. I despise Vim but I wouldn't teach Sublime-only, I'd give a brief overview of vim, emacs, sublime, vs code, and let students choose.

Well, they answer this: "Visual Studio Code is the most popular editor. Vim is the most popular command-line-based editor.... All the instructors of this class use Vim as their editor. Vim has a rich history; it originated from the Vi editor (1976), and it’s still being developed today. Vim has some really neat ideas behind it, and for this reason, lots of tools support a Vim emulation mode (for example, 1.4 million people have installed Vim emulation for VS code). Vim is probably worth learning even if you finally end up switching to some other text editor."

So, basically, it's popular, useful, and they know it. But, even before saying that they provide this caveat: "As programmers, we spend most of our time editing code, so it’s worth investing time mastering an editor that fits your needs." Then they devote a little of time explaining how to best learn any editor.

Also, in the QA they say "The three of us use vim as our primary editor but Emacs is also a good alternative and it’s worth trying both to see which works better for you.... An advantage of using Emacs is that extensions can be implemented in Lisp, a better scripting language than vimscript, Vim’s default scripting language."

I'm always sad when I ask interviewees about their editor and they don't have much to say.

Wild guess: the purpose of that module is to learn how to use a real editor on the command line. Which is available everywhere and has been installed by default on nearly every environment I've ever logged in to. Not to broadly introduce the many editors we have available in the world.

> Why not Emacs and Nano?

Time. It's supposed to be over their IAP which is about 4-5 weeks or so.

This is a continued course just put together by a bunch of grad students of things they have to learn on the side or not emphasized enough.

Ah, I didn't look at the dates. For those who don't know, IAP is Independent Activities Period and there are lots of talks, credit and non-credit courses and mini courses, other activities and so forth. So this is a perfect thing to slide in there.

In the last two lectures (Potpourri, Q&A), they actually have a grad student that uses Emacs go over it as well. The TA that was in charge of the editor section was just a Vim user and he wanted to show what kind of things are possible with a highly configurable editor like Vim/Emacs, so he naturally was going to use what he was most comfortable with. He even mentions that Emacs is capable of doing pretty much everything that he goes over in his demo and that it's mostly a matter of personal preference.

There are vim bindings in most (if not all) popular IDEs so learning the base keystrokes can be lifted up to these at a later point.

They did explain that they based there decision based off the most popular command line editor (based on a stack overflow survey). Although it would probably be good to at least reference other popular / useful ones for exploratory purposes, for a quick overview course I think focusing on vim makes ample sense.

Emacs bindings are also included by default in unix and Mac across all text fields, including browsers. Not arguing, just pointing out that I still think it's intellectually lazy. I detest vim every time I use it, and even when I was a CS student it wasn't that difficult to just learn how to use emacs or notepad++. The hard part is gaining the awareness, and that's what I would imagine one of the goals of teaching should be.

I suspect I'm not the only one who was introduced to vim because it's the default for git. This alone makes it good CS101 stuff.

I don't think they really advocate for vim to be your daily driver for all editor needs. Just a "you should know a thing or two about what this is because you're going to be lost the first time git shoves you into a vim editor" sort of thing.

It's a student run course, so I assume one of the reason they selected VIM is that instructors were proficient in it.

It's also one of the few modal editors out there, and that's a different paradigm students might not have been exposed to. In comparison, Emacs is much more similar to Sublime or VSCode (always insert, functions invoked via shortcuts).

I had some emacs pinky and for a while had a script setup to make the spacebar plus a key act as control (releasing spacebar without a key pressed would just be a space). Eventually I recovered and learned to be more gentle with my pinky.

vi still is and always will be the lingua franca of editors; the only more so is ed(1)

Back in my day we were "real programmers" and edited files by precisely waving magnets over our hard disks. Sure we still had some dinosaurs around that longed for the days of swapping out sector gears on their difference engines, but they were harmless enough so we kept them around for the amusement.

Reply on news.ycombinator.com