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

Code-GUI bidirectional editing via LSP

jamesbvaughan.com

Post reply on HN
Print view View original

61–70 of 71 posts

Re: Code-GUI bidirectional editing via LSP

#61

Post by jasonjmcghee »

phatskat wrote: post #52
jasonjmcghee wrote: post #8

Hey nice - this stuff is so much fun to me. I've worked a number of experiments like this too, especially related to live coding. Love seeing it in the wild. I built a small project where you can live-code Love2D. The running program updates in real time (no saving needed) and see all values update in real-time, via LSP. https://github.com/jasonjmcghee/livelove And also added the same kind of interactivity like a num…

I’ve been wanting to get into game programming and was looking at Love2D. I don’t know much Lua outside of what I’ve picked up with NeoVim configs. This looks like it could be a great way to get my feet wet - I don’t do well with math and physics programming, but I used to make things in Flash back in the day that were similar to the particles demo and being able to quickly change things and see the updates makes it…

Do it! It's a lot of fun.

Highly recommend adding code definitions https://github.com/LuaCATS/love2d

And getting the lua LSP.

It reminds me a lot of processing / p5js. So easy to get something fun up and running quickly.

Re: Code-GUI bidirectional editing via LSP

#62

Post by mk_stjames »

rao-v wrote: post #36
mk_stjames wrote: post #23

Earlier quoted context omitted.

It's really hard to explain if you don't know how CAD kernels produce final BREP shapes via their process trees, but, try give an example- something like "this is a 2mm fillet" requires a 'fillet solver' that is deeply ingrained in the kernel. It isn't something that would ever be portable, say, from Fusion360 to CATIA natively because those are completely different kernels with different ways of 'solving' the model…

This is helpful but surely we can save a consistent description of the process step and the input parameters alongside the final geometry in the same file format?

Yes, we could, but there are very few open source fully parametric couplings of kernels and the file format out there. FreeCAD (using OpenCASCADE as a kernel) is one of the few. And that is nothing close to the vastness of modern CAD+PLM systems in level of functionality.

There is a reason that systems like Dassault's CATIA are both ubiquitous in aerospace and automotive and closed source- it is literally the culmination of probably 3000+ person-years of programming, stemming from the 1970s. The same for many others... making them interoperable would mean making the entire chain of systems open source and there isn't a reason for them to do so.

For small projects though, building DSLs and graphical tools on top of OpenCASCADE (which is GNU LGPL version 2.1 licensed) is about the closest you could get right now, particularly, in my opinion, building something like a pseudo-gui+textural tool with the Python package Build123D.

Re: Code-GUI bidirectional editing via LSP

#63

Post by jesse__ »

dodomodo wrote: post #48
jesse__ wrote: post #40

It's concerning to me that the LSP idea is .. a thing. Casey Muratori observed years ago that it's just a way worse way of doing libraries. Like, you're introducing HTTP where there could just be a function call into a DLL/SO. What's the benefit there? Just make vim/emacs/$editor speak some native protocol and be done with it. Then you GUI is just welded directly into the running editor process.. right?? There's no s…

there are many practical benefits: 1. naturally async 2. each server and the editor itself can be written in its own language and runtime easily 3. servers can just crash or be killed because of oom errors and your editor won't be affected 4. in a lot of languages it is easier to write a server then to call/export c abi 5. the editor can run in a browser and connect to a remote server 6. you can have a remote central…

IMO, many of these are marginal or nonce gains for the huge cost of introducing a network call in the middle of your program.

1. There's nothing stopping you from shoving the library code onto a thread. For something like this request-response style usage pattern, that sounds extremely straight-forward, especially since the previous paradigm was probably an async server anyways. The calling code (from the editor) obviously already had to be support async calls, so no real change there.

2. If $LANGUAGE can be used to write a server, it should be able to build a DLL. I realize this is not practically true, but I also don't support the notion that we should be writing even light systems stuff like this in JS or python.

3. lol. You're telling me you're worried about a process eating 32GB of ram parsing text files ..? If some core part of my editing workflow is crashing or running out of memory, it's going to be a disruptive enough event that my editor might as well just crash. The program I'm working on uses a lot of memory, my editor better not.

4. I guess ..? Barely seems like that's worth mentioning because .. counterpoint, debugging networked, multi-process programs is massively harder than debugging a singular process.

