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

21–30 of 83 posts

Re: Apple's investment into Clangd and refactoring tooling

#21

Post by kuschku »

JDevlieghere wrote: post #12
pjmlp wrote: post #6

Earlier quoted context omitted.

To be able use it from any editor that is able to understand LSP, instead of having everyone writing their own bindings to libclang, specially if the editors are written in type safe languages.

Yes, exactly this. If you have 3 different editors and 3 different languages, you potentially end up with 9 different implementation. LSP means that the same can be achieved by one implementation per language and one plugin per editor.

With LSP, you end up with one subpar implementation, and you need to duplicate all refactoring functionality for each language.

While with common IDE plugins, you have one implementation of the refactoring functionality, and each language plugin just exposes an AST.

So LSP actually leads to more duplicated code and worse editors.

VS Code will never be able to match the functionality of IDEA unless each language server reimplements all the functionality slightly differently. What a mess.

Re: Apple's investment into Clangd and refactoring tooling

#22

Post by pjmlp »

oblio wrote: post #14
CodeArtisan wrote: post #10

There is an article from 2010 titled "Emacs is dead" that is being reposted on HN from time to time. The author args that the greatness of Emacs is to rely on external, editor agnostic tools where text act as an universal interface/medium but that the practice is fading out, and thus the dead of Emacs. Now, ten years later, Apple announces this. Emacs, the undead? https://tkf.github.io/2013/06/04/Emacs-is-dead.html

I think you might be right, but the greater context is highly ironic. The company resurrecting the Emacs concepts is Microsoft. They're the ones that created OmniSharp, bringing the idea of language servers to the programming mainstream. They then created the Language Server Protocol for what now is Emacs's biggest long term rival in the flexible editor arena: Visual Studio Code. Visual Studio Code is for the moment…

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

Re: Apple's investment into Clangd and refactoring tooling

#23

Post by girvo »

kuschku wrote: post #21
JDevlieghere wrote: post #12

Earlier quoted context omitted.

Yes, exactly this. If you have 3 different editors and 3 different languages, you potentially end up with 9 different implementation. LSP means that the same can be achieved by one implementation per language and one plugin per editor.

With LSP, you end up with one subpar implementation, and you need to duplicate all refactoring functionality for each language. While with common IDE plugins, you have one implementation of the refactoring functionality, and each language plugin just exposes an AST. So LSP actually leads to more duplicated code and worse editors. VS Code will never be able to match the functionality of IDEA unless each language serve…

And no other editor can implement IDEA’s feature set except from scratch. What a mess.

Re: Apple's investment into Clangd and refactoring tooling

#24

Post by pjmlp »

kuschku wrote: post #21
JDevlieghere wrote: post #12

Earlier quoted context omitted.

Yes, exactly this. If you have 3 different editors and 3 different languages, you potentially end up with 9 different implementation. LSP means that the same can be achieved by one implementation per language and one plugin per editor.

With LSP, you end up with one subpar implementation, and you need to duplicate all refactoring functionality for each language. While with common IDE plugins, you have one implementation of the refactoring functionality, and each language plugin just exposes an AST. So LSP actually leads to more duplicated code and worse editors. VS Code will never be able to match the functionality of IDEA unless each language serve…

LSP supports refactorings via Code Action Request messages.

Re: Apple's investment into Clangd and refactoring tooling

#25

Post by CodeArtisan »

coldtea wrote: post #16
CodeArtisan wrote: post #10

There is an article from 2010 titled "Emacs is dead" that is being reposted on HN from time to time. The author args that the greatness of Emacs is to rely on external, editor agnostic tools where text act as an universal interface/medium but that the practice is fading out, and thus the dead of Emacs. Now, ten years later, Apple announces this. Emacs, the undead? https://tkf.github.io/2013/06/04/Emacs-is-dead.html

Seeing that this has nothing to do with tools where "text acts as an universal interface/medium", no. It still concerns "external, editor agnostic tools" -- but that wasn't dying out in 2010, and is not coming from the dead today.

JSON-RPC is text based

https://en.wikipedia.org/wiki/JSON-RPC

Re: Apple's investment into Clangd and refactoring tooling

#26

Post by pjmlp »

codetrotter wrote: post #11
pjmlp wrote: post #2

Looking forward to it. It is really nice to finally start having C++ environments close to the promise of Energize C++ and Visual Age C++ 4.

https://www.reddit.com/r/programming/comments/25r6pw/a_demo_... They mentioned incremental compilation in the first few seconds of the video. Didn’t watch the rest of the video yet. I’ve always wished for incremental compilation. Imagine incremental compilation that was so fine grained it would recompile only the functions you changed. Of course this makes full-program optimization impossible but I think most of us d…

While not perfect, Visual C++ makes it a nice experience.

https://blogs.msdn.microsoft.com/vcblog/2016/10/05/faster-c-...

https://msdn.microsoft.com/en-us/library/4khtbfyf.aspx

Re: Apple's investment into Clangd and refactoring tooling

#27

Post by terminalcommand »

oblio wrote: post #14
CodeArtisan wrote: post #10

There is an article from 2010 titled "Emacs is dead" that is being reposted on HN from time to time. The author args that the greatness of Emacs is to rely on external, editor agnostic tools where text act as an universal interface/medium but that the practice is fading out, and thus the dead of Emacs. Now, ten years later, Apple announces this. Emacs, the undead? https://tkf.github.io/2013/06/04/Emacs-is-dead.html

I think you might be right, but the greater context is highly ironic. The company resurrecting the Emacs concepts is Microsoft. They're the ones that created OmniSharp, bringing the idea of language servers to the programming mainstream. They then created the Language Server Protocol for what now is Emacs's biggest long term rival in the flexible editor arena: Visual Studio Code. Visual Studio Code is for the moment…

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 foundations, you need to consult the API docs etc.

With Emacs you can learn as you go and the editor itself guides you if you ever get stuck. You can read the source of any part of Emacs you like, change it on the fly, evaluate and try it (except for some core modules written in C). And I think that's the beauty of Emacs. Emacs is easy to tinker with.

Re: Apple's investment into Clangd and refactoring tooling

#28

Post by ninkendo »

raverbashing wrote: post #7

Could someone explain what's the difference between both approaches and what are the advantages of Clangd?

Moving language parsing/refactoring/etc into a separate daemon is a step towards unifying tooling around specific protocols for interacting with compilers. Microsoft's effort towards a single language server protocol is worth mentioning: https://github.com/Microsoft/language-server-protocol

I'd love to see a future when new languages/compilers can implement this protocol for their external compiling daemons and just get support in all the various text editors/IDEs automatically.

Re: Apple's investment into Clangd and refactoring tooling

#29

Post by coldtea »

CodeArtisan wrote: post #25
coldtea wrote: post #16

Earlier quoted context omitted.

Seeing that this has nothing to do with tools where "text acts as an universal interface/medium", no. It still concerns "external, editor agnostic tools" -- but that wasn't dying out in 2010, and is not coming from the dead today.

JSON-RPC is text based https://en.wikipedia.org/wiki/JSON-RPC

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

Re: Apple's investment into Clangd and refactoring tooling

#30

Post by yzmtf2008 »

saagarjha wrote: post #4

I'm glad to see that Apple is putting work into making their tooling better and easier to work with, but I'm still not clear on the benefits of this change. Would someone care to enlighten me? Currently, the benefits of libclang that I see are that I can easily drop it into a project without requiring a lot of dependencies, and I don't need to figure out how to get permission to run different processes and manage int…

LSP converts a M x N problem (M editors, N languages) into a M + N problem.
Post reply on HN