I came here to say "can we worry about building programming languages in twenty-four years instead, please?". Someone who has gone through your list is exactly who I want actually building the next generation programming languages. Of course your last question is the best one:
> eh, why bother
This is absolutely the question you need a deep answer for. You need a problem that is burning you up and whose only solution is a new programming language. This might never happen. If it ever does, you're the person to do it, exactly because of all the ups and downs and half-started ideas you've thrown away. But you're right: the "why bother" stage is not to be ignored. It's the most important one.
I had to change the scope of my desires. I don't want to make the next Python. Not even the next Zig or Nim. I just like fiddling with compilers and interpreters. Someone else mentioned Crafting Interpreters and I'll bring it up, too. I've been following along in C# and occasionally come back to my C#Lox implementation and work through another chapter. It is quite a lot of fun.
I implemented VBA in C# a few years ago for malware analysis, and my takeaway is...well, it's a hard project. Possibly as hard as I've ever done, but a big part of that was guaranteeing bug-for-bug and type conversion compatibility and obscure language features that nobody would include today. I can't even fathom how the old folks implemented BASIC in 256 bytes of 8-bit assembly back in the day.
Seeing the interview with Chris Lattner on Lex Fridman podcast on developing Mojo, and how he's learnt from developing Swift, or LLVM is very interesting, and how the path they've taken with Mojo is different from Python. It also seems like a lot of languages especially the new ones are converging with the best features from past languages which also makes sense.
This is super ambitious, but a great project to work on to better your understanding. And I applaud you, especially as an undergrad student( I assume as you stated final exams in the post). I wish I'd done more projects like this back when I was starting out. You are way ahead of where I was lol, I barely did any projects outside classes. And you got some attention on HN. Good stuff!
An interesting read. Always been fascinated with compilers and lexers. I should really make a language at some point. I tried following that "make a lisp in c"* book but I didn't like that they used external libraries that I didn't know about.
Before you start down this path, which will take longer than you imagine, you need to understand your underlying reasons for doing so.
What is your problem domain?
What don't you like about the currently available languages?
Why do you want to kill yourself doing so?
Can you afford to do so?
Is this something you consider fun?
Understand yourself first and be willing to spend the time learning and sure go ahead, knock yourself out.
Just keep in mind that there are a small number of language classifications and yours will fit into one of these:
COBOL style languages: COBOL, Common Lisp, C, C++, C# and Java are examples here.
Fortran style languages: Fortran and all its variations.
I don’t think your list is particularly well compiled. For starters, bar your “functional” group, you’ve not grouped them by paradigms. Which has meant you’ve left out some pretty significant classifications. And several languages haven’t even been grouped correctly using your own method (or at least the lack of established terminology makes it harder to understand the grouping context behind each category, since most languages exhibit multiple traits and influences).
This is really good advice. Writing a language you'd actually like to use is difficult. It's been a richer source of interesting subproblems than any other I've found. If it's for education or entertainment, all good. If it's something you're going to quit a day job to pursue in the hope it'll make you wealthy later, quite high risk.
Language classifications normally antagonise people and tagging Lisp as essentially COBOL is well chosen for that. You're missing the prolog family and proof languages (coq/isabelle/lean etc). Also smalltalk (from which one might draw self and javascript).
Knowing exactly what one has rejected about existing languages is useful as a guide.
Oh dear, the language classifications above was supposed to be a somewhat obtuse sort of joke and it appears that I was way too obtuse with the grouping for [COBOL style languages] and the [a couple of other more minor kinds].
Way too many [Dad jokes] or in my case [Granddad Jokes].
24 minutes is a better target, i have a few repos like this... and long before the internet made it easy, it was the kind of thing i would do in my lunchtime at an office job.
it was way more instructive than following the standard path.
I'm not sure what the intended utility of "I am better than the target audience of this article" is, but I assure you it does not paint you in a positive light to other readers.
I read it more like setting a low bar in terms of time, like a pomodoro in fact. So whatever you produce in 24 minutes is that language. Then try again later.
Some of us should start the meta-project of cleaning our house by just making our bed.
> and long before the internet made it easy, it was the kind of thing i would do in my lunchtime at an office job.
This gives me vibes of "I think I'm really impressive and I want people to know it." Maybe that's uncharitable though... Talking to people online has made me too cynical haha. I appreciate the alternative perspective.
I had a lunch time project for a couple of months, where I would spend about 30 minutes a day (I had to limit myself) implementing a scheme-like in an assembly-like language called Teraterm. It was fun trying to work within the constraints of the language. I finally quit when I hit TTs built in recursion limits. I know the solution would be implementing a call stack in TT, but I couldn't bring myself to do it.
There wasn't a setjmp()/longjmp() type functionality? That's how I cheated implementing a Lisp in C. When tail recursing I'd let the stack grow a while, nuke it with longjmp(), and keep going.
That was a long time ago and I didn't know nearly as much about PL design and implementation as I do now, but it set me on the path. Funny thing was I started that project just to prove to myself that I could still write C since I'd been doing a ton of Perl.
If you discovered that trick yourself, you're very clever. It was documented by Henry Baker and is implemented in Chicken Scheme.
The basic ideas are:
1. All allocations (e.g. consing) take from the stack.
2. Tail calls are stack calls, so we keep consuming stack.
3. No function ever returns; all calls are tail calls. The Lisp code is CPS-transformed. (Since functions in the compiled code don't actually return even when appearing to, the stack-allocated objects remain nicely valid.)
4. When the stack reaches a certain limit, we rewind it. At that point, all the data which we consed on that stack which is still reachable is relocated to the heap, so they remain valid while we clobber the original stack.
- Be armchair-interested in programming languages
- Take some PL-whatever courses in college
- Read about PLs
- Read about progressively niche PL stuff…
- Get idealistic (get ideas)
- Read about the grueling design process of useful-in-the-real-world languages
- Eventually realize that There Are Always Tradeoffs
- Realize that the Tradeoffs are like two thousand parameters that might interact in super-weird and non-obvious ways
- Realize that a dozen super-competent PhD-wielders and multi-decade practitioners can easily spend a decade on developing the core of a language
- eh, why bother