This article is bugging me for some reason. I don't disagree with it. It's certainly easier to make a language now, even more so than in 2016 when this article was published. But it feels like saying "it's easier to make a bridge than ever". That statement isn't wrong. I'd much rather make a bridge with modern technology. But it's still a damn hard task.<p>And citing parsing isn't a great example. Parser generators have been around for ages. And they're usually not the hard part anyways. Defining a simple grammar and parsing it, even manually, isn't that terrible of a task. Getting decent error messages and figuring out recovery? That's trickier.<p>Code generation has certainly gotten easier. But you still need to go through the process of figuring out how to lower your abstractions. My language is still extremely basic but I've still had to map my high level types and control structures down to WebAssembly. LLVM won't do that for you.<p>There's also more that your average user expects if you want a language that people use. Decent tooling is important, so a language server and some syntax highlighting packages in different editors. Good error messages. Decent type inference. Most of these you can eschew in the first few iterations of your language but eventually you'll need them.<p>I feel bad criticizing this post because writing a language has been one of the most instructive experiences I've had. I've learned so much about code generation, typechecking, the WASM spec, etc. But it's still a lot of tough work to get to something people can use. I'm not sure parser generators and LLVM make it that much easier.
I'm all for writing one's own language. However, anyone who does this should be sentenced to writing a significant program in this language afterwards. Only then can they discover how wonderful or (more likely) horrible their creation actually is. Writing Towers of Hanoi in it doesn't count.<p>Also, if this language isn't just going to be a toy, they need to write some sort of specification document about it. I'm tired of seeing new language websites announcing version 0.9 of the new language, accompanied by a statement that “we haven't yet written a language manual, but here are some example programs and some obsolete papers about prior versions”.<p>I used to work in a senior position at a multinational firm. At one point, I went to the site of a company that had been recently purchased by my employers. Their major product was a large online system that was substantially written in a custom language. At that point, since the principals in the original company had left, there was not one employee left who understood this language completely.
+1 for LLVM. It's hard to grok at first, but the Kaleidoscope ([0]) tutorial lets you hit the ground running. After that, it's very rewarding to learn LLVM's API by googling, poking around their excellent source code, and having clang emit IR for you (`clang -S -emit-llvm -O0 test.c`)<p>[0]: <a href="https://llvm.org/docs/tutorial/MyFirstLanguageFrontend/index.html" rel="nofollow">https://llvm.org/docs/tutorial/MyFirstLanguageFrontend/index...</a>
The article takes the approach of gluing together disparate solutions to write a language. With a functional language as your base, writing a new language can be quite elegant and fun! A great series by Stephen Diehl <a href="http://dev.stephendiehl.com/fun/" rel="nofollow">http://dev.stephendiehl.com/fun/</a> covers the subject in good detail and the fvg Lang <a href="https://github.com/Lemmih/fvg" rel="nofollow">https://github.com/Lemmih/fvg</a> is a nice reference.
I am not sure I agree with the claim. What’s really easier with the proposed approach (using a
python port of lex and yacc and generating LLVM) than using yacc and lex (with all their warts) to generate C code for your own language was in 1980?<p>Yes, if your language doesn’t fit C, your implementation could be more efficient (potentially a lot), but getting there isn’t easier.<p>I think we got a lot of complexity and options since then that distract from “writing your own language”.<p>I think a claim that we can do better than lex and yacc nowadays (e.g. using Haskell) would be a much stronger argument for “it’s much easier now”
Our platform lets users create animations in minutes. We use natural language in our scripts.<p>Eg.
Cowboy say "Hi there."
Wait for 2 seconds.
Cowboy run to Point P2 in 3 seconds.<p>It has been an eye opening and learning exercise. The advantage is even first time users can start using our language. Disadvantage natural language has such a wide variety of usage styles that it's a challenge.<p><a href="https://toonclip.com" rel="nofollow">https://toonclip.com</a>
It was always easy to write your own language. Hard was making that language be a mature one with plenty of libraries for mundane tasks covering all needs people want. And harder was to make said language to be adopted and become mainstream.
Another option that may be useful: transform a custom syntax to an existing language.<p>And while you are at it, why not try to write a parser to reverse the process? :)
Use the Forth, Luke!<p><a href="https://github.com/codr7/gfoo" rel="nofollow">https://github.com/codr7/gfoo</a>