Lol, how are you so smart and figured just everything out, so already? I'd be so bored to ever touch the keyboard again. Bless Turing I'm so stupid and simple and keep trying different things just to see how they differ.
Emacs is not an editor. It's a Lisp-powered text orchestrator. It allows you to read, write, ocr, encrypt, decrypt, compile, debug, profile, browse, rss, email, calendar, track, journal, publish, tangle, run, query, spawn, multiplex, ssh, edit, diff, merge, blame, rebase, stage, review, chat, note, link, roll, play, run, preview, transcode, transcript, evaluate, redefine, introspect and rebuild anything in your computational vicinity - local and remote machines.
OMG. Don't let me even start here. Corporate IT cultures sometimes are so exhaustingly cretinous. With straight faces they'd perform "security theatre" that has nothing to do with security, but is still just so infuriatingly time-consuming and ignorant on even most basic things. Honestly, I am so thankful to Emacs for cultivating a hacker's mindset in me, otherwise I'd be so freaking burned out all the time if I didn't know how to bypass most of the nonsense they enforce on everyone. I even asked my IT guy once: "I don't get it, don't they realize that devs are just gonna play along with this bullshit maybe a couple of times and then they'll just fucking script a workaround? I for sure will...", and he was like: "I know, it is so stupid, but hey, I don't make these decisions here..."
What a nightmare. The day anyone tells me not to use a specific editor regardless of what it is, I'd be opening their suggested one to type my resignation letter. And not because I love Emacs, Vim or whatever.
I mean I'd understand enforcing using specific tools while pair-programming, mentoring, etc., but not allowing a software engineer to use whatever editor they are most comfortable using at all is not even dystopian, it's simply imbecilic. How are they supposed to not just "perform" but to get any shit done at all? It's equivalent of hiring a secretary and asking them to type everything in Hebrew (a language they have zero awareness of), using Dvorak (a layout they've never tried) and then complaining that their typing speed is undesirable.
How the fuck do these people even get to managerial positions? How in the world are these kinds of companies and company cultures not bankrupted themselves out of existence?
I feel you're now contradicting your own statements now. You said: "[maybe] Lisp is just another Blub", but when pointed out that Lisp (and Lispers) is evolving, you're saying "pg clearly meant [the other Lisp]"...
Of course we're not talking about "parenthesis". Clojure even added square brackets for arguments and destructuring, it's not about the syntax, I agree on that.
> don’t change anything significant about the REPL user’s experience
Perhaps you have never tried/heard of nextjournal/clerk, scicloj/clay, djblue/portal, vlaaad/reveal or just simply tried building a simple web scraper with Playwright running on nbb. Oh, and hyperfiddle/electric - something like that would not be very trivial without homoiconicity.
Most Lispers I met do actively write in multiple languages all the time. They tend to borrow ideas from other PLs instead of loathing everything else that's not their favorite. They prefer Lispy syntax, but won't reject a language to achieve a goal - they'd pick everything - runtime, tooling, etc. and try to find a Lispy syntax that sits atop. While preserving all the remaining semantics. And then they'd argue that syntax does not make a language. Perhaps, Lispers are the largest demographic of polyglot programmers in the global community.
Oh wow, how quickly you changed from being "a good citizen containing an asshole" to being an asshole on your own. Good job, keep checking your mailbox, your medal should arrive shortly.
Implementing C-like language in Lisp runtime - your interpreter reads C-like source, parses it to your own AST structs, and evaluates those. The host being homoiconic says nothing about the guest. You would have to write a guest REPL anyway (if you want one).
Rhombus built on Racket, yes, means it reuses Racket's machinery: the macro expander, the module system, the compiler, the runtime. But it doesn't mean it inherits Racket's parenthesized syntax.
Racket's expander does not operate on text. It operates on syntax objects (shrubbery). It has its own REPL, because the Read stage has to parse shrubbery syntax, not s-expressions. So, my original point stands - REPLs do have differences for homo and and non-homoiconic PLs.
Well, Haskell/OCaml campers would probably say "it ain't FP, like at all, rofl..." Truly, it's absolutely pointless mental exercise to cherry pick features of any given PL and compare with another one, with no regard to overall experience (which often is very subjective).
Switching between different Lisp dialects is far less mentally taxing, even when they operate in completely dissimilar runtimes. I have seen days when I needed to jump between CL, Clojure, Fennel, Elisp and Janet and from all practical points it felt like almost using the same language everywhere. While switching even between JS and TS is enormously vexing for me in comparison. Although I have programmed in both for far longer than any Lisp.
> I just feel this (and its practical ramifications) are often overexaggerated.
I dunno. Can't fully agree or disagree. Nominally, yes, you really don't need s-expressions and homoiconicity for creating reflective, self-hosting runtimes - live redefinition is possible in Erlang, Pharo, Ruby. Metaprogramming ergonomics - sure they are cheap in Lisps, but even Lispers try to avoid reaching there, Clojure specifically recommends thinking twice, although projects like Hyperfiddle prove macros absolutely can be very powerful. Syntax, mathematical beauty, yada-yada - that's all "poetry", much of the real world operates on tons of very ugly yet functioning code, right? So, really Lisp-shmisp, whatever, no?
In practice though, Lispers are enormously pragmatic - I'm not self-referencing here, I have worked with some. It's incredible how rapidly they can build things, prototyping on the fly. How quickly they can move between different runtimes - I've seen codebases sharing ideas between absolutely dissimilar platforms. It is inspiring how undogmatic they could be - they easily move between modes - data/code, FP/OOP, interactive/compiled, etc. They have good understanding of type systems and some even know good deal of theorem provers. For whatever reasons, Lispers are conspicuously, disproportionately effective, and this is true. Sure "citation needed" here, but this is my empirical, anecdotal observation working in different groups, using distinct language stacks for many years.
The causation probably runs through the programmer, not the program. It's not like Lisp unequivocally emits good engineers, maybe it's that a substrate with minimal syntax and maximal malleability trains a particular disposition - they treat everything as reshapeable material, distrust dogma because the language never enforced one, reach for the smallest thing that works because the language makes "the smallest thing" actually small? Maybe Lisp doesn't make anyone write better programs, it just makes it cheap to keep changing your mind? Perhaps cross-runtime fluency, undogmatism, and rapid prototyping are all just "cheap to change your mind" in a way?
Could be selection bias - maybe Lisp just attracts curious, theory-literate, undogmatic people? I don't know. What I observed is for whatever reason Lisp typically attracts older, more experienced engineers. And therefore all the "Lisp propaganda" comes from them, and demographically that's a small subset of overall community and maybe that why it often feels like overexaggerated rhetoric?
You're wrong on every count about my experience. And once again, please: I'm just saying that stages in Read-Eval-Print-Loop does have differences in homoiconic and non-homoiconic languages. THAT'S ALL I SAID. There's zero controversial taste in that statement. None. I'm not bashing on Ruby, or Python, or any language you favor. I'm not telling you to use this or that. I'm just pointing out at specific differences that exist.
Da fuk you're talking about? Where the heck am I being an asshole? I have not used a foul language or insult in this thread once, even when someone accused me of being in a cult. Don't patronize me, even if you bought a moral authority on a discount - I'm not your fucking child. No matter how many times you say "please" and call me "asshole" I won't correct anything in my behavior because there's nothing to correct to begin with. What "disservice"? a) I could't care less about Lisp's popularity b) You seriously think someone, anyone would be like "don't look at Lisp... because there's one jerk in this specific HN thread. He said something in 2026. Eight levels nested down..."
I don't know who that is. I don't play stupid social games to win stupid social prizes. Why would I create a new account and yet keep replying with another one? I have single accounts pretty much everywhere, except Reddit - they shadowbanned my first one when I posted while connected to a VPN (apparently that's not allowed). You can easily use some OSINT tools to confirm that.
pg's notion was psychological, not about languages per se: a programmer sitting in language X can't perceive power above X, only below. It's about a fixed vantage point.
Your "Lisp is just another Blub" would be true if Lispers were stuck looking up from Lisp-as-it-was and failing to see higher. If Lispers were trapped in the Blub position, they couldn't have deliberately imported ideas that sit "above" classic Lisp. But they keep adapting: Clojure added persistent immutable data structures; brought CSP/channels; introduced structural contracts like Spec and Malli. With Coalton and Shen they are explicitly reaching for the static-types level you say they can't see. Racket's whole "language-oriented programming" perhaps a level above any perceived Blub.
Maybe what you see ain't a Lisp ceiling? Could it be that some powers must live in the substrate - and Lisp's distinctive traits are precisely what makes building that new substrate cheap?
I did not say anything about s-expressions. I said "homoiconicity". S-expressions are not an absolute requirement for homoiconic features. You keep poking me with your "knowledge" as if I'm trying to sell you snake oil and you feel obligated to defend and retaliate. I don't need to prove anything to you, I'm not your ignorant professor attempting to instil you with some defunct truths that exist solely in my head. Do your own research. Or don't, who cares.
You sweet, summer child, just so you know, I have existed for nearly half a century in this world where the larger part of it I have spent dealing in computing. I have seen and dealt with more programming languages (including Ruby) than you can count with your fingers and toes and that number keeps growing still. I'm not advocating for any particular language, runtime, framework or paradigm - do use whatever your heart desires.
I'm simply pointing out that there is a meaningful difference in REPLs in homoiconic and non-homoiconic PLs. You don't have to listen to me, this is easily verifiable information. Google it, ask LLMs, try it yourself, or ignore the notion entirely - it's completely up to you. But let's not get too intimate and slide into insulting one another - you have no idea who I am and what cults I'm specifically fond of.
[ my public key: https://keybase.io/agzam; my proof: https://keybase.io/agzam/sigs/La7qFk8YkbwfkgeSx7vkBWBba2f3HIpZyNVxUHvshbU ]