[dasyatidprime]

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.]

[rmunn]

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.

And now it's more clear to me why that is.

[dasyatidprime]

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.