I've recently started adding support for the Language Server Protocol (LSP) in a language project I'm working on, and it's a godsend. If you're not familiar with it, it's basically an editor- and language-agnostic protocol for implementing typical IDE behaviours like error highlighting, code completion, hover information, find references, etc. It solves the M*N problem in which every language would have to have a separate plugin tailored towards the APIs of every editor; now you just write either to be LSP compliant and it takes care of 90% of integration effort (writing the language server itself of course is still a lot of work).
Although it's still necessary to do a little plumbing work to integrate into each editor, this is largely boilerplate that differs little between languages. Most of the functionality resides in a JSON-RPC server implemented in your language of choice.
I've found it particularly useful when used in conjunction with the Monaco code editor [1] (the engine that powers Visual Studio Code), along with a supporting plugin for talking to a remote LSP server [2]. These make it possible to build interactive coding environments into a web app which include many of the typical editing features you're used to in IDEs.
It's great to see Apple along with other language vendors adopting this as a standard.
I think it's a positive, but I also question what the point is.
What I'd like, is a better IDE, not an IDE that can provide features I've had for 30 years, for 30 different languages, in a consistent manner.
I dont' want 30 languages, and 1 basic lowest common denominator ide. I want 2-3 languages, and excellent ides that push the boundaries of the unique features of each language.
It's not like those sorts of IDEs don't exist. Swift and ObjC have Xcode, C# has VS, Java has IntelliJ, etc.
> What I'd like [...] not an IDE that can provide features [...] in a consistent manner
How is providing consistent support for many languages a bad thing? This I don't understand. People love their tools, for better or worse, so why should being forced to change tools be the only workflow?
Your beloved one-IDE-for-a-couple-of-languages already exist and have done for years, so no need to be a Grinch.
> excellent ides that push the boundaries of the unique features of each language
> Swift and ObjC have Xcode
Hard disagree that Xcode falls under the category of "excellent". Is this parameter a concrete type, or a protocol? Sure would be nice if they were color coded... that's pretty low-hanging fruit.
But that's looking at the trees. The important point is that the forest is rubbish. It is 2018 and our developer experience is still fundamentally oriented around the idea of _individual text files_. This has been the fundamental unit of organization for 50 years.
A typical developer task might require examining 7 or maybe 12 small pieces of code, all of which are in different files. If this were in the physical realm, you'd grab these pieces and plop them on your desk, arrange them this way or that, think about them for a while, play with a few ideas for possible changes, settle on one, and then start implementing the changes.
About the only affordance which Xcode offers to facilitate this sort of work is command+click to jump to a definition.
I literally resort to _taking screenshots of code snippets_ and arrange them in diagramming software in order to think through a problem. Why is my IDE not facilitating this sort of work?
Edit: though if we are stuck on text-file-oriented program organization for the time being, there's still a lot which can be done to improve upon that, e.g. https://youtu.be/0Vq2rcjWbTc?t=1429
All this "code portal" features of Inline should be found in any modern code editor! But nobody implemented them in any of the usual IDEs until now to my knowledge. That's a real pity.
Nice to see someone noticed this one. The ideas are indeed great, so spread the word. Really want to see this features in every code editor in the future.
Very excited to see this. We will use this project to add Swift support to Sourcegraph soon so you can get hovers, go-to-definition, find-references, etc., when browsing code on GitHub/GitLab/Bitbucket/Phabricator/Sourcegraph/etc.
LSP seems like an interesting concept, but it would be nice if it included more support for REPLs. I'm thinking of things like "evaluate highlighted section" or "recompile function under cursor".
> SourceKit-LSP is built on top of sourcekitd 23 and clangd 23 for high-fidelity language support, and provides a powerful source code index as well as cross-language support.
That's pretty much been Apple's motto for a while: need language support for anything other than compiling the language, like IDEs or documentation generation? Why not add it directly into the compiler? This has pros and cons, but personally I like the direction Microsoft has gone: rewrite everything in JavaScript (actually TypeScript) so that it's super portable and more easily embeddable.
> I like the direction Microsoft has gone: rewrite everything in JavaScript (actually TypeScript) so that it's super portable and more easily embeddable.
That is not at all what Microsoft has done. C# LSP support is driven by their C# Roslyn compiler. Are you confusing this with their VS Code editor? LSP solves a completely different problem: MN (editorslanguages) by providing a glue layer that compilers and editors can plug into.
The whole point of these things is to keep a single source of truth; why would you (poorly) reinvent a compiler for Swift when you can just use the actual Swift compiler?
It's simple code reuse... you know that compilers are made of many modules and have stages right? Why reinvent writing a code -> lexer-> ast parser for your indexer when you already have a well tested and fast one in llvm?
Did you know for example, that when you build your app in xcode that it uses that partial build product to also feed the indexer, so you don't have to scan the same code twice?
Seems Apple as a company is not totally hijacked by Javascript people. I am happy that Apple took some stand against Java/Flash/Javascript when it interfered with quality of user experience.
afaict, most, if not everything, that the LSP is expected to put out is information that is already known to the compiler, as its required for compilation and error'ing. The LSP is just a standardized way to extract that information from the compiler, instead of re-implementing the work in the IDE.
Although it's still necessary to do a little plumbing work to integrate into each editor, this is largely boilerplate that differs little between languages. Most of the functionality resides in a JSON-RPC server implemented in your language of choice.
I've found it particularly useful when used in conjunction with the Monaco code editor [1] (the engine that powers Visual Studio Code), along with a supporting plugin for talking to a remote LSP server [2]. These make it possible to build interactive coding environments into a web app which include many of the typical editing features you're used to in IDEs.
It's great to see Apple along with other language vendors adopting this as a standard.
[1] https://github.com/Microsoft/monaco-editor
[2] https://github.com/TypeFox/monaco-languageclient