Hacker News Reader

Comment by mgraczyk | Hacker News Reader

Read the linked email thread and decide for yourself.

He doesn't know operator overloading exists. Then when he's told and given an example he claims it doesn't interact with type deduction in a way that is not true in C++. Then when given a simple example with auto he claims that the method overload resolution is equivalent to finding the right return type, ignoring multiple overloads and the possibility of type conversion after the function returns.

All these mistakes are acceptable, but when they were pointed out to him, he reacted by claiming blanket bad faith on everyone who was trying to justify using the full AST. He then said he wouldn't listen to them and instead would talk to "people he trusts".

View on HN

His approach to implementing this feature would have been “if code completion needs data X from the code, we provide an API for that”, and repeat this for all other possible use cases. This, to protect the AST.

This is of course technically feasible, but a huge amount of effort, and will constantly have to be updated / changed. When people are effectively arguing “it’s a much more forward-compatible and scalable approach to let tools use the AST directly”, he rejects that as changing the discussion, not a concrete example, and/or pressuring.

This is super ironic coming from someone who made an editor entirely based on LISP, which is successful precisely because it is completely transparent and anything can be changed / inspected / done.

Given the success of LSP in the recent years, it’s super evident that RMS was wrong on this matter. It has created an ecosystem for LSP around clang, and the integration with emacs is great.

> Given the success of LSP in the recent years, it’s super evident that RMS was wrong on this matter.

But the LSP doesn't expose the AST. It just expose what the editor needs. That looks like the kind of interface RMS was asking for.

Sometimes the editor needs the AST, and LSP is general enough that language implementations can expose it. For example

https://clangd.llvm.org/extensions#ast

Sure, but the "success of LSP in the recent years" was not because of that extension.

To be more accurate, this to protect an AST parsed into source code that is _readily available_ for anyone who wants it, because... it's open source. Anyone with knowledge of GCC could write a patch in a week or so to dump the AST into JSON and publish it as a patch.

You're right, too, though: this exact argument is part of why LSP and clang won. When people showed up (in _2015_!) to try to start on support for this sort of thing in emacs and gcc, the dictator at the top could not be convinced this was worthwhile. And now the world uses Clang and LSP and the GNU counterparts get dustier and dustier.

Ironically that's what modern LSPs are, aren't they? An API on the handful of use cases an IDE might want to care about.

Yes but I don’t think that could have happened if they were not decoupled from the compiler.

But yes it’s a good point that LSPs are actually an API for editors instead of exposing the AST to the editors directly, but from the discussion I’m fairly convinced that RMS lacked the imagination of all the possibilities LSPs could create.

And it’s also quite ironic that he resisted opening up the compiler to support these kind of tools, and it ended up being a for-profit corporation that spearheaded this whole open standard / ecosystem of LSPs.

Reply on news.ycombinator.com