Props to Apple for doing this too, I am looking forward towards the next stages for the LangServ v4 spec, not sure what more they could do to make it awesome, but I'm sure there's plenty that could happen in the future in this space.
Props to Apple for doing this too, I am looking forward towards the next stages for the LangServ v4 spec, not sure what more they could do to make it awesome, but I'm sure there's plenty that could happen in the future in this space.
But many things seem obvious in hindsight.
So overall the effort to create a protocol and then getting everybody to accept it was rather huge and the chances of success rather slim. It's great that MS finally decided to do it and the huge popularity of VScode (especially with younger coders) seems to have helped a lot.
That then transferred to TypeScript, which again influenced VS Code. OmniSharp was then externalizing it. In VS Code I think Erich Gamma took it over and put it into standardized a protocol.
Another good alternatives are "Compiling with Continuations" and "Lisp in Small Pieces".
The Tiger book, "Compiling with Continuations" and "Lisp in Small Pieces" are some of my favourite ones.
Then if you want to learn about language semantics validation, "Formal Syntax and Semantics of Programming Languages: A Laboratory Based Approach".
The best ideas seem obvious in hindsight. I've had the experience of reading some books that explain groundbreaking ideas so well that you feel "shit, that's obvious. I should have thought of that". I think Language Server protocol is similar.
I actually blame Stallman for that. He insisted that GCC should not dump any AST or provide embeddable functionality so that actors like Apple wouldn't be able to build nonfree software on top of it. However, that meant you also can't build any free tools on top of it, so everyone was forced to make their own ad-hoc C++ parsers and analysers. Once clang appeared there were much higher quality tools available. There's rtags that's a sort of proto-langserv implementation for C++ from before Langserv was a thing.
I suspect Stallman's decision was right at the time, but it did hold back free tools.
But then backends for iOS apps are part of Apples ecosystem, if peripherally, so I stand corrected.
Vapor, Perfect, and Kitura are no match for the offerings in Java, .NET, Go, OCaml, Haskell, Erlang.
I can imagine that having a swift backend for your swift mobile app would be a lot nicer to work with than converting back and forth from a bunch of stringly-typed JSON.
I only develop part-time, as my main job is financial in nature, but god, it is really hard to find good learning material for serverside without depending on XCode. In particular, learning the server frameworks is almost not worth it. By using one language, I can keep my productivity acceptable.
If anyone has any references, I'd be super thankful!
Off topic but I love this, definitely stealing it. Did you coin this?
https://blog.codinghorror.com/new-programming-jargon/
My other favorite from that list is "baklava code" -- code that has too many layers.
Dock is only partially written in Swift. A significant portion is still Objective-C.
It was during WWDC 2016, "What's New in Swift" session.
https://developer.apple.com/videos/play/wwdc2016/402/
From the transcript. More on the video.
"I want to talk about a particular case study, and that's the Dock. And the Dock is interesting for two reasons. The first reason is it's a lot more than people think. It's not just the bar at the bottom of your desktop. It's actually a large amount of the macOS Windows, you know, management experience. So things like Mission Control, LaunchPad, Spaces, this is all what we consider part of the Dock. The second reason why Dock is interesting is it's actually been a Swift adopter for two releases. It started adopting Swift in El Capitan. So we have two releases to look at and to compare in how it was using Swift. So a lot of changes happened to the Dock in Sierra. First, almost all of Mission Control was rewritten in Swift, and the accessibility engine was rewritten in Swift. Why did we do this? We just didn't rewrite code just for the sake of rewriting code. The code had kind of grown organically over time as features had been added and it was time to refactor it. But also some new functionality needed to be implemented, and so it was the appropriate time to make this, you know, to do this rewrite. Now, what does this look like at the project level? So to give you an idea, Dock is about 200,000 lines of code with tens of thousands of lines written in Swift. And between El Capitan and Sierra, the amount of Swift code in the project more than doubled. And this actually, because this is part of a rewrite, this replaced a significant amount of C and Objective-C code. And the effects here are somewhat non-linear, because there's some refactoring and some new features being added, but we saw there was about 15 percent less code to replace the existing C and Objective-C code in Swift, and this is with new features being added at the same time. And the net result is this project is actually slightly smaller in Sierra than it was in El Capitan. Now, there's a lot you can read into statistics. I think the most important thing here is the engineers working on the Dock love using Swift. They are not mandated to use it. They volunteered."
So one would expect that during the last two years, the amount of Swift code has only increased, specially with the tiny spot Objective-C now gets at WWDC.
Not new at all. They support AJAX in Safari. Macs use SMB for file sharing.
LSP is Swank for other kinds of languages, and is certainly welcome, but neither the idea nor successful implementations of that idea is new.
---
I used it years before LSP was announced.
Mind you, the current recommended file sharing protocol on macOS is SMB. (since Apple have deprecated AFP)
https://lists.samba.org/archive/samba-technical/2014-Septemb...
Yes, it did.
from https://github.com/clojure-emacs/cider-nrepl#editor-agnostic
> Projects like vim-fireplace and vim-replant are making use of cider-nrepl already.