Can the headline be changed on this so it’s not ridiculous clickbait? “American Airlines trains its pilots by having them fly airplanes” is more informative.
Since the title includes the word "quirks," the observation I'll make here is entirely appropriate: the post oversimplifies this.
It says: "So as we can see, at both run-time and compile-time, Common Lisp does typechecking to prevent silly errors."
This is not entirely accurate, as the Common Lisp standard does not require such typechecking.
The Common Lisp standard specifies the types of the arguments that a function expects. It generally does not specify what happens if the function receives arguments of unexpected types. It explicitly does not specify this: the standard says that if you give a function unexpected types, the consequences are undefined:
I can understand why the standard is written this way. Checking the types of arguments takes time. Sometimes you might not want to check the types for performance reasons.
It seems the author is using SBCL. As a practical matter, SBCL on the default settings will check the types of arguments. SBCL's manual (along with the manual of its predecessor, CMUCL) discusses how to manipulate these settings - the author discusses this, with the DECLARE form. But Common Lisp does not require this checking, so if you need your types checked, consult your implementation's manual. Indeed, SBCL allows you to change the settings for SPEED and SAFETY to specify how much type-checking you want.
All these caveats are also true for structures. The author says structure types are checked - again, as a practical matter, SBCL will check these unless you tell it not to. But that's not what the standard requires. Indeed, the standard explicitly states that "It is implementation-dependent whether the type is checked when initializing a slot or when assigning to it."
Thank you for this. There is occasionally disagreement about what "Common Lisp" even means, and the spec is often cited, but as far as all of my posts, library work, and application work are concerned, Common Lisp means "the current reality of the major compilers as implemented in 2025". This is a descriptive / bottom-up definition, and as an active author of software it is the one I'm more concerned with. For instance, `:local-nicknames` have been essentially universally implemented among the compilers, despite not being part of the spec. To me, this makes that feature "part of Common Lisp", especially since basically all CL software written today assumes its availability.
You're right to point out too that the post is somewhat SBCL-centric - this too reflects a descriptive reality that most new CL software is written with SBCL in mind first. Despite that I'd always encourage library authors to write as compatible code as possible, since it's really not that hard, and other compilers absolutely have value (I use several).
Every programming language has a practical definition: it is the intersection of the sets of features that are accepted by the various relevant production compilers and interpreted identically enough to be portable to all of them.
Formal language definitions, standards, and books are great, but you can't compile with them. Abstract language specs that don't have reference implementations or conformance test suites are not particularly useful to either implementors or users.
The chat bot operator slurps all websites and gives answers to all questions free of charge.
No other website can compete with that.
The whole story with streaming media is not just that pay streaming became more convenient. It’s also that content creators used legal and business mechanisms to make piracy inconvenient. They shut down Napster. They send DMCA notices. They got the DMCA enacted. They got YouTube working for them by serving ads with their content and thus monetizing it.
Chat bots are just like Napster. They’re free-riding off the content others worked to create. Just like with Napster, making websites more convenient will be only part of the answer.
> content creators used legal and business mechanisms to make piracy inconvenient
Copyright holders, not content creators. Though typically content creators are also copyright holders, copyright holders are not always content creators, esp in this context. To a big degree these practices are not on the behalf of content creators nor are they helping them.
The solution may be elsewhere: starting from creating content that people may actually care about.
> The chat bot operator slurps all websites and gives answers to all questions free of charge.
> No other website can compete with that.
Copyright infringers uploaded music, television, and films free of charge, yet people still pay for all of that.
> The whole story with streaming media is not just that pay streaming became more convenient. It’s also that content creators used legal and business mechanisms to make piracy inconvenient.
Do you seriously think that copyright infringement ended when Napster went down? Have you never heard of the Pirate Bay or Bittorrent? They didn’t succeed at all in shutting down copyright infringement. People pay for things because it’s convenient, not because copyright infringement is no longer an option.
I think that's the idea with deregulated electricity. Where I live (Maryland USA) I can pick who generates my electricity. I have no choice in who delivers it and that is still regulated.
I found that in practice the non-default options do not wind up being any cheaper so after trying it for a few years I switched back to the default option, where the price is not regulated but is set through a prescribed auction process.
I suppose the deregulation might still put downward pressure on prices in theory.
Don’t switch text editors, and don’t use a plugin.
For a few years I used Orgmode. I didn’t use Emacs. That is, when I needed to edit text files, I used Vim or macOS TextEdit. I used Orgmode to track my tasks and keep notes. That Emacs was underneath it was purely incidental, and I didn’t use Emacs for anything else. For me, Orgmode was not a plugin. It was the primary software I used, and there was this Emacs thing under it.
Ironically, these days I do actually use Emacs, and I use OmniFocus for tasks, mostly because OmniFocus gets multi-device sync right so it’s worth the price. But don’t hesitate to use Orgmode even if you don’t want Emacs otherwise.
org-mode is basically better Markdown with a bunch of automated things that don't get in your way unless you specifically put them in there.
The only unwanted feature you're likely to encounter is automatic sub/superscript conversion, and that's documented and easy to turn off.
I'm not recommending org-mode. I personally don't care if you use org-mode or not. I never understood that mentality. But the type of software you're describing is crap, and org-mode doesn't fall into that category.
I think this sort of comment turns people off from Emacs.
Most people don’t want to become experts in the editor. The editor is a means to an end: writing code, writing text, etc. This comment suggests to the new user: if I don’t program Emacs and publish packages in it, I’m not really using it, I’m just dabbling in it. But I don’t want to program the editor, so I shouldn’t use it at all.
I also don’t think the comments you criticize discourage users who would have discovered something transformative. Someone interested in programming their editor isn’t discouraged by someone who complains that Emacs is missing some modern prettiness, or that it’s not popular. There is plenty of Emacs evangelism that will hook those receptive to it.
I would like to balance out your comment by saying: it is just fine to, as you would say, dabble in Emacs. Don’t write advice. Don’t publish packages. Use customize. Don’t write a .emacs. Use the pull-down menus. It is still a delightfully powerful and well-documented editor even if you do none of the “expert” things. The developers have added so many of these features precisely so Emacs is easier to learn and use, and don’t let commenters who call you a dilettante convince you that if you’re not an Emacs Lisp maestro, you shouldn’t bother with Emacs.
To start, I disagree. If it takes a person to turn away from a tool just because some random human tool said something online, maybe they are not ready, on what level - emotional, spiritual, mental, moral - I'll leave them to decide.
I'm not saying "don't dabble in Emacs", dable all you want. Just use the damn tool - it's not that hard. To use the tool you just need to use the fucking tool with the intent to fucking use it. When someone says something like "I used Emacs for a decade as just a text editor" to me it sounds like: "I had this smartphone for the past two years and used it only to make calls. Not even video - I never bothered to figure out how that works..."
Emacs is a Lisp-based event-loop, with an embedded editor in it. This is of course a "simplification", but that will do. What do you do with a Lisp interpreter? You feed Lisp programs into it. Try writing some Lisp, it's not that hard. Swallow you hubris, swallow your pride - whichever you prefer and stop blaming parenthesis, bad weather, ThePrimeagen's mustache, sanctions or AI. With AI tools these days it may even feel like playing a video game.
You don't need to be "an expert" there are no "experts" in Emacs, there's no "career ladder," progression system, no ranks and shoulder straps, I don't know anyone who gets paid even just a little bit more for simply being good in Emacs - I certainly don't. Use it or not - just don't think of being "a newbie" or becoming "an expert" you either enjoy it or not, whichever it is - it's fine.
And by the way, I personally think I would've loved to witness my kind of evangelism back when I was still a tool, just much younger.
My message in this particular instance is not aligned with either of these, and you seem to be misreading me. I have no issue with people choosing different tools, switching techniques, finding different ways of thinking about problem solving, text-editing, etc. It's not even about "punishing" those who choose to leave my beautiful world or trying to get them back, it's about setting expectations for those who have never seen it.
What I see quite often is when people profess years of using the tool and finding it unsatisfactory, only to reveal (if ever) that they've engaged with just its surface layer. It's like someone saying they found a piano limiting after years of only using it as a percussion instrument. My point is about embracing Emacs as a Lisp environment from day one - not because everyone must use it this way, but because that's what it actually is. When you treat it as 'just an editor' you're working against its design rather than with it. Those who embrace its programmable nature early often discover possibilities they didn't know they were looking for. Yes, this may mean a slightly steeper upfront commitment, but it also means actually using the tool rather than having square-peg-round-hole mismatched expectations.
It's not about choosing nicer or harsher messaging, it's about the truth, and it comes from the heart - I personally, of course, regret years wasted in vain instead of finding Emacs sooner; it works great for me. I understand it may not work that well for everybody, and I'd rather they realize that sooner, instead of wasting years of their lives. I also spent a long time trying to rationalize Emacs in my own head, because I kept approaching it from the wrong angle, but I am happy I didn't quit. Some people may not have that kind of patience.
> When you treat it as 'just an editor' you're working against its design rather than with it.
No. This is exactly the sort of talk that turns people off from Emacs. You can use it as "just an editor." Indeed, read the GNU Emacs Manual. It almost entirely describes "just an editor." An excellent editor. The user needs to consult the Emacs Lisp Reference Manual only if extending Emacs is desirable.
Comments like this one suggest that Emacs is designed only to be programmed and that if the user does not program it, the user is "working against its design." This is just as false as saying that a Vim user who writes no VimScript is working against Vim's design. No, the user who doesn't program the editor is...using the editor. As designed.
You can, sure - sometimes we all do, when we need to debug a faulty package, we run it with the -Q option. I've been working for many years with people who use Emacs, have many friends who use Emacs, have mentored complete newbies and regularly discuss advanced topics - I have yet to meet someone who uses Emacs as is - with no customizations whatsoever. In fact, if I meet anyone who does that, I would very much be interested in learning their rationale, and perhaps even try to question their mental or emotional state.
Vim on the other hand, is very different in this, there are in fact plenty of users who do use it with zero customizations, daily.
> read the GNU Emacs Manual.
Okay. Let's do it... M-x info-emacs-manual - the very first two sentences - "Emacs is an advanced, extensible, customizable, self-documenting editor. This manual describes how to edit with Emacs and some of the ways to customize it." The third paragraph right there, at the very top, already explicitly says: "For information on extending Emacs, see Emacs Lisp". Five words pertaining extensibility in just three opening paragraphs, against only a couple of cognates of "editor".
What the heck are you even trying to argue here? Rephrasing your point doesn't change the underlying fact - Emacs is first and foremost an "extensible editor", not "an editor that can be extended (if desired)" - the emphasis is on "extensible", not on the "editor". That's what sets it apart from literally any other tool that gets used as "just an editor".
If regurgitating the factuality engrossed in the manual, ardently or otherwise, turns some people off from Emacs - so be it, like I already said before - it's probably for the best. Better for them, better for the Emacs community.
reply