This advice is quite good for certain types of programming language, if you look at the world the same was as he does. We're implementing Dark from a completely

This advice is quite good for certain types of programming language, if you look at the world the same was as he does. We're implementing Dark from a completely different worldview, and from that vantage point, a lot of these aren't exactly wrong, but different. > Syntax matters The approach we took with Dark is that there isn't a syntax, per se, in that there isn't a parser. There's certainly a textual view of Dark and so it's important that the code looks good (it currently looks only OK, in my opinion). But as a result, we have other options for minimizing keystrokes (autocomplete built-in), parsing (again, no parse), and minimizing keywords (you're allowed have a variant with the same name as a keyword, which isn't allowed in languages with parsers (well, lexers, but same idea). > context free grammars No parser, no need to have a grammar. His point about IDEs is great - we only support our own IDE (a controversial decision to be sure!) > Redundancy This is an esoteric parsing problem, that only applies if you have a parser. No parser means no syntax errors. We are left with editor errors (how does the editor have good UX) and run-time errors. > Implementation He's right about how hard error messages are, so I feel good about our "not parsing" approach. > Compiler speed Our compilation is instant. The way it's instant is: - very small compilation units: you're editing a single function at a time, and so nothing else needs to be parsed. - no parser: The editor directly updates the AST, so you don't have to read the whole file (there isn't a "file" concept). Even in JS, that means an update takes a few milliseconds at the most. - extremely incremental compilation: making a change in the editor only changes the exact AST construct that's changing. > Lowering This is really about compilation. One thing you can do, which is what we do, is have an interpreter. Now, interpreters are slow, but we simply have a different goal with the language, which is to run HTTP requests quickly. We do run into problems with the limit of the interpreter, but we plan to add a compiler later to deal with this. Really what I'm suggesting here is that compiled languages look at having interpreters in addition to compilers. > i/o performance > memory allocation I think he's approaching this with an implicit goal of "it must be as fast as possible", which isn't necessarily a goal for all languages. > You’ve done it, you’ve got a great prototype of the new language. Now what? Next comes the hardest part. This is where most new languages fail. You’ll be doing what every nascent rock band does — play shopping malls, high school dances, dive bars, etc., slowly building up an audience. For languages, this means preparing presentations, articles, tutorials, and books on the language. Then, going to programmer meetings, conferences, companies, anywhere they’ll have you, and show it off. You’ll get used to public speaking, and even find you enjoy it (I enjoy it a lot). Well this is certainly correct!