5 ms·

No, it's merely a work-around for two very distinct and self-inflicted problems: - The pain of exposing language-native compiler/language AST and indexing APIs

No, it's merely a work-around for two very distinct and self-inflicted problems: - The pain of exposing language-native compiler/language AST and indexing APIs to a JavaScript IDE. - RMS' inability to accept that GCC might need to expose an AST to external consumers, and his paranoia regarding how that might undermine his GPL-everywhere ideals. Using JSON for local IPC -- and requiring IDE language support to funnel itself across that high-overhead IPC connection -- is fey.

barrkel 9y ago
LSP is sensible for the same reason that the middle end in a compiler is sensible - it turns an MxN problem into an M+N problem. For compilers, M is source languages and N is target platforms. For LSP, M is source languages and N is editors. They both have the same downside. The more esoteric the language feature, the lower the fidelity of support in the common middle.
- teacup50 9y ago
  Libraries solve the problem of said middle end in a compiler, and in an IDE. If you insist on using IPC, then you've incurred a great deal of friction in a place that it matters. If you insist on using JSON IPC, then you've incurred a great deal of overhead in a place that it matters.
  - jblow 9y ago
    This times 1000. AN API IS ALREADY A PROTOCOL but it doesn't require external processes, serialization, extra failure modes, etc, etc. The fact that the HN community seems to have jumped aboard this idea, "yeah let's just require a server to do something simple like format text in your editor", is completely flabbergasting. People just seem to have NO IDEA how much complexity they are adding, and don't care. Maybe in 5 years our machines will be running 10,000 processes at boot because people will want a server for every operation...
    - yorwba 9y ago
      Do you know how these IDE features are currently implemented in editors like vim? Unless there is built-in support (e.g. ctags), most plug-ins that provide language-specific features do so by running an external tool, sometimes going so far as scraping the compiler output. This means that on every single change, a new heavyweight process is created, communication happens over unspecified textual formats, and everything is likely to break with the next update because there is no stable interface. JSON IPC with a continuously-running process using a well-specified protocol is a huge step up in comparison.
      - jblow 9y ago
        Just because the current way it's done is terrible, doesn't mean you should "upgrade" to a bad way instead of a good way.
        StavrosK 9y ago
        What would a good way be? Why is having the code completion and parsing in a self-contained library a bad way? Or are you just opposed to using TCP instead of an ABI?
    - barrkel 9y ago
      An API that can be accessed from heterogeneous languages will involve IPC. Particularly since the best API will use the compiler's symbol tables (avoiding implementing syntactic and semantic analysis twice, buggily), and compiler implementation languages are even more diverse than editor implementation languages.
      - jblow 9y ago
        > An API that can be accessed from heterogeneous languages will involve IPC. No. If your language cannot call into a dynamic library using a well-defined C ABI for your platform, then it is already failing to speak a standard protocol. Building all kinds of crazy, complicated, slow infrastructure in order to get it to successfully speak some other protocol, is a symptom of modern-day clueless programming. > Particularly since the best API will use the compiler's symbol tables (avoiding implementing syntactic and semantic analysis twice, buggily) Yes, this is of course a good idea. Why one presumes this requires a separate running process, I have no idea.
  - barrkel 9y ago
    What library supports C, C++, Lisp, Java, JS and C# callers?
    - jackmott 9y ago
      I think any C api should be target-able by all of those.
    - kuschku 9y ago
      The JetBrains IDE libraries? Those are separate libraries with support for C, C++, Clojure, Java, Kotlin, C#, JS, PHP, Python, and more. All of them exposing the entire AST and the entire environment, which is far more than LSP ever did.
      - Matthias247 9y ago
        The question was not which library could present an AST for all those languages, but which kind of library format can be consumed from all those languages. And ideally without FFI and writing complex wrappers. C libraries non very convenient to use from C#, JVM, JS (node.js) or sometimes it isn't even possible (e.g. for JS in the browser). The question is important, because otherwise one would constrain editors to be written only in a language which is compatible to the library format.
        kuschku 9y ago
        Using C libraries from C# or the JVM is very convenient, even today. There’s even automated systems to generate the entire bindings for the JVM, I’ve written bindings myself for a few libraries. You can just generate the interface file for Java from the .h with JNAerator, import it, and you’re done.
        wtetzner 9y ago
        That doesn't solve the problem of a segfault in the C library crashing the entire JVM.
