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?
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.
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.
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.
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.
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.
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.
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.
> 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).
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.
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 :-)
> 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.
[1] https://news.ycombinator.com/item?id=48447484
I always whenever I see code on a show/movie I wonder if it's real, a lot of times it's a mix of random languages. Sometimes just jibberish.
Also recently watched Nirvana 1997 really good.
https://www.theterminatorfans.com/the-terminator-vision-hud-...
⸻
1. A movie which exists primarily to set up a joke in Office Space.
Also, we're really close to the 24 year anniversary of "Dilemma": https://hollawhenyougetthis.com
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.
And sometimes it's just a directory listing.
I enjoyed the book. It got good reviews and was a Pulitzer Prize finalist.
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.
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.
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.
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.
...and, now I see your edit ;)
^[u..........:wq
:h undo-branches
There's also a plugin to show a visualization of the tree, but the tree is implemented within vim.
https://github.com/mbbill/undotree
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).
[1] https://ex-vi.sourceforge.net/
https://k.japko.eu/busybox-vi-tutorial.html
https://dev.to/hyenast2/neal-stephenson-s-cryptonomicon-and-...
(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.]
And now it's more clear to me why that is.
Vim and Emacs barely overlap in functionality.
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.
(With you on spaces, though.)
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.
We know Sick Boy (Zero Cool) would be an emacs user.
https://www.youtube.com/watch?v=D1sXuHnf_lo
Interview with an Emacs Enthusiast [Colorized]
https://www.youtube.com/watch?v=urcL86UpqZc
Writing an Emacs implementation in C (Gosling Emacs) | James Gosling and Lex Fridman
https://www.youtube.com/watch?v=wA7aB-oxjVc
At risk of being downvoted into oblivion by the emacs gang, I wonder if someone’s got a similar theme for vim?
https://web.archive.org/web/20120502000130/https://jtnimoy.n...
This is from the person who wrote the original article on Emacs.