Hacker News Reader

Comment by spc476 | Hacker News Reader

How would that work in real life? It sounds nice in theory, but as the saying goes, "in theory, there is no difference, in practice, there is."

One programmer fixing a bug, one adding a new feature, are both working on the same program at the same time? Or is each one working on their own copy? And how does the merge happen if they're working on separate copies? How is the updated code moved to production? How is this "live coding" supposed to work?

View on HN

As I understand it:

* There's still a notion of production. Most people work on dev environments just like today. You do need the ability to merge code in some reliable form from one environment to another. The Clerk project mentioned in the talk does this.

* Dev environments are more fluid. You can debug issues faster because you spend less time getting to arcane parts of your program after every restart.

* It is possible to live-edit production for important incidents. It's very much a weapon of last resort, you have to be super careful, and you probably want to rehearse in staging the way NASA does with their rovers. But it has the promise to reduce the amount of time your customers are impacted in major incidents.

This talk inspired me to go build a live programming environment in my current stack of choice: https://spectra.video/w/wkDB5fsjBNBbsqKXGhGzwT

> It sounds nice in theory, but as the saying goes

Listen to Ron Garret’s interview on Corecursive.[1] He sent verified Lisp code to Mars at NASA. The code failed but the debugger popped up and they were able to recover from it. Look for “Debugging Code in Space” and “Sending S-Expressions” in the time stamps.

[1] https://corecursive.com/lisp-in-space-with-ron-garret/

Here's another account of the same story: https://flownet.com/gat/jpl-lisp.html

Ron Garret (https://news.ycombinator.com/user?id=lisper) is a frequent contributor on HN.

I'm not sure mainstream development practices would automatically benefit from mimicking the ones used for such an extreme scenario

You're right, possibly not, but it has its place.

By using source code and version control. It's not magic, check out Pharo + Iceberg (their integration with git). You still end up with a live environment for much of your work, but in a way that still works well for collaboration. Just don't be foolish and think, "Oh, I can redefine this live and never commit it anywhere and that'll be fine." That's not very smart, and you don't want people to think you're an idiot, so don't do it.

> That's not very smart, and you don't want people to think you're an idiot, so don't do it.

Yeah, that works about as well as saying you don't need tests because it's not very smart to write bugs. You need processes to enforce these things at scale.

I mean, was it that hard to get your team to adopt git or another version control system? I've only had one team that struggled with that, and they struggled with a lot of things. Everyone else adapted quickly to it. Working in Smalltalk would be no different in that regard. It's just as easy and just as hard as working with git in C# or another language. Someone forgets to check in a new source file, everyone else has a broken build. It's obvious quickly and gets addressed.

A la Emacs, I'd say. Emacs is basically a live environment where you can edit text. While you're running it, you can add new features on the go, then save the modifications once you're happy with them. Imagine if you open apple notes and wanted to change a few things, maybe adding an interface to some services. You'd just open the live environment, code your changes, and voilà.

On your development environment mostly.

Smalltalk, Lisp, Scheme, Erlang, Haskell, OCaml, Java, .NET, C++ (via VS, Live++, Unreal) allow for this kind of interactivity, where Smalltalk and Lisp variants win in tooling.

Some Lisp variants, Erlang, Java (via JMX beans / JVMTI) also allow to connect to a running application in production and change its behaviour, although on Java's case it is only a subset of possible changes.

The sound in this video is pretty bad, but several years ago I did a talk showing how this development style work on a real project, and I think it may answer some of these questions. https://www.youtube.com/watch?v=bl8jQ2wRh6k

Try irc ( interactive ruby console ) with a running ruby on rails server to get a feeling for what magic is possible

Reply on news.ycombinator.com