Hacker News Reader

Comment by stryan | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com