4 ms·

Same is true for compilers. and actually, modern compilers already include the LSP business logic. Therefore, it is not a waste. Especially since languages exis

by oaiey 6y ago

Same is true for compilers. and actually, modern compilers already include the LSP business logic. Therefore, it is not a waste. Especially since languages exist outside of a single idea system like IDEA

kuschku 6y ago
> Same is true for compilers. Which are mostly collections of dozens of languages and dozens of backends reusing the same functionality in compiler collections like the GCC or LLVM. Instead, with LSP, every single one reimplements everything from scratch. And the features available to you differ heavily from one language to another.
- brundolf 6y ago
  > every single one reimplements everything from scratch Still not sure where you're getting this idea that everything has to be done over from scratch. Code sharing is code sharing; the only new thing that fundamentally has to be written is the mapping to a particular public interface, but that had to be done anyway because no previous interface was generic enough to be used by all possible editors. As an example: the original RLS mostly just uses Rust's existing compiler internals. It doesn't perform super well, because rustc is optimized for full-build usecases and not interactive/partial usecases. But it didn't have to be written in a clean-room environment just because it's exposing a new API to the outside world.
  - kuschku 6y ago
    Rustc has code to refactor-rename variables across multiple files? Code to extract the implementation of a function out into a separate file? Code to turn duplicated code automatically into a macro? The significant task in a language server isn't the "parse and show types" part but the "provide resharper-like refactoring functionality". And every single language server has to reimplement all these from scratch. And every single language server ends up with slightly different refactoring functionality, no standardisation or anything. Compare that to IDEA, where changing the type of a function at one point, and propagating that change to all calling functions across the whole code base is a single key stroke — and always the same, no matter which language you use. That's what I'm complaining about. LSP is an improvement for editors, but significantly worse than the alternative for actual IDEs.
    - matklad 6y ago
      >And every single language server has to reimplement all these from scratch. This is mostly true about IDEA as well. Take a look at the extractFunction implementation from IntelliJ Rust: https://github.com/intellij-rust/intellij-rust/tree/6b2c4dfaa8f1a27efbd4c0580e868a3df14de92d/src/main/kotlin/org/rust/ide/refactoring/extractFunction https://github.com/intellij-rust/intellij-rust/tree/6b2c4dfa... It is based on a generic `RefactoringActionHandler`, and not on the specialized `ExtractFunctionActionHandler`. There's relatively little code sharing you can do for high-level things in IDEs. The use interface sharing is another thing, and that is exactly what LSP achieves: it standardizes common actions across many languages.
- deleted 6y ago
  [deleted]

by oaiey 6y ago

kuschku 6y ago

> Same is true for compilers. Which are mostly collections of dozens of languages and dozens of backends reusing the same functionality in compiler collections like the GCC or LLVM. Instead, with LSP, every single one reimplements everything from scratch. And the features available to you differ heavily from one language to another.

brundolf 6y ago
> every single one reimplements everything from scratch Still not sure where you're getting this idea that everything has to be done over from scratch. Code sharing is code sharing; the only new thing that fundamentally has to be written is the mapping to a particular public interface, but that had to be done anyway because no previous interface was generic enough to be used by all possible editors. As an example: the original RLS mostly just uses Rust's existing compiler internals. It doesn't perform super well, because rustc is optimized for full-build usecases and not interactive/partial usecases. But it didn't have to be written in a clean-room environment just because it's exposing a new API to the outside world.
- kuschku 6y ago
  Rustc has code to refactor-rename variables across multiple files? Code to extract the implementation of a function out into a separate file? Code to turn duplicated code automatically into a macro? The significant task in a language server isn't the "parse and show types" part but the "provide resharper-like refactoring functionality". And every single language server has to reimplement all these from scratch. And every single language server ends up with slightly different refactoring functionality, no standardisation or anything. Compare that to IDEA, where changing the type of a function at one point, and propagating that change to all calling functions across the whole code base is a single key stroke — and always the same, no matter which language you use. That's what I'm complaining about. LSP is an improvement for editors, but significantly worse than the alternative for actual IDEs.
  - matklad 6y ago
    >And every single language server has to reimplement all these from scratch. This is mostly true about IDEA as well. Take a look at the extractFunction implementation from IntelliJ Rust: https://github.com/intellij-rust/intellij-rust/tree/6b2c4dfaa8f1a27efbd4c0580e868a3df14de92d/src/main/kotlin/org/rust/ide/refactoring/extractFunction https://github.com/intellij-rust/intellij-rust/tree/6b2c4dfa... It is based on a generic `RefactoringActionHandler`, and not on the specialized `ExtractFunctionActionHandler`. There's relatively little code sharing you can do for high-level things in IDEs. The use interface sharing is another thing, and that is exactly what LSP achieves: it standardizes common actions across many languages.
deleted 6y ago
[deleted]