Comment by mishoo | Hacker News Reader

Comment by mishoo | Hacker News Reader

Parent Full thread

You won't get what true "liveness" is until you work in Lisp or Smalltalk. The ability to change a function in a running program, without restarting it. Automatic reload might seem cool, but reload means your application restarts and loses state. Imagine you have some Web app and you open some menus/dialogs, perhaps it's connected to some server via WebSockets etc. and you find a bug somewhere, you go to the code to fix it, but reloading the page means you start from scratch and need to open again those menus/dialogs, and reconnect the sockets, in order to test your fix.

Common Lisp had true liveness for decades; it's almost mandated by the standard, it's designed in such a way that you can actually recompile a function, or even redefine objects, adding or removing properties or methods, at fucking runtime without restarting the application. Objects already instantiated will remain so and will be updated to reflect the change. You don't restart. That's the true "liveness", but seriously you don't get it until you try it, and once you get it you become depressed because you realize it doesn't really exist in any mainstream language.

JavaScript is some decades behind this dream, even with stuff like Webpack.

> You won't get what true "liveness" is until you work in Lisp or Smalltalk. The ability to change a function in a running program, without restarting it

This can be done in a number of other common languages today such as Java (JVM languages) and C# (probably all .NET languages). Most IDEs I've seen for those platforms support it.

Substantial enough changes to the code can require an application restart, but most changes you might make like changing the implementation of a function, adding new functions to a class, etc., will not. Hot Code Replacement (HCR) has been supported since Java 1.4: https://wiki.eclipse.org/FAQ_What_is_hot_code_replace%3F

Fully dynamic languages like Lisp and Smalltalk permit a greater degree of this than statically typed languages do, however, since they don't have types and a type system to wrangle with. When I've used it, hot code replacement supported most of the changes that conceptually make sense to support.

You'd be surprised to find out that Common Lisp has actually quite a strong type system (not Haskell-level but much better than C++/Java); just that it's optional. You get the best of both worlds — fast prototyping, and then when you decide upon the types, you can add type declarations, which usually result in (much!) faster code and robustness.

If you use webpack's hot reloading properly with something like React, then you get to keep your state - it's only the functions that get swapped out. So it's actually exactly what you describe, and it's brilliant - so much more productive. This isn't even all that new (in web dev terms) - I had this working probably four or five years ago now on a project.

Huh?

I do procedural music in JS/web audio, and my projects are set up so that changes to the logic and instruments all happen live, while the music continues to play.

How is that different from what you're describing? What specifically can't webpack/HMR do?

What tools do you use? Just web audio api? Or a higher level library?

I first started out using Tone.js (and recommend it!), but later wound up rolling my own engine and so forth. So I'm just using WebAudio directly (or via libraries I wrote).

It’s relatively simple to have live reloading of individual JavaScript modules in Webpack. If you change the text on a React button component, that module will be recompiled and its new version injected into your browser and re-rendered. The text on the button in your browser will change, but other state will not change (e.g. something in your Redux store).

I’m not an expert, but I think the way it works is that Webpack provides a way for JS modules to register callbacks for what should happen when Webpack detects changes in them and recompiles them. React then provides such a callback implementation for component modules that causes the individual component to re-render. Webpack’s development server also provides a way to inject new code into your app running in a browser.

Things get a little more complicated if you want to hot reload things that deal intimately with state, like Redux reducers or middleware. AFAIK people usually just have the browser do a full page reload when changes are detected in those modules. I think Webpack will actually automatically trigger a full page reload if it detects a change in a module which does not explicitly declare how hot module reloading should be handled.

I only mention React and Redux because it’s the only major stack I’m at all familiar with; I don’t know if other stacks provide similar functionality.

FWIW hot reloading React/Vue components come quite close to this.

So does ClojureScript and Figwheel.

> You won't get what true "liveness" is until you work in Lisp or Smalltalk. The ability to change a function in a running program, without restarting it.

Erlang provides this as well, as do many dynamic languages. However, aside from certain Lisps and Smalltalk that are image based, and a few others, liveness and source persistence are typically traded off for each other. I can make a live change to a Ruby system if it is set up to provide a REPL, but unlike a live Smalltalk change I won't then have the source code for the changed but available the same way it is for the rest of the system. As a result, in many languages live coding features are mostly a tool for experimentation (usually in nonproduction environment!) on code that will eventually be incorporated into traditional source tree for a from-scratch build.

- IBM's visual age for java provided most of this for Java too. (yes, it was modeled to the smalltalk env with the same name)

- Zope (python app server) had a feature where you could debug a web application (in production) in a private session, so all code modifications you did in your session were private until you committed the code.

- Jrebel is a commercial tool that also lets you replace bytecode in a running program without loss of state.

"Hot code replacement" is a Java VM feature. What makes JRebel useful is support for live reconfiguration of a gazillion Java frameworks (e.g. Hibernate, CDI, Spring etc) so you don't have to restart your server after changing some configuration annotations. It's expensive though and slows down startup so it's a tradeoff.

Reply on news.ycombinator.com