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.
Hello!
This is the current Lemmy equivalent of https://www.reddit.com/r/ProgrammingLanguages/.
The content and rules are the same here as they are over there. Taken directly from the /r/ProgrammingLanguages overview:
This community is dedicated to the theory, design and implementation of programming languages.
Be nice to each other. Flame wars and rants are not welcomed. Please also put some effort into your post.
This isn't the right place to ask questions such as "What language should I use for X", "what language should I learn", and "what's your favorite language". Such questions should be posted in /c/learn_programming or /c/programming.
This is the right place for posts like the following:
See /r/ProgrammingLanguages for specific examples
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))
Let the LLM fill in the details
don't tempt me frodo!
There are some things that it is better to begin than to refuse, even though the end may be dark.
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 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.