https://futureofcoding.org/ logo
Join Slack
Powered by
Hi :wave: I’m Jim Kring. I co-authored LabVIEW fo...
# introduce-yourself
j
Hi 👋 I’m Jim Kring. I co-authored LabVIEW for Everyone (back when people read books) and I’m working to self-host a visual programming language. I’ve been using LabVIEW for nearly 30 years, and a few years back I started exploring re-writing LabVIEW in LabVIEW. I’ve got a lot of interesting ideas in this space (many of them working) and am now starting to implement them in modern web technologies and with AI co-pilot capabilities. I’m also very interested in visual languages as a means for more efficiently interacting with AI (and parallel compute targets) as a means for having visibility into proposed actions by AI agents and enable human accountability for such systems to keep them safe. I’m looking forward to sharing ideas and successes. Kind Regards, Jim https://create.vi https://www.linkedin.com/in/jimkring
👋🏻 2
👋 17
👋🏼 1
d
Hi! Self-hosting is an awesome goal, it’s also something I’m hoping to get too. Where does self-hosting sit on your timeline of development? Is it a short term goal or desired eventuality? Curious how you think about it.
j
Self-hosting is not a gating item for what I want to do, so it seems to always takes a back seat, while I explore language design and tooling. As you know, it’s a chicken and egg problem.
I’ve taken a couple different paths: A) create a G interpreter in G (LabVIEW) B) create a G to Rust (or other text language) transpiler
😮 1
I have a pretty good JSON schema for the AST which makes working on runtime and compiler possible in any language.
I’m exploring svelte for a front end and even possibly using svelte as a compilation target (which then uses vite to compile to JS) since its reactivity and stores could serve as the basis for the dataflow execution. This lends to the possibility of creating a code editor in svelte for creating svelte components/apps, which could be the code editor.
Back to the discussion about paths to self-hosting: C) I built a python editor and runtime using trio for asynchronous task execution. I’ve sort of paused python for a runtime, until nogil (free, threaded python) mature in the next couple releases
it might be fun to try to self host using a more dynamic/interpreted runtime. Compilation of this visual language, which is inherently parallel, gets a bit tricky in terms of clumping and scheduling synchrolinear tasks (that’s a term which I believe I coined, which means the order of execution of nodes in a given subgraph does not change the timing of the subgraph as a whole) that get executed in an asynchronous runtime. I really want this language to include the concept of what type of compute fabric and asynchronous capabilities a given diagram supports, since this has a tremendous impact on compilation and execution strategy.
I worked on this privately as a hobby project during the pandemic. Now I’m gonna start opening it up and sharing more publicly.
I’ve bounced a lot of these ideas off of the creator of LabVIEW and others who used to work on the compiler team, and it seems like I’m on the right track
The other language rabbit-hole I got sidetracked on is whether to include passing AST (vs data) as a first class feature of the language (like elixir allows). There are some extremely powerful concepts that come out of the idea that AST (code) can travel down the wire. However, I do like how Zig simply separates the two using comptime, which means that the final executable output does not need to support passing AST, since it is only at compile time that this occurs.
Again, I think that using Svelte to start working on the visual aspects of the language (along with a JSON AST) will allow for rapid iteration of ideas and working concepts.
d
Really cool stuff. Seems like you’ve really thought about this a lot! It’s hard to make it a priority though it’s a sweet goal given the dogfooding benefits and perhaps a proof point of universality. I like the idea of targeting svelte as a starting point- basically close the loop leveraging the DOM/browser tech as a platform without trying to reinvent rendering at an MVP. And the point you made about that path sort of suggesting having the visual language support code I think is an interesting one. I’ve been thinking that the simplest version of a self-hosted visual language is effectively a code editor with access to its own source. And to get to a more visual code, imaging your code now lives and be modified in a canvas. Then imagine breaking apart code and leveraging more of your own languages data/control semantics. Perhaps in this way we can do things incrementally. Could make for an interesting experiment at worst.
j
@Dennis Hansen this approach definitely speeds up the iteration cycle, and it’s very obvious when the code is broken 🤣 somewhat analogous to “working on the car while it’s driving down the road”.
having code that can edit itself, will benefit a lot from having a mechanism to take a snapshot of the entire code base/system, so one can easily roll back
💯 2
d
Exactly haha. And maybe gets us at least driving down the road as soon as we can. Going to give it some more thought in context of my thing as well as the ideas you’ve presented here. A lot of good stuff, appreciate the insights
j
Yeah, these conversations will make for a fun road trip!
😂 2
💯 1
Open in Slack
PreviousNext
Powered by