kibwen 9y ago
LSP--or rather the general idea of a common interface between IDEs and language-specific static analyzers--is a very good idea regardless of GCC or VSCode. Which isn't to say that LSP made universally correct design decisions (e.g. it's fair to be grumpy at JSON), and also isn't to say that it represents the be-all end-all of IDE integration (the fact that it necessarily represents a lowest-common-denominator interface is well-understood). But having such a standard to establish a baseline of support between languages and editors with the minimal amount of work possible is something that needed to be done.
bpicolo 9y ago
Whether or not the IDE is JS based is asymmetrical. A common format for any IDE to integrate with is a fantastic idea.
- teacup50 9y ago
  That would be an API; JSON IPC is used because of the difficulty in hoisting language-native AST/indexing APIs into JavaScript.
  - bpicolo 9y ago
    That's true for every combination of language / platform where the languages differ. Rewriting AST parsers for every language would be nuts. Overall this vastly increases accessibility / choice when it comes to languages. That's purely a good thing. People are still free to make hyper-optimized versions for whatever case they would like to.
  - jahewson 9y ago
    I don't see that as actually being true. There are thousands of native npm modules which work just fine with Electron. There's really no problem exposing native APIs to JS. What VSCode has pioneered, and this is something which Atom got wrong, is a multi-process model, where the various IDE components communicate via IPC. This improves stability and allows isolation of 3rd party plugins, and provides mostly foolproof parallelism. When plugins are such a big part of the experience, this is a very good thing. It's a deliberate design decision, not some attempt to overcome the failings of JavaScript. Couple this with the fact that limiting "API" to mean "C ABI" forces every compiler author to start exposing complex C structures, unsafe pointers and the like - which if their compiler is written in, say Haskell, or LISP is going to be particularly painful, v.s. implementing text-based RPC over a socket in whatever way is best for them. If Language Server had been a C API then I seriously doubt it would have got much traction, as it's just too awkward for many compiler authors to implement. Unsafe C APIs are, frankly, last century's technology.
    - pjmlp 9y ago
radarsat1 9y ago
Regardless of those points, having a standard protocol for this kind of thing makes a lot of sense, instead of binding directly to the AST data structures of each compiler.
jackmott 9y ago
let me clarify: shipping along with your language, some kind of API that is standardized so that editors can easily add high quality IDE level features to support new languages is a great idea that this is currently being done via a server + json over pipes or whatever is a suboptimal way to do it, I agree.

barrkel 9y ago

LSP is sensible for the same reason that the middle end in a compiler is sensible - it turns an MxN problem into an M+N problem. For compilers, M is source languages and N is target platforms. For LSP, M is source languages and N is editors. They both have the same downside. The more esoteric the language feature, the lower the fidelity of support in the common middle.

teacup50 9y ago
Libraries solve the problem of said middle end in a compiler, and in an IDE. If you insist on using IPC, then you've incurred a great deal of friction in a place that it matters. If you insist on using JSON IPC, then you've incurred a great deal of overhead in a place that it matters.
- jblow 9y ago
  This times 1000. AN API IS ALREADY A PROTOCOL but it doesn't require external processes, serialization, extra failure modes, etc, etc. The fact that the HN community seems to have jumped aboard this idea, "yeah let's just require a server to do something simple like format text in your editor", is completely flabbergasting. People just seem to have NO IDEA how much complexity they are adding, and don't care. Maybe in 5 years our machines will be running 10,000 processes at boot because people will want a server for every operation...
  - yorwba 9y ago
    Do you know how these IDE features are currently implemented in editors like vim? Unless there is built-in support (e.g. ctags), most plug-ins that provide language-specific features do so by running an external tool, sometimes going so far as scraping the compiler output. This means that on every single change, a new heavyweight process is created, communication happens over unspecified textual formats, and everything is likely to break with the next update because there is no stable interface. JSON IPC with a continuously-running process using a well-specified protocol is a huge step up in comparison.
    - jblow 9y ago
      Just because the current way it's done is terrible, doesn't mean you should "upgrade" to a bad way instead of a good way.
      - StavrosK 9y ago
        What would a good way be? Why is having the code completion and parsing in a self-contained library a bad way? Or are you just opposed to using TCP instead of an ABI?
  - barrkel 9y ago
    An API that can be accessed from heterogeneous languages will involve IPC. Particularly since the best API will use the compiler's symbol tables (avoiding implementing syntactic and semantic analysis twice, buggily), and compiler implementation languages are even more diverse than editor implementation languages.
    - jblow 9y ago
      > An API that can be accessed from heterogeneous languages will involve IPC. No. If your language cannot call into a dynamic library using a well-defined C ABI for your platform, then it is already failing to speak a standard protocol. Building all kinds of crazy, complicated, slow infrastructure in order to get it to successfully speak some other protocol, is a symptom of modern-day clueless programming. > Particularly since the best API will use the compiler's symbol tables (avoiding implementing syntactic and semantic analysis twice, buggily) Yes, this is of course a good idea. Why one presumes this requires a separate running process, I have no idea.
