I know I'm sidetracking the point but I despise projects - particularly game engines - that make up their own language and force you to use it.

Making a language is a good exercise and learning experience, but making a good language is hard.

If you want to give it a try, I highly recommend the book Crafting Interpreters. It's also available online in HTML format.

Edit: RTFA and I see that's what the author did as well!

Designing a language is easy. But the better the language is, the harder it is to make a compiler.

Gui.present(DoThatThingThatIWant(data))

don't tempt me frodo!

I work on a language for a living. It's fun! It's a job. But it's fun.

I'm not super involved with the traditional language parts. The design and parsing and optimization. I spent most of my time on the runtime. We're embedded in another big system and there's a lot of things to make it nice.

I spent the day wiring up more profile information for the times the runtime has to go async. Then I'll fix up some docs generation stuff. Eventually I'll get back to fun shadowing edge case in the new syntax I'm building.

I'll likely never get to or understand enough for the proje, but I dream of knowing FORTH well enough to write a threaded interpreter for a microcontroller, or something that a LLM agent could use in an unsupervised loop.

I did, once. While I never completed a compiler, it was an utter disaster, in that - in retrospect - it was everything I've subsequently learned to hate about PLs: multiple ways of solving the same problems, multiple modalities, and lots of rules. I was picking the best things I liked from many PLs and putting them all into one PL, and it was a horrible idea. I didn't start from fundamentals, and there was no BNF.

I still have the design document, which was fairly complete in describing the syntax and operation; enough that I'm pretty sure that with some time and effort with a good LLM, I could probably get the LLM to build an interpreter or compiler. But looking back on it, man. Was that a complete waste of time.

I don't think I learned anything from the experience. Having had a long career and deep exposure to a wide variety of languages taught me more about what I value than anything else. For example, my favorite interview question for developers became: "what aspects of language X (that we're hiring you for) do you dislike the most, and why? What are the biggest points of pain about the language?" Anybody can learn sufficient surface knowledge about a language to hiring tests; it's the demonstration of understanding the pitfalls that's most valuable.

You should preach to the choir.