Why Study Programming Languages
34 comments
·October 14, 2025hinkley
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.
rednafi
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.
ramon156
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
doyougnu
I still like Olin Shiver's take on this: https://www.ccs.neu.edu/home/shivers/papers/why-teach-pl.pdf
zweifuss
There is something to the existence of fads and fundamentals. When I started, it was Object-Oriented-Programming (with multiple-inheritance and operator overloading, of course), Round-Trip Engineering (RTE), XML, and UML.
IMHO, not the ideas were bad, but the execution of them was. Ideas were too difficult/unfinished/not battle-tested at the time. A desire for premature optimisation without a full understanding of the problem space. The problem is that most programmers are beginners, and many teachers are intermediate programmers at best, and managers don't understand what programmers actually do. Skill issues abound. "Drive a nail with a screwdriver" indeed.
Nowadays, Round-Trip Engineering might be ready for a new try.
lock1
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.
keyle
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.
TomasBM
I'm not a 'native' programmer, but even I can agree with that.
As it became easier to abstract away from pure assembly, people did just that. Some ideas stuck, some converged, and the ones with the most tenacious, adaptable and attractive communities remained.
Before I learned to code, no programming language was even remotely readable to me. But the more I learned, the more I could shed the notion that this was purely my fault, and accept that sometimes things are a certain way because someone found it interesting or useful. Applies to natural languages and mathematics, too.
WalterBright
Because what we know about programming has progressed, and new languages appear to take advantage of that.
pjmlp
Many new languages are still recycling ideas from the 1970's research labs.
Outside affine types, all the praise for Rust's type system traces back to Standard ML from 1976.
The heretic of doing systems programming in GC enabled programming languages (GC in the CS sense, including RC), goes back to research at Xerox PARC, DEC and ETHZ, late 1970's, early 1980's.
Other things that we know, like dependent types, effects, formal proofs, capabilities, linear and affine type systems, are equally a few decades old from 1980's, early 1990's.
Unfortunely while we have progressed, it seems easier to sell stuff like ChatGPT than better ways to approach software development.
eptcyka
Aside from bringing in the groundbreaking feature, Rust doesn't bring in any groundbreaking changes. It could be argued that bringing in lesser known features to more people is a good thing in it's own right.
keyle
Hey Walter, while we have you. Have you ever had the itch to make a newer D that takes all the fancy constructs while retaining the good parts?
agumonkey
linguistic constructs will direct your brain when solving problems and may help you discover solutions spaces you wouldn't with another set of idioms
not to promote FP but imperative stateful vs closures/function oriented is quite a strong example of that
a different paradigm can really be a massive intellectual tool
DarkNova6
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.
mellosouls
(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).
shevy-java
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.
binaryturtle
But is that a problem of the language itself, or is it just a problem of available toolchains? E.g. if the gcc compiler collection would come with BASIC support and you just could type something like "gbasic -O3 foobar.bas -o foobar" to get a properly optimised executable out of your BASIC source code file then some may would still use BASIC today, I guess?
I started with BASIC too. Also enjoyed BlitzBasic2 for a long time on the Amiga. That's where I learned programming… back then when programming was still fun.
MoltenMan
Realistically? No, not at all. The reason there are no toolchains for BASIC is because nobody uses BASIC (because it's not functional in our modern world), not the other way round.
vbezhenar
Why do you think BASIC is not functional? Our modern world does not differ from the 1980 world at all. Variables are variables, subroutines are subroutines.
It fall out of fashion, along with Pascal, Perl, Ruby, but that's just fashion.
jonathanstrange
I was never more productive than with REALBasic, it was a true RAD tool, and I'd happily use Xojo nowadays if it wasn't so expensive. That's a "modern" structured BASIC so I guess not what you had in mind.
One thing I've learned over the years is that the language is almost irrelevant, the tooling and 3rd-party library support are much more important.
ryandv
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.
christophilus
Sarcasm, right?
ryandv
The best way to get a strong answer is to post boldly incorrect statements. Then I get other people to write my actually-desired arguments for me.
I call it, "wetware LLM prompt engineering".
> I encourage everyone to create the most absurd, implausible, and impractical languages.
Been there, done that: https://esolangs.org/wiki/Ziim