4 ms·

To step back a bit, the way I see it, the main goal as a language designer is to ensure that users can be productive in the language. Many factors play a role h

To step back a bit, the way I see it, the main goal as a language designer is to ensure that users can be productive in the language. Many factors play a role here. Language features are an obvious one, but there's also (in no particular order): standard library, ease of integration with other code, documentation, community, tooling, etc. That's a lot, so as daxfohl says, picking your battles is key. Not everyone will agree on the relative priorities of these factors, and that's totally fine too. However, I personally think that tooling is (one of the) super important factors. "Fast & snappy tools" is actually one of the explicit design goals for Muon [1] (design principle #12). So releasing a language server so early on in the life of the language underscores that, yes, Muon is a language with a strong tooling focus, and I hope that resonates with people. [1] https://github.com/nickmqb/muon https://github.com/nickmqb/muon

UglyToad 7y ago
Thank you for your detailed response and the great article. I'm interested in whether the focus on tooling as one of the priorities ended up informing elements of the language design. To take an example mentioned elsewhere, autocomplete is (generally) easier to implement for OO languages than FP ones because the dot syntax for method calls helps scope the options. Are there instances where you've changed design or felt constrained by making it work with tools?
- nickmqb 7y ago
  One design decision that comes to mind is Muon's significant whitespace. Having that makes it much easier to do parser error recovery, which in turn made it easier to build the language server. Another one is that I initially had the rule that all typenames had to start with a capital letter, and nothing else could. Which simplified parsing even further, but turned out to be too restrictive, so I got rid of that. Your question is something I've wondered about too. How can the design of a language co-evolve with its tools? If you have pointers to existing research on this I would be interested to learn about it.
  - daxfohl 7y ago
    Ooh, great question and answer. I'd never thought of that advantage of significant whitespace.

UglyToad 7y ago

Thank you for your detailed response and the great article. I'm interested in whether the focus on tooling as one of the priorities ended up informing elements of the language design. To take an example mentioned elsewhere, autocomplete is (generally) easier to implement for OO languages than FP ones because the dot syntax for method calls helps scope the options. Are there instances where you've changed design or felt constrained by making it work with tools?

nickmqb 7y ago
One design decision that comes to mind is Muon's significant whitespace. Having that makes it much easier to do parser error recovery, which in turn made it easier to build the language server. Another one is that I initially had the rule that all typenames had to start with a capital letter, and nothing else could. Which simplified parsing even further, but turned out to be too restrictive, so I got rid of that. Your question is something I've wondered about too. How can the design of a language co-evolve with its tools? If you have pointers to existing research on this I would be interested to learn about it.
- daxfohl 7y ago
  Ooh, great question and answer. I'd never thought of that advantage of significant whitespace.