Hacker News Reader

Comment by tov_objorkin | Hacker News Reader

I was greatly inspired by his work. After getting enough skills, I even built my own IDE with live coding and time traveling. Its practical use is questionable, and it seems like nobody is really interested in such tools.

Playground: https://anykey111.github.io

Images: https://github.com/anykey111/xehw

View on HN

I've dabbled a lot in this space as well- built an experimental language that natively supported live-coding, after building live coding capabilities through LSP for love2d (Lua) to get a feel for the feature set I wanted etc

Love2D Demo https://github.com/jasonjmcghee/livelove

Language Demo https://gist.github.com/jasonjmcghee/09b274bf2211845c551d435...

Nice, the main problem is a broken state. I use immutability at the language level to prevent disaster code changes. So, the program during live coding is literally unkillable, and you can jump back to the saved checkpoints without restarts.

Yeah the language here has a notion of the "last good state" so it can keep running. In the demo I'm not hitting "save" - the moment there's a good state, it becomes the "current version" - but there's no reason it needs to be that way.

I made the decision that state management is manual - the "once" keyword. Any expression/block not using "once" is re-evaluated any time there's a change to the code. If it's using it, it only re-evaluates if you change the (depth 0) code of that once wrapped expression.

In my case, only part of the program is recompiled and re-evaluated. The rest is located in a "committed" frozen area. Users can try new changes and throw them freely. The editor performs an evaluation/rollback on every keystroke, ensuring no accumulated or unintended changes to the stated were made during editing. When the user is satisfied and hit run, a long-term snapshot is created and the source code snippet is moving to the frozen area. Thats critical because the edit also rollback the file positions and streams.

Me too, for my master thesis:

https://m.youtube.com/watch?v=HnZipJOan54&t=1249s

It was a language designed alongside its IDE (which was a fairly rudimentary web app).

Exciting stuff, thanks for sharing!

I've come around to feeling that if I'm going to make an experimental development tool, I need to make it in service of building something specific. Maybe something playful... if I'm building something "important" then it can put unwanted conservative pressure on the tool. But something, and if I do that then at least I have something interesting regardless of the fate of the development tool. Because yeah, there's a good chance no one else is going to be excited about the tool, so I have to build for my own sense of excitement, be my own most enthusiastic user.

Maybe this is some kind of art that doesn't need to be useful.

I share a similar sentiment.

I have a deep drive to build the "important" stuff so that my life has meaning, but there's something hard to motivate about any given thing being "important" when you look at it long enough. It seems like the "important" thing I'm building eventually looks ridiculous and I bounce off of it.

I think your time might be now.

One major issue with vibe coding is parsing divergent code paths, when different prompts create different solutions and architectural compromises.

Parsing that mess is a major headache, but with live coding and time travel,I bet those tools would make managing divergent code branches easier and really take advantage of branching repositories with multiple agents all working in tandem.

This is excellent: thank you for pursuing these wonderful ideas.

I wish to have the skills to explain my work as well as Bret Victor does. Editing, reverting, and committing parts of a running program feel alien to users.

Isn't that part of Paul Graham's startup lore? They were running lisp web servers for their ecommerce store and while a customer was on the phone with an issue, they would patch the server live and ask the customer to reload. Customers would hang up convinced it was their personal glitch.

The tool uses a Forth-like language with immutable data structures and persistent memory snapshots. It also uses Clojure style meta-data and compile-time meta-programming. I have no luck convincing people that a language without curly brackets is useful.

There was recently an HN post with a video of someone using a pretty cool environment that supported that kind of live-coding for creating an electronic music track -- it seemed very appropriate there, and I would guess likely to be popular.

Reply on news.ycombinator.com