Or do none of that. I understand that this article is meant to encourage people to learn some cool stuff within programming languages, but it’s also discouraging. The better answer in my view is to learn how to build a tree walking interpreter with Crafting Interpreters, then build whatever comes to mind. Want functional programming? Add immutability and first class functions. How about concurrency? Add an event queue. Then try to make a bytecode interpreter or a compiler. Sure these ideas require some of the knowledge detailed in the article, but you can learn that info JIT. Don’t try to learn it all before you get started. Just start and see what happens.
I think most people who are interested in programming languages would do well to start by making toy languages. There's a lot of pressure in trying to make something "useful", and you're almost certainly not going to succeed at that on your first attempt anyway.
The list of prerequisites in the article is extensive, overwhelming, and largely unnecessary if you're just getting started. Most of the concepts that it lists as "prerequisites" are ones that I finally understood while implementing a toy language, not stuff that I studied ahead of time.
Part of the usefulness of the guide might be to dissuade people from even trying, by showing them how hard language design is.
I don't think I would ever want to do anything beyond a DSL or bytecode for tiny 128 byte ish embedded config or the like, and even then only if nothing else worked.
The odds of usefulness are low even with pro backing. Understanding all this stuff puts you in a better position to decide it you actually want to try.
With toy projects you can just keep iterating and iterating and never get anywhere, and not really fully realized why it's not successful.
> Part of the usefulness of the guide might be to dissuade people from even trying, by showing them how hard language design is.
That is a bad thing. Going deep in any domain is hard; the thing to do is make the on-ramp gentler so more people can try it out, not make it steeper to discourage new learners.
If someone wants to start making games, we tell them to start off by cloning Pong or Breakout. We don’t say “be careful, here’s the long list of topics you’ll need to understand before you can make Fortnite.”
Yes, but if you approach it as a toy then "success" doesn't mean "wide usage" it means "I had fun and learned stuff".
I love Crafting Interpreters in part because he's explicit about this being mostly about learning and about play. I love languages (spoken, written, programming) and it was a great introduction that really got me rolling.
Articles like this consistently overwhelmed me, with the result being that I didn't really try it until years after I wanted to. Yeah, languages aren't for everyone, but specifically trying to scare people off of it seems harsh and unnecessary.
> Yeah, languages aren't for everyone, but specifically trying to scare people off of it seems harsh and unnecessary.
That depends. It's really hard to articulate just how much work is involved in writing a programming language. It's one of the classic infinite time sinks that exists in the CS field; no matter how much work you put into it, there's more to be done. It's very hard to ever call it "finished". I've seen a lot of language projects start as "I was working on this other thing and then I thought to myself, gee, here's a great opportunity for a programming language to make this easier." 8 years later they're still working on that programming language, the original project a distant memory.
Programming languages have a way of sucking in developers without them realizing it until it's too late. So while I wouldn't dissuade anyone from writing a PL per se, I would warn them that writing a PL is a *huge* undertaking in its own right, and should really never be undertaken to help you solve your own problems. If you want to go this route, then you need to abandon your problem and focus on the PL instead.
I'd almost agree, but at the same time such work can be a lot of fun.
Personally I think an average programmer could knock out a BASIC, FORTH, or similar programming language - with extensions - in a few months of part-time work, if not less.
The harder part, the part that I can see taking a lot of time, is trying to create a "batteries included" language which has a very complete and complex standard library.
Sure there are cheats if you're able to use dlopen, and FFI, to access C-stuff, but it's still not easy to create client-libraries for MySQL, Postgres, Redis, HTTP, etc, etc. Those kind of extensions/support make your language very very useful for users though. So there's a trade-off.
I've put together a couple of simple languages, with a standard-library of maybe 30 functions. I'd draw the line at anything more no matter how appealing it might seem because I can just imagine how much of a time-sink it might become.
The article is aimed at people hoping to make an actual useful language.
Lots of people could make a BASIC or a FORTH in a week. It would almost certainly be rather useless, unless the language itself is the point of the project using it.
99% of GitHub repos appear to be useless. They show up because someone wanted to make a simpler version of something that they can understand.
They don't teach much about the mainstream professional way. They often don't perform better, since things like GPU and SIMD are more important than simplicity.
They are perfectly fine as toy projects. I have a few myself(Although none of them use any real interesting algorithms or new concepts or anything). But that's... all they are.
At most they will become super niche things like suckless.
But all programmers should know that Electron apps run just fine even on cheap modern hardware, and that existing solutions are probably going to be better than anything you can do, unless you spend months to years like they did.
The programming community doesn't really seem to respect just doing everything by the book, the way a Microsoft dev would, and it's cool to see someone reminding people that it's a perfect good option to just grab some npm packages and make your thing and not bog yourself down with how it all works.
Yeah you’re right. I guess I’m saying that you gotta build a few toy languages before the big one. I don’t think you can read all of the material in the blog, then go build a language that people would actually use. Ideally you should concurrently read the material, work on a toy language, and work on an existing language.
It's a page from Loyola Marymount University's Compilers course, which involves building a compiler for a language of your own design. This is basically a syllabus for a course that has a lot more detail at each stage.
