3 ms·

I'm yet to see RMS out of his depth in any technical discussion of computer science related matters and I think it's a very big call for anyone to make without

by oska 4y ago

I'm yet to see RMS out of his depth in any technical discussion of computer science related matters and I think it's a very big call for anyone to make without backing the assertion up (as you very noticeably failed to do). RMS has a towering reputation in the computer science field based on very significant accomplisments, that is undeniable. Any random person on a forum is welcome to challenge that reputation, but they'll need to do it properly, not just sling mud.

mgraczyk 4y ago
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".
- stingraycharles 4y ago
  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.
  - varajelle 4y ago
    > 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.
    - mgraczyk 4y ago
      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 https://clangd.llvm.org/extensions#ast
      - varajelle 4y ago
        Sure, but the "success of LSP in the recent years" was not because of that extension.
  - leni536 4y ago
    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.
    - stingraycharles 4y ago
      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.
  - discardable_dan 4y ago
    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.
matheusmoreira 4y ago
The man is right about a lot of things but the GCC thing isn't one of them. First time I read those emails it permanently changed the way I looked at GNU software. Now I always wonder if they crippled something on purpose every time I run into any difficulty. For example, is this the reason why GCC is unable to output source file dependency data in anything but makefile format? That would make so much sense.

by oska 4y ago

mgraczyk 4y ago

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".

stingraycharles 4y ago
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.
- varajelle 4y ago
  > 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.
  - mgraczyk 4y ago
    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 https://clangd.llvm.org/extensions#ast
    - varajelle 4y ago
      Sure, but the "success of LSP in the recent years" was not because of that extension.
- leni536 4y ago
  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.
  - stingraycharles 4y ago
    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.
- discardable_dan 4y ago
  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.

matheusmoreira 4y ago

The man is right about a lot of things but the GCC thing isn't one of them. First time I read those emails it permanently changed the way I looked at GNU software. Now I always wonder if they crippled something on purpose every time I run into any difficulty. For example, is this the reason why GCC is unable to output source file dependency data in anything but makefile format? That would make so much sense.