Flipping through the esolang wiki <https://esolangs.org/wiki/Main_Page> and coming to the frustrating realization that there still isn't a worthy successor to INTERCAL.

The modern day esolangs are, it seems, motivated by one of three things:

* "How different can we make this from a conventional programming language and have it still be Turing complete?"
* "Wouldn't it be annoying if [thing that conventional programming languages never do]?"
* "Let's optimize for terseness at the expense of readability" (aka "golfing" languages).

INTERCAL *has* bizarre, annoying, and/or terse features but it's not *motivated* by any of them. INTERCAL's motivation is *satire.*

Specifically, INTERCAL is satirizing the common "third generation" programming languages of its time (the early 1970s). The things about INTERCAL that (on purpose) make it incredibly unpleasant to use are funhouse mirrors of the things about FORTRAN, BASIC, COBOL, the other somethingBOL languages, MUMPS, etc. that made *them* unpleasant to use (because their designers didn't know any better at the time).
It's not just a parody, either, because it has a point to make -- several points, in fact. The most obvious is the numbered variables (skewering languages where all variables had to be one letter) but there's also a whole chunk of the manual about how "a person whose work is incomprehensible is held in high esteem", and a throughline about what we'd call "familiarity" today (all the made-up custom names for symbols)...
A true successor to INTERCAL, then, would also need to be a satire. Where's the programming language whose intentional annoyances demonstrate the unintentional annoyances of writing code in *today's* popular programming languages?

Followup: The most annoying things about current generation programming languages are IMO *not* about the syntax. Sure, it still grinds my gears every time I can't have a multi-line anonymous function in Python, but in the *grand* scheme of things, the stuff worth satirizing about today's languages is like

* dependency hell
* API tarpits (everything is possible nothing is easy)
* nobody knows how to write docs
* forgetting the lessons of the 1990s is the new forgetting the lessons of the 1960s

@zwol adding in some stuff about the rust borrow checker could be an interesting modern update. Not only can it be difficult to satisfy the conditions of the borrow checker, you could also bring back intercal's politeness requirements - you can only have a borrow if you're sufficiently nice about it.

You can steal references, but if you do it too much you'll get caught by the reference cops.

@kepstin hm, yeah, if we want to make it strictly about the languages themselves rather than the stuff surrounding the languages then that could be an interesting angle. Borrow checking and other well-intentioned features that turn out to have frustrating limitations that make you occasionally pine for the days when the C compiler really would sit back and watch as you shot yourself in the foot.
@kepstin
Or error handling! Every programming language I've ever used has gotten error handling wrong in a _different way_. It's one of the few things where I think we still genuinely don't know how to do it right. Maybe some thoughtful mockery will help.
@zwol @kepstin From my experience that‘s because handling errors means writing another program than primarily intended: I want to write a program that succeeds at doing a thing but instead I‘m forced to write one that survives in the face of failures only somewhat related to the thing. It‘s like instead of writing about Odysseus continuing the journey to also being forced to write down the full story of what happens to Polyphemus and everyone else.

@pancomputans @kepstin i was just telling someone else the other day that the difference between a program that works for its author and a program that works for lots of people is mostly about error handling...

what you just said is the pithiest explanation of _why_ that's so that i've ever seen!

@pancomputans @kepstin and there's a lot of that extra work that requires actual design put into it, but I do still think programming languages could be doing a better job of helping ... somehow ...
@zwol Obviously you are talking about C++. Stroustrup just hasn’t revealed it’s satirical.
@pancomputans I dunno. Possibly this is just Poe's Law of Satire at work, but C++ has always felt like it's in earnest to me. Kinda like how, as Teresa Nielsen Hayden once quipped, only someone with a truly _clean_ mind could have invented candle salad.
@zwol @atax1a Has anyone made a language yet that reinterprets whatever you wrote through a random number generator I mean LLM, every time you run it?
@samir @atax1a Some say this is what "agentic" coding is all about already :-P

RE: https://infosec.exchange/@atax1a/112124923616439836

@zwol it was in earnest, otherwise we would nominate Vim Guy Bram Moolenar's hobby language Zimbu

https://web.archive.org/web/20160310084006/http://www.zimbu.org/design/goals

@atax1a I am so very tired
@zwol "Code must be easy to read, therefore keywords are uppercase, we have eliminated the opening brace for blocks, and you can't put parens around predicates of if" sure is a thing you can think
@atax1a I know right?? I think I could actually make an argument that one should *deemphasize* all the keywords when syntax highlighting. Not... whatever this is.
@zwol it just baffled us the degree to which this guy celebrated this puke as some kind of crowning achievement

@atax1a Back in the day on rec.arts.sf.written they used to talk about the Brain Eater, an imaginary monster that would visit SF authors towards the ends of their careers and eat the part of their brains that could tell when a story they'd written was any good. It was invoked to explain e.g. why Heinlein's "Stranger in a Strange Land" is so much better than "Time Enough for Love".

Perhaps a similar monster is in play here.

@zwol oh my god COMEFROM is based on MUMPS

this makes so much sense and it’s so horrifying

@jyn I don't know enough about MUMPS to know if this is true! But I shall choose to believe it anyway.
5. General Language Features of M — YottaDB Documentation documentation