Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple's investment into Clangd and refactoring tooling

lists.llvm.org

Post reply on HN
Print view View original

71–80 of 83 posts

Re: Apple's investment into Clangd and refactoring tooling

#71

Post by pjmlp »

oblio wrote: post #57
pjmlp wrote: post #22

Earlier quoted context omitted.

Here is how Lucid implemented their C++ knowledge repository for Energize C++. "Foundation for a C++ Programming Environment", chapter 7, Protocols https://pdfs.semanticscholar.org/84a4/8824fc7dd872414efa0ad6... And how it looked like with their Emacs customization in 1993 on UNIX. https://www.youtube.com/watch?v=pQQTScuApWk

Lucid went bankrupt as far as I remember :)

And that proves what?

Sadly the best ideas aren't always the ones that get widespread adoption.

Here we are now, about 30 years later still trying to get major C++ environments to offer some of those ideas.

Re: Apple's investment into Clangd and refactoring tooling

#72

Post by oblio »

pjmlp wrote: post #71
oblio wrote: post #57

Earlier quoted context omitted.

Lucid went bankrupt as far as I remember :)

And that proves what? Sadly the best ideas aren't always the ones that get widespread adoption. Here we are now, about 30 years later still trying to get major C++ environments to offer some of those ideas.

It proves nothing, it's just about my original comment about Microsoft:

> bringing the idea of language servers to the programming mainstream

Lucid failed to do this, Microsoft succeeded.

Re: Apple's investment into Clangd and refactoring tooling

#73

Post by luikore »

DannyBee wrote: post #48
oflannabhra wrote: post #45

Earlier quoted context omitted.

The proposal is to split the LSP implementation into a transport layer and a logical layer. The current LSP implementation is directly tied to JSON-RPC. Apple's end goal is, as you say, to get clangd to work with Xcode. However, having a replaceable transport layer for LSP could benefit lots of people other than Apple.

Sure, it's nice, but again, being pragmatic, nobody else has desired such a thing that much. Ie so far the "lots of people" have not materialized, even outside clangd. I can certainly think of use cases for such a thing, but most people seem happy enough with json-rpc at the moment. Part of that is likely that trying to speak LSP over a non local connection may be a fools errand anyway. It's a chatty protocol no matt…

Really? I desire a protocol which is not coupled with JSON-RPC.

Re: Apple's investment into Clangd and refactoring tooling

#74

Post by jupp0r »

I have mixed feelings about this.

On one hand it's really nice to see Apple jump on the LSP train and use standard tooling for their IDE to interact with language tools.

On the other hand, instead of having a consistent strategy of using proper LSP (which by specification is JSONRPC), they are shoehorning LSP on top of their in-house XPC transport. To do that they're planning to introduce additional complexity to clangd (a transport abstraction), while actually defeating one of the main purposes of LSP, which is reducing the m-times-n complexity problem of matching compilers with tools to an m-plus-n complexity problem. No other tools (unless they support LSP-over-XPC as well) will be able to talk to XCode. XCode won't be able to talk to other tools. I hope they rethink that decision, keep clangd simple and instead adopt proper (JSONRPC) LSP in all of their other tools for Swift, etc instead. That way they'd not only open up XCode to clangd, but also all other editors to their refactoring tools for Swift, etc.

Re: Apple's investment into Clangd and refactoring tooling

#75

Post by fourthark »

oblio wrote: post #47
terminalcommand wrote: post #27

Earlier quoted context omitted.

I think Emacs's greatest strength comes from the ability to use a single scripting language throughout the whole editor. I can quickly write up some ELISP statement to do anything, if I like it I can put it in a file and load it. If I want to share it, I put it in an extension. I've just looked up the official tutorial on making an extension in VS Code. It seemed cumbersome. You need a code generator to lay the found…

Yeah, but I have a million monkeys^Wdevelopers at my back for Javascript/Typescript. How many divisions does Lisp have?

Out of curiosity I looked it up. It's a factor of 200: 3788 packages on MELPA, vs 650000 packages on NPM.

Re: Apple's investment into Clangd and refactoring tooling

#76

Post by tbodt »

