Hacker News Reader

Comment by _pmf_ | Hacker News Reader

It's a bit ridiculous[1] that one has to jump through hoops with Clojure to get the benefits that Java hotswapping provides out-of-the-box (i.e. changing a method and transparently recompiling and changing to the new implementation in the running JVM) with even second rate IDEs like Eclipse (which I am using). Note that this is without any third-party plugins and Oracle's standard VM.

[1] And by "a bit ridiculous", I mean completely archaic.

View on HN

Clojure has excellent support for hot swapping functions and data; which in my experience is far ahead of anything that Java has. The system introduced in this article is for reloading code but with a consistent state.

For example, if your application includes some state from previous actions. Then you change a function that acts on that state, but with a different protocol (e.g. data structure expectations changed in the function). Then your application would not work, as the old state is invalid for the new function. With techniques like explained in the article, you can quickly "reboot" your state to be consistent with your new code by reseeding your system.

This is equivalent to restarting the JVM along with your application but only quicker?

I really don't see a good pain/gain ratio here. Clojure being a lisp you are already good for reloading functions. Only if you change data structures or macros you need to reboot. That I would think is a much less frequent operation for which a JVM restart is acceptable. (You also know that absolutely everything got reset.)

Note it's not just restarting the JVM, it's also restarting your repl as well, which can be as big a PITA as restarting your JVM.

If restarting your JVM is ok with you, go for it! But I like what Stuart has presented and find it interesting, I'm all about minimizing interruptions while I'm working on something and will be trying to adapt his workflow to mine.

Try JRebel.

JRebel seems a big improvement over normal JVM hot swapping, but it still doesn't seem to be quite as comprehensive as the capabilities a dynamic language like Clojure offers.

I've used hot code replacement with Eclipse since 2004, but you had to jump through hoops to get it back than, and you could not do anything other than code inside methods (no changes to a class public or private interface). No idea if that has changed, but I still think this won't help if you suddenly decide to change your class hierarchy, or initialization files.

His workflow goes much deeper than just changing the code. The entire application state is abstracted away and you can reload the entire application state in under a second.

Think a little about the implications of that before posting.

If you just want to reload the file do the first once and the second any time you want to reload.

user=> (use '[clojure.tools.namespace.repl :only (refresh)])

user=> (refresh)

What is described in the article is a little more advanced and has to do with how to control how your reloaded code deals with the old state.

Reply on news.ycombinator.com