In Elif Batuman's 2017 novel The Idiot, about a naive Harvard student, her not-really-a-boyfriend Ivan, a math student, enthuses to her about Emacs. The book is set in 1995.
I enjoyed the book. It got good reviews and was a Pulitzer Prize finalist.
Replicator code in Star Gate was iirc (it’s been a good while) the html/js for the royal bank of Canada (appropriate since it was mostly filmed in Canada).
One of the great onscreen code moments was in Superman III¹ where Richard Pryors’ character has written some “impossible” program and when the listing is shown on screen it’s pretty much five screens of BASIC REM statements.
⸻
1. A movie which exists primarily to set up a joke in Office Space.
Note: everything beyond the 30th column is derived from the observed output of the program (which is also shown in the movie), but not everything can be deduced exactly. Specifically, lines 41, 43, and 45 are very likely incomplete.
The program listing ends with line 350, but this is incomplete; the program must has more lines than those shown in the movie. The missing lines have a known functionality, and, infering them from their observed functionality, they could be something like this:
These specific line numbers are merely guesses, except the line number 395, which is known to be the end point, since that is the line number where the program is interrupted.
The listing is also missing line 5000, referenced on lines 20 and 47. I am guessing it may have been a subroutine to play an audible beep.
More great on screen code moments (I haven't got round to Superman III, yet): https://behind-the-screens.tv But Superman III is not just REM statements.
Oh, it’s been a long time since I’ve watched the movie. Unlike I&II it does not bear rewatching, so I’m going by a memory of watching this for the first time in the 80s, probably on TV.
I paused a bunch of times and I forget the details, but I remember everything always looking good, especially his brainstorming about the site and making notes about pgp and onion services and the like.
I also loved them knowing Lenny wrote some code, as he was the only person in the world who uses snake case in javascript, because I’m also a snake case heretic.
Enjoyable list but I’m not sure the AlphaGo documentary counts as pop culture :).
It’s interesting how people talk about vi vs emacs, can’t remember ever meeting anyone who chose vi over vim, let alone enough people to make th at the debate.
> can’t remember ever meeting anyone who chose vi over vim
Pleased to meet you.
Most of my console dev time is spent in *BSD, where nvi is where I land. I find the the default creature-features of vim annoying, so I end up having to configure it to be a bit more quiet, and I don't know anything so compelling about it (a vi clone (to an extreme, acknowledged)) that nvi isn't a good enough place to be. I have vim installed, but it's not my go-to.
For me, it'd be primarily having more than one undo. Not being able to undo the second-to-last change is pretty bad. In fact, vim's undo being set up as a tree that can be walked with g- and g+ is excellent. It's impossible to lose a state of the buffer, even if you undo and make changes. It's a lot more practical to navigate than Emacs' undo, too.
EDIT: I just realized that nvi can undo more than one change by having u toggle the direction and . continue in that direction. I don't think ex-vi could. busybox vi seems like it can undo multiple with u but it seems to have no redo.
> For me, it'd be primarily having more than one undo
Do you mean infinite undo? nvi has that. I'm not sure what you mean "set up as a tree" wrt undo, but i'll look into it. I think of nvi's undo as linear - I can 'u' to "undo" and implicitly set my "undo direction" "backward in time" (as one would expect). If I want to "undo, even more", '.' (dot, period) to "do that last command again" is what I'll do. If I want to "undo an undo", 'u'. That has the effect of moving the "undo direction" back towards the state of the buffer we had at the beginning of our discussion here.
The only times I encounter vi (and so not sure what version, but likely barebones Linux), it doesn't indicate whether you are in insert or normal mode. So I immediately install vim (once possible).
Is that something you just get used to, or was I using some weird vi?
I always assume I am in normal mode unless I am actively typing. If I stop to think I ESC. Then, when I gave thought, I know what I need to do next.
So for me there isn't really any time of looking at the screen and not knowing. And if there ever was some ambiguity I would reflexively hit ESC to get to a known state.
So, not sure it would bother me. But my editor does give me an indication of whether I am in normal, insert, visual, visual block, or Emacs mode.
> can’t remember ever meeting anyone who chose vi over vim
As a sysadmin, I prefer a basic "vi" as in most cases I want quick open/edit/close and don't need fancy colours and such. (I.e., vim.tiny on Deb/Ub rather than vim.basic.)
> can’t remember ever meeting anyone who chose vi over vim, let alone enough people to make th at the debate.
Because vim generally offers everything vi has.
vi does have one advantage though. It's a lot lighter. vim is like 5.4MiB in size with 82 shared library dependencies, while vi[1] is like 260KiB with 2 library dependencies (libc and ncurses).
Right. Sometimes all you need is to edit a couple lines in a config file and get out, in which case hjkl, i/a, and Esc (and then :wq) are all the editor really has to implement. (And a few more movement tools like w/b and so on). Plugins? Colorschemes? You don't need 'em to edit a couple lines in a config file. (I'll grant that syntax highlighting that makes the comments a different color from the actual lines can be helpful, but if it comes at the cost of a much larger binary it's not always worth the cost on those resource-constrained systems).
I traded emacs for vscode several years ago now but this post made me wonder if I'd be insane for dusting off my herd of finely shorn yaks to try typescript dev again with it.
At the time I left for vscode, emacs had a REALLY bad Typescript story and it felt like a revelation doing TS in vscode.
Surely emacs has gotten a definitive TS solution since, idk, 2018? 2019? Right?
I guess so - I use built in TypeScript modes, and integrate with tsc via the built-in LSP client, eglot. Works well. Front-end specialists may disagree.
There's an obscure Polish film from 2002, "Haker" (Hacker), obscure for many reasons and not in a good way; it's absolute drivel, not even accidentally funny in a MST3K, B movie kind of way - it's just really, really bad.
In this gem there is a conversation about hacking into some system, and a character asks another a completely nonsensical semi jargon question, which goes like this: "Did you try Emacs via Sendmail?". I shit you not.
This expression firmly cemented itself into Polish tech speak as a way to refer to or call out someone having absolutely no idea what they are taking about.
That sounds really interesting, would like to read it. Amazon is not an option for me though since they don't let you download your ebook files anymore. Any other way I can get a copy and pay you for it?
I chose the DRM-free route on Amazon for "Means & Motive" ( https://www.amazon.com/dp/B0GYCZJVGX ) . Self-published authors can choose to be DRM-free on Amazon now. You can also buy it via Barnes & Noble (paperback), links here: https://frequal.com/novels/
Nice. I've never seen any of these things except for Tron: Legacy; and I either didn't notice it was Emacs or immediately forgot if I did (you could also sorta take it to be tmux or something if you don't look closely enough to see the *eshell*). But this is the sort of thing I would generally never let my acquaintances hear the end of if I spotted :)
Same on the not spotting emacs, I was too focused on the fact that the commands looked right. (A `ps` to find out which process it was, then a `kill -9` of the PID). It was nice to see realistic Unix commands rather than Hollywood Hacking, for once.
> In a scene (Season 3, Episode 6) where protagonist Richard is coding with his new girlfriend Winnie at her apartment (okay, yeah… that’s not how all software engineers date, whatever the outside world may think), the two clash over the use of spaces versus tabs. Richard, a stubborn advocate of the tab character for indentation, argues: “I mean I do not get why anyone would use spaces over tabs. I mean, why not just use Vim over Emacs?” To which Winnie replies, “I do use Vim over Emacs.” Richard then breaks down, yelling, “Oh, God help us!”
Gotta admit that I use Emacs and favor spaces over tabs. And K&R braces. And you’re wrong if you make any other choice.
waves Vim and spaces over here as well. Emacs is a great tool, I just can't stand its keyboard shortcuts. In theory I should try out evil mode, but I've got NeoVim configured how I like it and I don't want to spend the time on switching.
As for tabs vs spaces, in theory, tabs are more flexible than spaces and allow everyone to view the file with their preferred indentation levels. In practice, I have only seen one codebase — ONE — in all my years of programming that was using tabs and yet did not end up with spaces getting mixed in with those tabs at some point along the way. (In the indentation, I mean: obviously once the non-indentation part of the line starts, you want spaces there). And that codebase had precisely two people committing regularly to it. Occasional PRs from other contributors, but only two primary maintainers.
Every other tab-using codebase I've seen (of non-trivial size and complexity, that is), someone, somewhere, had been lazy, or had a misconfigured editor, or something, and spaces snuck into the tabs. The worst offender I ever saw was a file that had been edited by multiple people over the years, who must have had different tab settings in their editors. There was one section where they had tried to line up a bunch of variable assignments and values. (Yes, I know, bad idea, but stick with me for a minute, I'm getting to the punchline). None of the pieces of code that were supposed to line up were actually lined up. (This was C# code, so indentation didn't truly matter like it would in F#, or Python, or ... well, I won't list all of them since I'm trying to get to the point). Here's the really hilarious part. I tried all sorts of tab settings to see if I could get that file to line up. I tried 8. I tried 4. I tried 2. I even tried 3, the setting for the people who can't make their minds up between 4 and 2. Then I tried really oddball settings like 16, 5, or even 7. Nothing worked. There was no tab-size setting I could use that would make the code line up. Which entirely negates the whole point of tabs, that you can set your own indentation.
That was the day I said "Forget about tabs, just use spaces, you won't have that problem with spaces." Tabs have great promise, but in practice, in my experience at least, you end up having to tell your colleagues "hey, you need to set your tabs to 4" (or 8, or 2, or ... well, you better not be using any other numbers) "before editing this file". Which basically negates the whole point of tabs. They're great in theory, but I've only seen ONE codebase that made them work in practice.
I’ll overlook your poor choice in editors. :-) The rest of this is spot on. Yea, that’s bad. A project like that screams for a code formatter to be plumbed into a pre-commit hook. Like you say, I’ve never really found a great argument for tabs either, and with more and more indentation-sensitive languages, any argument to the effect that programmers can choose their own indentation really goes out the window. These days, I program in Clojure with Emacs’s aggressive-indent-mode minor mode. It re-indents the whole top-level function you’re working in every time you pause typing. It keep everything properly indented pretty much all the time. Sometimes your commit diffs will be larger, though.
These days .editorconfig compliance is everywhere, thankfully, so there's a cross-platform solution. At least for that bit. (Note that while usually "cross-platform" means OS's, this time it means editors).
I was a diehard spaces-over-tabs person until I saw this scene in Silicon Valley. I had rather naively assumed that the tab-indent default in emacs was an oversight rather than a considered decision. This scene actually educated me.
A long time ago I was doing some on-site programming at a swiss bank, and the only available editors were vi on a Sun, or EDIT on a VMS machine (the project involved both.) I learned rudimentary vi on the fly while waiting for ftp-by-mail-over-uucp to deliver GNU emacs sources :-)
There's two reasons for this, I think. The most obvious is that emacs has better CJK support compared to any other editor of the time. The less obvious is that Japan liked lisp machines and lisp in general a lot
Notably, Yukihiro Matsumoto took substantial inspiration from Lisp while designing the Ruby language. You can see historical Lisp terminology in the Ruby interpreter sources (at least last I checked, which was a long time ago), like the use of “Q” to refer to a dynamically typed datum that can be stored in a cell.
(Hah, I just looked around a bit more, and Wikipedia cites an archived mailing list message that I don't remember seeing before: https://web.archive.org/web/20181027195101/http://blade.naga... I remember at some point Emacs Lisp specifically being cited as an inspiration, but I might be confabulating that, I didn't find a source for it.)
Also, here's a fun paragraph from the opening comments of quail.el (lightly reformatted):
> [There was an input method for Mule 2.3 called ‘Tamago’ from the Japanese ‘TAkusan MAtasete GOmen-nasai’, or ‘Sorry for having you wait so long’; this couldn't be included in Emacs 20. ‘Tamago’ is Japanese for ‘egg’ (implicitly a hen's egg). Handa-san made a smaller and simpler system; the smaller quail egg is also eaten in Japan. Maybe others will be egged on to write more sorts of input methods.]
Just yesterday I stumbled across an article from 2005 titled "Why Ruby is an acceptable LISP": https://www.randomhacks.net/2005/12/03/why-ruby-is-an-accept.... I don't agree with all of his points about macros, e.g. I think his line about "The most common use of LISP macros is to avoid typing lambda quite so much" is simply incorrect. But his point about how Ruby allows building DSLs, and so it gives you quite a lot of what you want from Lisp macros, is broadly correct, I think.
Having skimmed the article, I think he's correct about the most common use of macros (by far the single most common type of macro I write in CL is a body-to-lambda transformation, though being able to tweak the sugar makes a difference too), but then I think he kinda equivocates in implications between “80% of the usage” and “80% of the impact”. I also think Ruby DSLs cover a big chunk of that last gap (and it sounds like you might agree with me). Part of the classic Lisp Curse is that easy access to advanced metaprogramming indirectly increases social fragmentation, but part of the Blub Curse is that lack of access to advanced features causes people to have to solve the same dumb problems over and over again, so you lose efficiency and create different fragmentation. Having fancier metaprogramming functionality require a bunch of rigamarole but be possible to work through when you need it might plausibly hit a sweet spot in the middle there.
Now that I've read through the Common Lisp HyperSpec and realized that there's no standard shortcut syntax for lambda, you have to spell it out every time (or define l as lambda), I'm realizing that yes, that is probably the most common use. I'm also starting to understand why Janet has the `short-fn` macro with special reader syntax for it: |(> $ 0) is short for (lambda (x) (> x 0)), which is SO much less typing. (It also handles multiple arguments: you can say |(> $0 $1) if for some reason you're allergic to just typing > to accomplish the same thing).
In fact, I think next time I'm writing Common Lisp code, I'm going to figure out how to create Janet's | as a reader macro.
FWIW, the common utility library Serapeum offers ‘op’ which it claims is from GOO, which is quite similar as a short positional function utility macro without being a reader macro that has more potential for character clashes: (op (> _ 0)). (But don't let that stop you from recreating it if you wanted to do so for educational purposes!)
> EMACS, Electromagnetic Control and Survey, is an AIM (aeronautical information management) tool that applies advanced simulation techniques to perform airport and Enroute electromagnetic environment analysis as well as airport and en-route electromagnetic site verification.
IIRC there’s another scene in Silicon Valley where they have a post-it board of feature ideas for their software and one of them is “emacs keybindings.”
I enjoyed the book. It got good reviews and was a Pulitzer Prize finalist.