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.
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.
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.
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.
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.
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.
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.
(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).
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.
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"
I don't think we have a lack of concepts, but a lack of concept connectivity.
To avoid feature bloat of unconnected pieces of ad-hoc syntax Java does the right thing and focuses on expressing easily-composable language building blocks.
As a last adopter language, Java has the luxory of cherry-picking good features of other languages but I think their line of thinking should be the reference moving forward.
>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.
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.
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.
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.
Because what we know about programming has progressed, and new languages appear to take advantage of that.
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.
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?
Really fancy one, when it gets to what translation actually means in implementation effort.
Hehe, it was tongue-in-cheek. It takes a buttload of efforts to make a good one.
[dead]
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.
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.
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.
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.
(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).
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.
Related: https://cs.wellesley.edu/~cs251/f16/assignments/antics/Stefi...
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"
While those languages made the concepts mainstream, they weren't the ones coming up with them.
Rust's "ownership model", is a simplification of Cyclone, AT&T's research on a better C, based on mix of affine and linear type systems.
https://en.wikipedia.org/wiki/Cyclone_(programming_language)
Haskell's "Lazy evaluation" was present in Miranda, before all related researchers came up with Haskell as common playground.
https://en.wikipedia.org/wiki/Miranda_(programming_language)
"History of Haskell"
https://www.microsoft.com/en-us/research/wp-content/uploads/...
Java's "Green threads" go back to systems like Concurrent Pascal.
https://dl.acm.org/doi/10.1145/775332.775335
I don't think we have a lack of concepts, but a lack of concept connectivity.
To avoid feature bloat of unconnected pieces of ad-hoc syntax Java does the right thing and focuses on expressing easily-composable language building blocks.
As a last adopter language, Java has the luxory of cherry-picking good features of other languages but I think their line of thinking should be the reference moving forward.
I'm pretty sure they mentioned
>we create programming languages to experience new ideas; ideas that would have remained inaccessible had we stayed with the old languages.
>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.
[flagged]