Once you understand a thing, you know what it’s capable of.
A lot of my early expertise in performance analysis was heavily informed by my SIGPLAN membership. Many of the improvements showing up in compilers and interpreters would show up in some form there, and of course those developers were either involved in the papers or had access to the same research. So when some new version came out with a big explanation of what it did, I already had a reasonably good notion of how it worked.
It was a dark day when they got rid of the paper proceedings.
I tries to answer the question "Why do we design new programming languages?" but it forgets the simplest of answers:
Because we can. Because a compiler is nothing more than a fancy text translator.
I still like Olin Shiver's take on this: https://www.ccs.neu.edu/home/shivers/papers/why-teach-pl.pdf
> Why do we design new programming languages?
The main answer is that we have only a limited ability to modernize existing programming languages. For example, most languages are not null safe, because most languages are old and we can't make them null safe without breaking backward compatibility with most existing code. And we can't break backward compatibility for practical reasons. So Java will never be null safe, PHP will never be strongly or statically typed, etc.
So for fundamental language features, replacing older languages is the only way to achieve progress. Unfortunately that's a very slow process. Python, the currently most popular language, is already over 30 years old.
For me, I find reviewing and analyzing programming languages to be a fun activity. Writing esolangs is also fun, you can write it without needing to care about things like backward compatibility or practicality.
This reminds me of recreational math & gamedev, you simply do whatever you feel is fun and design it exactly as you'd like it to be.
When studying programming languages you really have to focus on the why's.
When I was learning Rust I started out just associating patterns with lib types. Need to dynamically hold items? Vec. Need a global mutex? install lazy_static.
This is fine if you're beginning, but at some point you need to read about why people choose this. 9/10 times there's a more elegant option you didn't know about because you just did what everyone else does. This separates programmers from coders.
The only reason I learned this was because my current company has programmers, not coders. I learned a ton from them
I think that one of the things that they neglect to mention, on why we invent new languages, and it's probably the most important thing - people want new ways to express concepts.
It's super important because those concepts get measured, and absorbed into existing languages (as best they can), but that wouldn't have happened without the new languages
New concepts like Rust's "ownership model", Smalltalk's "Object Orientation", Lisp's "Functional programming", Haskell's "Lazy evaluation", Java's "Green threads"
The appeal of experimenting with languages varies widely between academics and industrial practitioners. When you’re in the business of creating languages, exploration often takes on the character of an art project.
However, as a trench-line coder, I enjoy dabbling in languages to learn different techniques for achieving a similar set of goals without sacrificing pragmatism. In that sense, I rarely have the luxury to explore purely for exploration’s sake. So I wouldn’t describe abstraction, performance, or usability as “aesthetics,” nor would I spend time on a frivolous language that I know won’t gain much traction outside academia.
I like reading the perspectives of academics just to see how wildly different they are from those of the people I work with in the industry. This is probably a good thing.
>Common answers to this question will include words like abstraction, performance, convenience, usability etc. The problem with these answers is that apart from the measurable, they are all subjective, aesthetic choices.
That just is not true at all. These are all legitimate engineering tradeoffs, which any serious project has to balance. Calling this "aesthetics" is completely dishonest. These aren't arbitrary categories, these are meaningful distinctions engineers use when evaluating tools to write software. I think the students better understand what programming languages are than the teacher.
If you accept that a programming language is a tool and not just an academic game of terms, then all these questions have clear answers.
> I encourage everyone to create the most absurd, implausible, and impractical languages.
Been there, done that: https://esolangs.org/wiki/Ziim
The answer to (2) is, IMO, "to make computing cheaper". It's interesting to me that this is not the obvious, default answer (it may not be the most actionable answer but IMO it should at least be noted as a way to frame discussions). I think we're at the tail end of computing's artisanal, pre-industrial era where researchers and programmers alike have this latent, tacit view of computing as a kind of arcana.
Old languages died or are barely in use anymore.
I think it is more interesting to see which languages are still used today and how popular these are. Because this is also tied to the human user/developer.
For instance, I used BASIC when I was young - not as a professional but as a hobbyist. I liked it too. I wouldn't use BASIC today because it would be entirely useless and inefficient.
One of PGs essays hit on this when he talked about “blub”. Building a language for a specific solution/domain was/is expensive, but using a language to build abstractions or an internal domain specific language has been much more tractable. As such some languages are more or less suited for this activity; Lisp being the king then Ruby then etc.
So to me the study languages was interesting from this DSL perspective.
The author says:
“This class is about the study of programming languages.”
Where is that class?
There absolutely lies value in studying programming language, but maybe not when reinventing ideas of the past.
> I encourage everyone to create the most absurd, implausible, and impractical languages. Chasing the measurable is often useful, expressing the expressible is insightful, but never forget the true goal of language design: to explore and create what isn’t.
Sorry, but this sounds more like an artsclass to me. Don't get me wrong, there was a point in time where exploration of the unknown was the only way to move forward. But these days we would need greater insights into higher-level language semantics and inherent tradeoffs to guide language-design and language evolution.
There is plenty to choose from and one can learn already so much just by reading up on the Java-EG mailing lists. Brian Goetz has a true academic mindset and I frequently feel inspired when I read his reasoning which is both highly structured and accessible.
Otherwise we would just be left with another compiler class. Compiler basics really aren't that difficult.
(2022) This is particularly important here as the essay makes no mention of LLMs or coding agents (which were still in their infancy in development environments; this article is post original copilot/codex but pre ChatGPT).
Programming languages are obsolete in the LLM era. What current generation AI has revealed is that English is actually the ultimate representation of computer programs and systems, which is both sufficiently terse and precise to economically describe the operation of arbitrarily complex programs.
There is no reason to study programming languages in 2025, other than as a historical curiosity - the same way one may study languages equally as pitiable as e.g. COBOL, Lisp, or MIPS assembly.
> Usability is similarly ill-defined and hard to measure.
Human factors are very well studied and standardized, and there is a well-established discipline called "Human Factors Engineering", which also provides established test and evaluation methods. Human Factors research is considered solid and well-established because it has been built on rigorous experimental psychology and engineering principles developed over more than a century, with systematic methodology and empirical validation. Even if much of it is unknown or ignored by computer science or programming language design, there are many disciplines where Human Factors Engineering is critical (see e.g. ANSI/AAMI HE75).
Usability is therefore neither ill-defined nor hard to measure. Several ISO 9241 series standards address textual and command-based interaction directly relevant to programming language assessment. ETSI EG 202 116 provides extensive human factors guidelines for command language style. ITU-T Recommendation Z.361 provides guidelines for Human-Computer Interfaces in telecommunications management, incorporating the ISO 9241-10 dialogue principles. ISO/IEC TR 24772 addresses programming language vulnerabilities specifically from a human factors perspective.
E.g. Ada did have substantial human factors considerations documented in its design rationale, directly contradicting the notion that such principles don't apply to professional developers or programming languages. It's rather that computer science seems to continue ignoring established fields ("Not invented here"). Human factors in software development have been overlooked by researchers in the software engineering and development research areas, despite their obvious relevance. So what is lacking is primarily interest or willingness, not the fundamentals and means.