falanjito wrote: post #44
DannyBee wrote: post #40

So, just because there seems to be confusion: Clangd already exists. It already supports LSP. It is already part of the llvm project. It was written by !Apple, and used by a wide number of people. (I want to make sure these people still get credit, i already see people in this thread thanking apple for supporting LSP, which is not actually what happened). What apple has proposed contributing is: Making clangd work wi…

Would it make sense to rewrite everything in Python to gain some speed?

No.

Re: Apple's investment into Clangd and refactoring tooling

#77

Post by pjmlp »

oblio wrote: post #72
pjmlp wrote: post #71

Earlier quoted context omitted.

And that proves what? Sadly the best ideas aren't always the ones that get widespread adoption. Here we are now, about 30 years later still trying to get major C++ environments to offer some of those ideas.

It proves nothing, it's just about my original comment about Microsoft: > bringing the idea of language servers to the programming mainstream Lucid failed to do this, Microsoft succeeded.

The simplicity of you statement ignores what it meant to get a computer running Energize C++ properly in 1993 and an Electron (VSCode) app in 2017.

Specially the money part.

Re: Apple's investment into Clangd and refactoring tooling

#78

Post by r4nt3r »

DannyBee wrote: post #56
k4st wrote: post #54

Earlier quoted context omitted.

The [follow up]( http://lists.llvm.org/pipermail/cfe-dev/2018-April/057672.ht... ) message suggests that Google already internally using a non-JSPN-RPC transport layer.

Yeah, but that is likely to actually go away, not happen more. It's not a desired thing in that case, it was just easiest at the time for various reasons. We didn't want the public project to have to support our special snowflakism, hence it was done a different way.

clangd already has a layered architecture, where you can either use the JSON-RPC mechanism or more directly control clangd and implement your own transport. There are no plans for this to go away, as generally large companies often have environments in which they want better control of features than a standard protocol like LSP can give you, and we don't discourage that.

We also just talked with Apple folks at Euro LLVM about this, and while the plan for the near future is for them to have a transport conversion to JSON-RPC, I expect them to want the more fine grained control in the long term.

Re: Apple's investment into Clangd and refactoring tooling

#79

Post by r4nt3r »

DannyBee wrote: post #51
oflannabhra wrote: post #50

Earlier quoted context omitted.

Just because Apple is the first doesn't mean there won't be others. Maybe others have not materialized because the upfront cost of updating clangd was judged too high. JSON-RPC has several alternatives that very large software companies have vested interests in: gRPC and XPC. You seem more knowledgeable of these technologies than I am, though. It just seems to me a good thing that 1) Apple, and consequently, all iOS…

My point was precisely that plenty of languages have LSP implementations at this point, an f even in those, nobody has cared much to try to find an alternative to json rpc. As for 2, all I'll say is based on history in llvm projects, I'm not anywhere near as optimistic as you. The history here is simply not one of all great things. The PR is, but the reality is much more mixed (some really great things, some really n…

While I agree that not everything is always great, I'd say the same for our own contributions ;) I've definitely let patches unreviewed for way too long due to internal priorities, and have gotten my share of shit at conferences for that...

In this case, the collaboration with Apple and Ericsson on the underlying architecture has been going on for a while, and while not everybody always agrees on priorities and design details, I'm thrilled to see Apple double down on their involvement here!

Re: Apple's investment into Clangd and refactoring tooling

#80

Post by coldtea »

CodeArtisan wrote: post #43
coldtea wrote: post #29

Earlier quoted context omitted.

It's a parsable format. Not some arbitrary stream of text, like what UNIX streams deal with...

What do you mean by "arbitrary stream of text"? I fail to understand, to be honest. A text always need to be parsed, even a simple number, but the point is to deal with characters instead of raw binary data.

>What do you mean by "arbitrary stream of text"? I fail to understand, to be honest

That it's structured and specific.

UNIX pipes, for example, can deal with any kind of text -- it's up to the user to ensure that the commands (e.g. "cut -d," etc) work ok with them, whereas the JSON RPC communications of the language server are not only in a specific syntax (JSON), but they also have predetermined content schema.

Post reply on HN