- barrkel 9y ago
  What library supports C, C++, Lisp, Java, JS and C# callers?
  - jackmott 9y ago
    I think any C api should be target-able by all of those.
  - kuschku 9y ago
    The JetBrains IDE libraries? Those are separate libraries with support for C, C++, Clojure, Java, Kotlin, C#, JS, PHP, Python, and more. All of them exposing the entire AST and the entire environment, which is far more than LSP ever did.
    - Matthias247 9y ago
      The question was not which library could present an AST for all those languages, but which kind of library format can be consumed from all those languages. And ideally without FFI and writing complex wrappers. C libraries non very convenient to use from C#, JVM, JS (node.js) or sometimes it isn't even possible (e.g. for JS in the browser). The question is important, because otherwise one would constrain editors to be written only in a language which is compatible to the library format.
      - kuschku 9y ago
        Using C libraries from C# or the JVM is very convenient, even today. There’s even automated systems to generate the entire bindings for the JVM, I’ve written bindings myself for a few libraries. You can just generate the interface file for Java from the .h with JNAerator, import it, and you’re done.
        wtetzner 9y ago
        That doesn't solve the problem of a segfault in the C library crashing the entire JVM.

kibwen 9y ago

LSP--or rather the general idea of a common interface between IDEs and language-specific static analyzers--is a very good idea regardless of GCC or VSCode. Which isn't to say that LSP made universally correct design decisions (e.g. it's fair to be grumpy at JSON), and also isn't to say that it represents the be-all end-all of IDE integration (the fact that it necessarily represents a lowest-common-denominator interface is well-understood). But having such a standard to establish a baseline of support between languages and editors with the minimal amount of work possible is something that needed to be done.

bpicolo 9y ago

Whether or not the IDE is JS based is asymmetrical. A common format for any IDE to integrate with is a fantastic idea.

teacup50 9y ago
That would be an API; JSON IPC is used because of the difficulty in hoisting language-native AST/indexing APIs into JavaScript.
- bpicolo 9y ago
  That's true for every combination of language / platform where the languages differ. Rewriting AST parsers for every language would be nuts. Overall this vastly increases accessibility / choice when it comes to languages. That's purely a good thing. People are still free to make hyper-optimized versions for whatever case they would like to.
- jahewson 9y ago
  I don't see that as actually being true. There are thousands of native npm modules which work just fine with Electron. There's really no problem exposing native APIs to JS. What VSCode has pioneered, and this is something which Atom got wrong, is a multi-process model, where the various IDE components communicate via IPC. This improves stability and allows isolation of 3rd party plugins, and provides mostly foolproof parallelism. When plugins are such a big part of the experience, this is a very good thing. It's a deliberate design decision, not some attempt to overcome the failings of JavaScript. Couple this with the fact that limiting "API" to mean "C ABI" forces every compiler author to start exposing complex C structures, unsafe pointers and the like - which if their compiler is written in, say Haskell, or LISP is going to be particularly painful, v.s. implementing text-based RPC over a socket in whatever way is best for them. If Language Server had been a C API then I seriously doubt it would have got much traction, as it's just too awkward for many compiler authors to implement. Unsafe C APIs are, frankly, last century's technology.
  - pjmlp 9y ago

radarsat1 9y ago

Regardless of those points, having a standard protocol for this kind of thing makes a lot of sense, instead of binding directly to the AST data structures of each compiler.

jackmott 9y ago

let me clarify: shipping along with your language, some kind of API that is standardized so that editors can easily add high quality IDE level features to support new languages is a great idea that this is currently being done via a server + json over pipes or whatever is a suboptimal way to do it, I agree.