Ask HN: What's a starting point for learning how to write programming languages?

Declarative thingies are easier to parse? You can skip a lot of these steps, I guess --- or just stop at a working interpreter, which will get you as far as MRI Ruby got before RoR took off.

For my capstone class for my CS BS, we had to write a compiler that compiled to machine code that the virtual machines we wrote could run. I can't remember the name of the book, but we called it "The Dragon Book." Looking in the other comments, it looks like someone already linked it.

Write a DSL. This is really easy in languages like Ruby that don't need parentheses around function parameters. You can write a Ruby DSL in a few hours and expand on syntax, features as you like.

The next step is to actually parse code with an abstract syntax tree. The easy path here is actually javascript. There are many transpilers for JS so things like bluebird/harmony can work.

Next step is to do thing "the right way"(tm) with yak/bison and build a compilable language. For that, I suggest you read a few books on languages and understand concepts such as backus-naur form before continuing.

I spent 3 years writing como-lang https://github.com/analang/ana I didn’t have a compilers course at my college. I think the first thing you should understand is how a language works. The first part is the syntax and grammar. It would also be very useful to know how assembly works, as than you’re probably keen on stack machines, which are very simple, yet powerful machines capable of representing expressions in a linear way. Feel free to email me if you have any questions! I’d love to help you get on the right track.

When I was learning, my only resources were books, google, and PHP-src and CPython.

In phases, this is roughly how I learned:

1. Cute hacks like using the eval function in Python and rewriting the string before passing it in. This is basically metaprogramming by macro-processing and a good stepping stone to thinking about what a programming language really accomplishes.

2. Writing various Forth-like and Lisp-like languages. This let me explore a working system without spending too much time on parsing - I could try interpreting the AST directly or compiling it to an intermediate language.

3. Gradually learned that a lot of the features and technologies in general purpose programming languages aren't things I want to care about(how to implement arithmetic, perform variable assignment, perform typechecking etc.). Focused on data languages like JSON and small supplemental languages for e.g. scheduling concurrency.

4. Found a useful model for prototyping semantics before adding a syntax, by envisioning the whole language in the form of a state machine that builds expressions one API call at a time, then compiles/executes the result with a "commit" call or similar. This is a practical technique for many domain specific problems, and makes the necessary syntax emerge naturally.

A lot of what goes into making a useful production language isn't really on the theoretical side, but on finish-and-polish stuff: fast builds, helpful docs and error messages, well-rounded libraries, debugging tools, ease of deployment and so on. Learning this through the process of writing small PLs helped change how I viewed language selection to be more like picking any other application, vs a point of religion: choosing something with approximately the right features and tooling so that the groundwork is easy, and then magnifying that leverage by adding a bit of custom syntax, static checking, code generation, what-have-you on top. Turning the tech into an airtight abstraction generalized across a whole language is a ton of work, but getting 80% of it in for the specific app takes a fraction of the time in comparison.