4 ms·

You don’t need to do a generic AST. Have it be a protocol ... that runs in-process via an API. Because you know what, that’s what an API is ... a protocol for c

• klmr 9y ago
  Right, this seems obvious. Any idea why they opted not to go that way? I guess the reason is that the original use-case was VS Code & TypeScript (?) and developing a lowest common denominator API for all clients would mean C, so they would have had to program to a C API even though both the client (VS Code?) and the server (Node?) are running JavaScript. But then maybe the answer should be to provide better C invoke wrappers for high-level languages, not to use HTTP instead of C.
  • frou_dh 9y ago
    Knowing programmers, it's probably an absolutely irresistible concept that the provider for a given language must be easy (in the Hickey-ian sense) to write entirely in that language.
    • Guillaume86 9y ago
      Seems a reasonable request to me.
    • zaphar 9y ago
      Not just a concept. Many languages are bootstrapped and therefore the canonical tools for understanding that languages syntax and semantics are in that languages stdlib. You would have replicate all of that in your IDE's language instead. It's DRY at work.
  • hasenj 9y ago
    I think the language server is not a solution to a technical problem; it's a solution to a social/political problem. How to support intellisense for a language one time and have it work on many editors?
• acdha 9y ago
  The downside to that approach is that it limits you to C calling conventions (most language communities are going to want to write in the target language) and means that the process will be as stable as the least stable plugin. Given how many bug reports were filed against every editor which has ever done that, it's easy to see the appeal of containment to the people working on an editor. The other side of that is that we're not in the 90s with single core processors and there's been a lot of hardware & software optimization over time. Most people can run something like VSCode and a language server and still have multiple cores left over — and since the events which trigger language server interactions are generally made by a human with a keyboard it's not like you need to be in the microsecond range to keep up.
  • hasenj 9y ago
    Try harder. A PC full of programs built with these assumptions will probably grind to a halt all the time despite having very high spec hardware.
    • acdha 9y ago
      That’s a lot of fearmongering with no evidence. Do you have profiler data showing that the microseconds needed to pass a message between a process is a significant limiting factor in a program which is rate-limited by human text entry? I mean, taking your argument seriously would mean everything should be hand-tuned assembly. Obviously we figured out that other factors like time to write, security, portability, flexibility, etc. matter as well and engineering is all about finding acceptable balances between them. Microsoft has been writing developer tools since the 1970s and in the absence of actual evidence I’m going to assume they made a well-reasoned decision.
      • ksk 9y ago
        It seems like the person was suggesting if all processes on your PC used a client/server model with message passing/RPC instead of the existing API model, the idle cores you speak about, would not be idle. While you're right that productivity versus performance is a trade-off, and an editor is not necessarily a high performance application, its not clear to me whether future optimizations would reduce the gap, as much as optimizing compilers did vis-a-vis C and assembly. In any case, that aside, the core guarantee of software stability with LSP remains to be seen.
• jahewson 9y ago
  One of the design goals for LSP is that it is not in-process. Process isolation gives the text editor stability in the face of unstable plugins and allows multiple language servers to run concurrently without requiring the target language (which could be anything) to support threads and a C ABI - something which many languages have no need for. Furthermore, many languages ship with a runtime which does not play nice with other runtimes. Try running a JVM, .NET VM, Golang runtime, and Erlang BEAM VM in the same process and see what happens. Better yet, try debugging it.
• ATsch 9y ago
  The best part is when I simulate bad network conditions by increasing latency and my autocompletion stops working (timeout 10ms) or becomes unusable.
  • zaphar 9y ago
    Why would you need to simulate bad network conditions over localhost? It's probably you're most stable network connection in any situation. You are simulating a condition that will almost never happen unless your machine itself is dying in which case you have bigger problems than auto-completion to worry about.
    • ATsch 9y ago
      You have a custom communication protocol over UDP and discover that with high latency, transferring large chunks takes a long time. You have a laptop available for testing. What do you do? Sure, could do some hyper complex setup with multiple VMs etc... or you could just run one command to temporarily increase latency on localhost. If you know some better way of doing this, feel free to tell me.
      • zaphar 9y ago
        Create a new loopback interface for testing? No reason you should be using your actual loopback for testing bad networking. Especially since the loopback interface is used for far more things than the one application you are testing these days. Setting up a new interface is pretty easy on most unix OS's and then you can increase the latency on just that interface without impacting the interface most software on your machine is built to expect to be blazing fast. And you can mess with that interface to your hearts content knowing the only thing affecting it is the applications you are running on it.
        • ATsch 9y ago
          That's a good idea actually, that didn't occur to me.