5. Why would I want (other than extremely niche applications, shadertoy comes to mind) an editor to run in a browser? If I have a browser, I can run an editor that connects to a remote machine. Furthermore, the `library-over-http` approach of LSPs doesn't really buy you anything in this scenario that using a single process wouldn't.. you can just send all the symbol information to the browser.. it's just not that big.

6. Wut?

Re: Code-GUI bidirectional editing via LSP

#64

Post by jesse__ »

chamomeal wrote: post #42
jesse__ wrote: post #40

It's concerning to me that the LSP idea is .. a thing. Casey Muratori observed years ago that it's just a way worse way of doing libraries. Like, you're introducing HTTP where there could just be a function call into a DLL/SO. What's the benefit there? Just make vim/emacs/$editor speak some native protocol and be done with it. Then you GUI is just welded directly into the running editor process.. right?? There's no s…

I’ve definitely wondered about this. Like why does the language-understanding standard have to be a server specifically? Just cause it’s a good architecture to build around? I think I’ve heard that vscode has benefitted hugely from it starting out with a client-server architecture from the start, since it started as a browser based editor. Things like editing code directly on servers via ssh or in containers is easy…

> I’ve definitely wondered about this. Like why does the language-understanding standard have to be a server specifically?

I don't think it does. I think it's a bad architectural decision that web bros thought sounded cute.

> Things like editing code directly on servers via ssh or in containers

I mean, vim and emacs have supported editing over ssh for like .. longer than I've been alive probably.

> I think I’ve heard that vscode has benefitted hugely from [clinet-server architecture]

IMO VSCode is a giant steaming pile; I'm not sure what the huge benefits could have been. It's intolerably slow, uses an insane amount of system resources, and the debugger barely works most of the time.

Re: Code-GUI bidirectional editing via LSP

#65

Post by dodomodo »

jesse__ wrote: post #63
dodomodo wrote: post #48

Earlier quoted context omitted.

there are many practical benefits: 1. naturally async 2. each server and the editor itself can be written in its own language and runtime easily 3. servers can just crash or be killed because of oom errors and your editor won't be affected 4. in a lot of languages it is easier to write a server then to call/export c abi 5. the editor can run in a browser and connect to a remote server 6. you can have a remote central…

IMO, many of these are marginal or nonce gains for the huge cost of introducing a network call in the middle of your program. 1. There's nothing stopping you from shoving the library code onto a thread. For something like this request-response style usage pattern, that sounds extremely straight-forward, especially since the previous paradigm was probably an async server anyways. The calling code (from the editor) obv…

1. True, but in practice it's not always the case, for example older versions of resharper sometimes slowed down typing speed. It's much harder to fuck it up when there is a network request in the middle.

2. What about languages like Java and Go?

3. a. The experience of lsp server crashing is much better than an editor crashing, the editor usually automatically restart it. I had lsp servers crash without me noticing at all.

b. Memory problems in both lsp servers and traditional IDE analysis are extremely common in my experience. It seem to me that the problem is that there are a lot of pathological cases where the analysis enters a loop and keeps allocating memory.

4. When mixing runtimes I actually find it easier to have multiple processes because I can attach a specialized debugger to each process but this is definitely an important point.

5. good counter argument, I retract my point

6. what I meant is that for very large code bases it can be beneficial to run a central lsp server that many people can connect to because most of the index is shared between all of them and the parsing+indexing itself is very costly. I heard Google were doing something like that but I don't have more information.

Re: Code-GUI bidirectional editing via LSP

#66

Post by jesse__ »

dodomodo wrote: post #65
jesse__ wrote: post #63

Earlier quoted context omitted.

IMO, many of these are marginal or nonce gains for the huge cost of introducing a network call in the middle of your program. 1. There's nothing stopping you from shoving the library code onto a thread. For something like this request-response style usage pattern, that sounds extremely straight-forward, especially since the previous paradigm was probably an async server anyways. The calling code (from the editor) obv…

1. True, but in practice it's not always the case, for example older versions of resharper sometimes slowed down typing speed. It's much harder to fuck it up when there is a network request in the middle. 2. What about languages like Java and Go? 3. a. The experience of lsp server crashing is much better than an editor crashing, the editor usually automatically restart it. I had lsp servers crash without me noticing…

