
Building a language server for Muon - nickmqb
https://nickmqb.github.io/2019/11/24/building-a-language-server-for-muon.html
======
UglyToad
An interesting article.

I was minded to write an Ask HN related to this. Why do so many new languages
launch without what I'd consider to be essential functionality for any
language; autocomplete, good IDE integration, intellisense, auto refactoring
and navigation support?

I get that all languages are just text at the end of the day but are people
really holding the whole API surface and type arguments of standard libraries
and 3rd party libraries in their head? Do they remember variable names across
files and directories. I feel like my memory must be absolutely terrible
because there's no way I could work in a language without decent autocomplete.

~~~
skocznymroczny
Many projects are open-source, developed by the community. It comes with
several caveats:

1) many open-source developers use vim/emacs, maybe something like Sublime
Text and don't have experience with IDE offerings for languages like Java/C#.
As such, they don't really require much more than syntax highlighting and
basic autocompletion.

2) many of the new languages boast powerful metaprogramming capabilities.
Metaprogramming makes it very hard to implement working refactoring, because
the IDE cannot reason about the code as well as in more 'static' languages
like Java.

3) most new languages coming out are closer to the functional paradigm rather
than OOP. I think OOP lends itself much more for refactoring features and
things like autocomplete.

~~~
UglyToad
I think part of my question was related to your part 1. Are people genuinely
remembering the entire API surface of their application, their language's
standard library and all 3rd party dependencies for their code when using a
text-mode editor like Vim?

The only way I could possibly work like that is if my program wasn't bigger
than a couple of files not exceeding 50 lines or if I spent all day in the API
docs.

It has me worried I've just got incredibly early onset memory loss I guess.

~~~
samvher
I’m one of those vim users - I never use autocomplete, autorefactor or a
debugger for that matter. Occasionally I have them available in something like
RStudio but I don’t feel like I gain much from it.

I find myself constantly jumping through the code (with / for find) and I have
3 or 4 terminals open on the same display (to see how things are defined in
various files) with stackoverflow a key binding away. I definitely don’t
remember how exactly I named my variables but I find that at the same time
knowing just the variable name is not enough, I also want to see where and how
it’s defined. I use “grep -R” a lot for that as well.

Also often I end up editing files over ssh somewhere so then an IDE also
wouldn’t be available, and vim always is.

I’ve never tried tools for refactoring. But as mentioned elsewhere that
probably wouldn’t work well for functional and/or niche languages.

I generally feel pretty productive, if I had felt that there is a reward to
learning these IDEs I wouldn’t have hesitated to do so.

------
jimws
Lisp had this kind of interactive programming support for a long time using
SLIME and Emacs. Why isn't this a more common feature in the more recent
languages?

~~~
oaiey
There are two aspects here: Interactive Development is incredible difficult.
There is a talk of Anders Heijlsberg about that compiler building is no longer
the same than 10 years ago. When you code, you need sub-100-ms reactions, the
parser needs to be happy parsing incomplete, typically errorous code and then
you need a code analysis engine dealing with that half-baked AST. Also
traditional compilers are a strict pipeline and not a loop etc. Microsoft had
to rewrite the C# compiler for that. The PHP LSP had to create an own parser
engine because no suitable was available. It is essentially a lecture for
future language creator: If you write a compiler, do not only built it for
binary emitting but also for editors and analyzers.

And yes, the smart-asses of the 70/80s (aka LISP and Smalltalk) thought about
that long time before anyone else. But hey, today's landscape is a bit more
complex (think about CSS styles in a HTML embedded in a TypeScript enriched
JavaScript JSX file).

The second aspect: LSP is great because it was a cross-vendor, cross-language
initiative which had in its first year already two dozen languages on board in
addition to half a dozen editors (VS Code, Emacs, Atom, VIM, ...). Emacs
plugins could never deliver that because they were bound to Emacs.

~~~
TeMPOraL
RE the second aspect: that's why I'm a fan of LSP and the related debugging
server protocol. There's no way Emacs can have native IDE-like support for all
the languages out there, and the small developer base makes it hard to compete
with IDEs for popular languages, that have commercial interests backing them.
LSP promises to level the playing field - it only takes one good language
server to make IDE features suddenly available not just for IDEs, but also
Emacs and Vim and others.

------
ktm5j
I thought this article was about "building a language server" like the title
says, but this is really just a grammar set for an existing language server..
unless I'm missing something? I realize that this is being picky about
wording, but it's a little misleading.

~~~
nickmqb
Author here. I wrote both the language server and Muon compiler [1] from
scratch. The language server reuses the compiler code, for parsing and type
checking. I'm not sure which grammar you're referring to? The VS Code
extension [2] does contain a grammar, but it's only used for syntax
highlighting.

[1]
[https://github.com/nickmqb/muon/tree/master/compiler](https://github.com/nickmqb/muon/tree/master/compiler)
[2] [https://github.com/nickmqb/vscode-
muon](https://github.com/nickmqb/vscode-muon)

~~~
tasogare
The properties of the language listed on the websites are compelling, but I
wonder what are you using the language for except the compiler?

~~~
nickmqb
My main focus has been on the compiler and language server so far. Next up is
a tool for generating foreign function definitions. This tool will make it
easier to work with 3rd party libraries. Once ready, I'm planning on writing
some examples, such as perhaps a small OpenGL program to demonstrate this
functionality. Hopefully that will encourage users to give Muon a try for
their own projects!

------
ngcc_hk
Good article. In fact the muon is very doc. Still, one of the curse when
coping segment of python code is to handle those tab and white space. The muon
help to have a feature (first line say tab or space). Sigh muon opt for that
turn me off.

~~~
nickmqb
I agree that Muon's current handling of whitespace is not ideal. I have plans
to allow users to customize it. For now, you can use the //tab_size=N
directive as documented here:
[https://github.com/nickmqb/muon/blob/master/docs/muon_by_exa...](https://github.com/nickmqb/muon/blob/master/docs/muon_by_example.md#significant-
whitespace)

------
duckqlz
Moun’s for loops make me angry.

~~~
all2
Can you expand on this?

~~~
lioeters
From "Muon by example" [0], the for loops look pretty natural/intuitive
subjectively.

    
    
      for i := 1; i < n {
        temp := a
        a += b
        b = temp
      }
    

> `for` works mostly like in other imperative languages. For convenience, the
> 3rd term can be omitted; in that case, the index variable is incremented by
> 1 at the end of each iteration of the loop. The index variable is scoped to
> the loop body. The variable can be omitted if you want to use an existing
> index variable, e.g.: for ; i < n; i += 1 { ... }

With arrays:

    
    
      for x in arr {
        sum += x
      }
    
      for x, i in arr {
        sum += x
      }
    
      for arr {
        sum += it
      }
    

> A secondary loop variable may be specified which holds the index of the
> current element. If no loop variable is specified, the name `it` is used.

[0]
[https://github.com/nickmqb/muon/blob/master/docs/muon_by_exa...](https://github.com/nickmqb/muon/blob/master/docs/muon_by_example.md)

