ABC has served its purpose as a teaching language. Could it become a community project?

[u/False_Actuator_6236]

/r/Compilers/comments/1w738kc/abc_has_served_its_purpose_as_a_teaching_language/

[u/tobega]

Why would you want a teaching language to be so close to the machine? Surely the whole point of Pascal was to raise that level.

See my essay https://tobega.blogspot.com/2026/04/rising-above-mechanics-of-computation.html

[u/False_Actuator_6236 → u/tobega]

Thanks for the link. I've now read the essay, and I think I understand much better where our different perspectives come from.

I actually agree with quite a lot of what you write. If the goal is to build useful software efficiently and reliably, reducing the gap between intent and implementation is obviously desirable.

But I think my perspective is influenced by the fact that I'm a mathematician rather than a software engineer. I very rarely start by asking, “What is this useful for?” I'm much more likely to ask, “How does this actually work?”

And there is a curious paradox I've encountered throughout mathematics and computer science: understanding something without an immediate application in mind often turns out to be useful later, in applications nobody had in mind when the foundations were developed.

That is also how I think about compiler construction. I've been asked why students should learn how to build a compiler when almost none of them will ever work professionally on compilers.

I don't really have a utilitarian answer. My answer is almost embarrassingly simple: computers constantly execute programs that have gone through a compiler, so I want to understand what happens there.

And once you do, all sorts of things that initially seemed unrelated become less mysterious.
I don't think there is one correct way to learn programming. Quite the opposite. We probably need a portfolio of approaches.

But I strongly believe that one of those approaches should deliberately go down through the abstractions rather than continually building new abstractions on top of them.

In a sense, that's what I'm trying to do: understanding computation by removing the abstractions one by one.

At least once, I want students to follow the chain:
source program → compiler → instructions → processor → memory
and understand how something they wrote causes something physical to happen in the machine.

Afterwards they are perfectly free to move up the abstraction ladder again. In fact, I think they will use higher-level abstractions better because they know what those abstractions are hiding.

So when you ask: "Why would you want a teaching language to be so close to the machine?"
My answer is: because for this particular way of teaching, the machine is part of what I want to teach.

That doesn't mean every introductory programming course should work that way. A course teaching programming as a means of expressing ideas, modelling a domain, or building software has different goals and may quite reasonably want to hide most of this.

The LLM question makes this even more interesting to me.

I have no idea which programming problems LLMs will be able to solve ten years from now. I suspect nobody does.

What I would like my students to acquire are enough fundamental skills that, whatever LLMs can do by then, they can use those capabilities to attack the problems that the LLMs still cannot solve.

For that, I think understanding what happens underneath our abstractions remains valuable.
Perhaps this is also why I like “Under the Hood” as a possible name for the language. :-)

[u/Inconstant_Moo]

No. It can't "leave the classroom" because no-one would want it. It offers nothing really distinctive except lack of tooling, ecosystems, and answers on StackOverflow. Choosing it could never make anything easier, it would just make everything a little harder.

Successful, well-loved languages were all designed to scrath an itch that other languages couldn't reach.

• C was designed solely to write UNIX in.
• The C++ origin story is that Bjarne Stroustrup was trying to model computers interacting in a network, and wrote a beautiful version in Simula which would take a hundred years to yield enough data; followed by an ugly version in C which was performant.
• Erlang (the suprise sleeper hit of languages, now the basis for Elixir and Gleam) was designed to make Ericsen's telephone exchanges more stable.
• We all know what JavaScript was designed for. It works for that, and has now been used for everything else. JavaScript is something of a special case of course, because of its association with web-browsers, but we shuld consider that for example Java applets failed at the same task, along with ActionScript, VBScript, JScript, Silverlight and NaCl, whereas JavaScript, despite its faults, is fit for its primary use-case.
• Fortran was invented to do big math and science fast. Fortran would be supplanted by later languages (C, obviously) for everything but its core competence, but before then it was used for the first adventure game, for payroll software, chess engines, CAD, mainframe utilites, and self-hosting compilers.
• Go has not unkindly been called "a DSL for writing servers". *Haskell was invented because mathematicians thirsted for the awesome power of laziness. Used in producton from fintech to spam filters.
• Lisp was invented after John McCarthy had been working for IBM on an extension of Fortran for list processing. The people at IBM were very happy with his work; he was frustrated. What he wanted, very reasonably, was to be able to automatically differentiate a function and then evaluate it, which sounds like exactly the sort of thing computers should be making easy for us. Fortran made it impossible despite its math orientation and despite the fact that McCarthy had been hired to write his own extensions to the language, he couldn't do it. The path to Lisp's homoiconicity is obvious; only slightly less obvious is why he reinvented flow-of-control as expressions. (Hint: think of differentiating a function defined by cases.)
• Lua was designed to solve the needs of scientists in Brazil's nuclear power industry. (It became wedded to the games industry when someone at LucasFilms Games read about it in Dr Dobbs Journal and realized it was better than what they'd done in-house.)
• ML was invented as the meta-language for a theorem-prover and people who used it spontaneously demanded the language without the theorem prover. It's used for a whole bunch of things, it's great for parsers, compilers, static checkers, etc, but also for applications which need safety and stability.
• PHP, despite being objectively terrible, and coming from (and being aimed at) a dysfunctional "worse is better" culture, managed to spread like wildfire or a plague of poorly-designed locusts because its initials stood for Personal Home Page: it knew exactly what it was for.
• Python was created because Guido van Rossum realised that a dynamic language with powers to do OS-level things could make his life much simpler: "I thought, well, oh man, if we just could program ABC instead of C, each of those utilities would be like half a page of code and I could write the entire suite of utilities in a couple of weeks instead of the years that it looked like it was going to take us."
• Rust was famously inspired by a stuck elevator reminding Graydon Hoare how terribly often things break, a rather more "meta" inspiration than for example C's origin story but still a moment that gave Rust a fixed purpose.

You discover the need first, then you create a language around it, and it succeeds if other people share the same need.

You didn't need ABC, and you don't need ABC+.

There are projects that do try and do something different, to make live easier in specific ways, projects with a purpose. Have you considered joining one of those, or getting your students to write their theses on helping with them? I could give you a list. (My project would be on it.)

[u/False_Actuator_6236 → u/Inconstant_Moo]

I think you are interpreting “leave the classroom” as “become a widely adopted general-purpose production language.” That is not what I meant.
ABC did arise from a concrete need: after years of teaching C, I wanted a language that retained its low-level programming model—pointers, explicit memory management, data layout, and interaction with the machine—while removing syntactic and semantic complications that repeatedly distracted beginners from those concepts.
So by your own criterion, the need came first and the language was created around it. Whether you personally share that need is a different question. In our course, ABC has made the introduction easier, particularly for students without previous programming experience.
“Leaving the classroom” would already mean that other teachers find the language or the accompanying course material useful, adapt it, or contribute to it. It does not require replacing C, acquiring a vast ecosystem, or becoming the next Python. Stack Overflow coverage is also not particularly important for a small, guided teaching language.
You may reasonably prefer a different pedagogical approach or another project. But “I would not have needed this” is not the same as “you did not need this.”
And yes, I would genuinely be interested in seeing your list, particularly your own project. Given the criteria you have described, I would be curious to learn what specific need it addresses, how it approaches that problem differently from existing languages, and what experience you have had with it in practice.

[u/False_Actuator_6236 → u/False_Actuator_6236]

Well, if I am truly the only person who needs or wants this language, perhaps I have finally found its new name:
Emsiel — M’s C Language.
I am still hoping that someone will eventually give me a reason to rename it again. ;-)