1. Choosing a shitty architecture to absorb the downside of low quality tools seems like a bad decision, but I guess that's just where the industry's at right now.

2. AFAIK Go can both compile and load DLLs now. A language that doesn't have native compilation facilities (Java, JS, python, etc) would have to have extra tooling that loads the runtime and program from a DLL. A quick google search tells me Java has this tooling already. I'm sure other languages would too.

3 a,b. See point 1.

4. Yeah, that's fair, although I'd probably still rather have a single process.

6. Also a good point. Might be a useful paradigm for large codebases. Although at that point the usage pattern is so different that the calculus for choosing the architecture is different, and I stand by my choice. Google can afford to build fancy shit for themselves.

Re: Code-GUI bidirectional editing via LSP

#67

Post by dodomodo »

jesse__ wrote: post #66
dodomodo wrote: post #65

Earlier quoted context omitted.

1. True, but in practice it's not always the case, for example older versions of resharper sometimes slowed down typing speed. It's much harder to fuck it up when there is a network request in the middle. 2. What about languages like Java and Go? 3. a. The experience of lsp server crashing is much better than an editor crashing, the editor usually automatically restart it. I had lsp servers crash without me noticing…

1. Choosing a shitty architecture to absorb the downside of low quality tools seems like a bad decision, but I guess that's just where the industry's at right now. 2. AFAIK Go can both compile and load DLLs now. A language that doesn't have native compilation facilities (Java, JS, python, etc) would have to have extra tooling that loads the runtime and program from a DLL. A quick google search tells me Java has this…

first of all I want to say that I have a lot fun talking to you! Honestly I would also prefer dll based approach, if you really want to see the limits of the architecture of Lsp I recommend you to read the discussion about adding syntax highlighting to the protocol, but I see why the people behind LSP did what they did.

One final point!

I think there is a difference between absorbing low quality tools and absorbing low quality code. I think that it makes a lot of sense for a plugin system to design for low quality plugins. I have two examples from my job, the first is a micro services based parsing infrastructure, where each team is responsible with parsing it's own formats, which are oftentimes layered apon formats parsed by different teams. I believe this takes about 10x-100x more resources than it should, but it has the benefit that a rouge parser can't takes everything down with it. The second example is internal scripting capability of a different system where a lot of work was done to make sure the script can't do anything stupid.

In both of those cases the system is designed for low quality code because it is more cost effective to make sure code can be low quality without affecting the overall system, than to make sure low quality code doesn't exists.

Re: Code-GUI bidirectional editing via LSP

#68

Post by sitkack »

It is referenced down in the wonderful tree of knowledge, but I thought I would lift this info up to the top level. A system like this called a "bimodal editor" from the work of Ravi Chugh [1] see the project Sketch-n-Sketch [2] these kinds of systems got a big kick in the pants with Bret Victor's talk Inventing On Principle [3]. That in turn kicked off a wonderful dynamic execution Clojure IDE called lighttable [4]

There are tons of other great research projects and researchers in this fascinating space. Comment is not meant to exclude.

[1] https://people.cs.uchicago.edu/%7Erchugh/

[2] https://ravichugh.github.io/sketch-n-sketch/

[3] https://vimeo.com/906418692

[4] https://web.archive.org/web/20250616031034/http://lighttable... (demo video plays)

Re: Code-GUI bidirectional editing via LSP

#69

Post by LarMachinarum »

i wonder: could this kind of bidirectional flow be used to turn any LSP-capable editor (without it having to have any collaborative editing function integrated) into a collaborative editor that real-time-syncs any modification by any connected user with all other users who have the modified file open?

Re: Code-GUI bidirectional editing via LSP

#70

Post by krebby »

adastra22 wrote: post #46
krebby wrote: post #39

Earlier quoted context omitted.

How about a visual programming language? Plenty of 3D and CAD software uses a VPL for procedural design, which helps a ton to bring out the benefits of both

Any examples?

Grasshopper for Rhino is a big one, or VisualCAD/CAM. Blender, Houdini, or Unreal Blueprints are others. It gives you the exploration benefits of a UI plus the procedural benefits of code. Inputs tend to be auto-bound which makes exploration much, much faster.

I'm working on one for web map data visualization: https://youtu.be/GJ0ftFB8r4I?t=871

Post reply on HN