3 ms·

You have to pick your battles. But I'll say that the Language Server Protocol is a game changer. Now at least the battle is communicating with a single well doc

You have to pick your battles. But I'll say that the Language Server Protocol is a game changer. Now at least the battle is communicating with a single well documented high level editor protocol that works everywhere. Prior you'd have to first choose an editor to integrate with, chug through far lower level details of how to color code, make dropdowns, etc, and do it in the editor's plugin language rather than your compiler's. My guess is you'll see more editor integration for new languages in the future if LSP stays relevant. In my own little toy languages, integration with LSP is one of the first things I do after I have the basis for a hello world. So, before if statements or loops. It makes a nice feeling to be able to see your language get to look like a professional thing so rapidly. Also I think it helps in developing the compiler, that you know in advance what functionality it needs to have in order to provide good editor support. Also helps guide what unit tests should look like, and helps find bugs because they are apparent as you type. So we could see an explosion of domain languages, since they are usually more about tooling, and with tooling a nice editor integration is very helpful.

nickmqb 7y ago
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.

nickmqb 7y ago

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.