My Clojure Workflow, Reloaded

http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded

by mark_l_watson • 13 years ago

178 31 13 years ago

_pmf_• 13 years ago

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.

Kaali• 13 years ago

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.

reddit_clone• 13 years ago

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.)

spullara• 13 years ago

Try JRebel.

stonemetal• 13 years ago

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.

outworlder2• 13 years ago

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.

tom_b• 13 years ago

wow - the workflow mgmt hacking Stuart has done seems much more in-depth and hacked on than any Clojure I've actually written.

I mainly play with Clojure for little things, but still, . . . I'm impressed. Heck, I barely use two or three commands out of nrepl.el

moomin• 13 years ago

I've been edging towards something similar in my own code. Tomorrow, I'm going to just rip off this stuff wholesale. Maybe it could make a nice lein plugin.

moonboots• 13 years ago

I was experimenting with integrated tools.namespace reloading in elisp as well, and I found a slightly nicer way to send commands to nrepl:

  (defun nrepl-reset ()
    (interactive)
    (nrepl-interactive-eval "(user/reset)"))

The original elisp function:

  (defun nrepl-reset ()
    (interactive)
    (set-buffer "*nrepl*")
    (goto-char (point-max))
    (insert "(user/reset)")
    (nrepl-return))

jmw74• 13 years ago

Note the former technique will display the output in the minibuffer, the latter will display it in the repl.

dj-wonk• 13 years ago

The linked blog post (above) is a nice write-up and elaboration from Stuart's Clojure/West talk this year: http://clojurewest.org/sessions#sierra

outworlder2• 13 years ago

> It is dangerously easy, when changing and reloading code at the REPL, to get an application into a state which could not have been reached by the code it is currently running.

This is the key point people some comments have been missing. Since you can evaluate code whenever you want, the running instance might become a frankenstein, containing code and data that shouldn't be around anymore.

I'd like to see the point of view of Smalltalk users (who develop against the images).

pjmlp• 13 years ago

I only used Smalltalk at the university back in the day, before Java was born and it was a very nice experience.

All the talks about live editing is nothing more than recovering the workflows we already had in Smalltalk and Lisp machines.

If you destroy the environment, just restart not a big deal.

If you already saved the environment into the image, just rollback to the previous image snapshot, not a big deal specially nowadays that image based source control systems are available, like Monticello and Metacello.

aerique• 13 years ago

I develop Common Lisp the same way (against an image) and it only was a problem when I just started. Soon enough it becomes second nature to know which functions have been changed and / or knowing when it is time to start over with a fresh image.

tl;dr it is not much of an issue

mwcampbell• 13 years ago

It seems to me that the central idea of this post, having all application state rooted in one top-level object/structure with no singletons/globals, with the ability to set up and cleanly tear down multiple instances any number of times, is applicable well beyond Clojure. Looks like all-around good design to me. I suppose some might argue, though, that it's all an elaborate work-around for a slow-starting runtime environment.

timbaldridge• 13 years ago

It also allows for multiple copies of the same application to run on the same VM. That is a nice dev feature.

bad_user• 13 years ago

When working in Clojure, you tend to experiment a lot with the REPL. And the environment (Emacs, clojure-mode, nRepl and Lein) feels like having a dynamic IDE ... so you write code in your text file and with a single short-cut, you recompile your code and then move over to the nRepl window that you keep open in Emacs and you invoke whatever you wrote, to see if it works.

So it's like working with Ruby's irb, or with iPython, except that the integration with Emacs is so freaking nice. So the whole workflow ends up being a back and forth between the code buffer and the repl buffer. And it happens really fast too.

Clojure does have a slow startup, thanks to the JVM. It's not so bad on capable computers though. But that's not the point. The point is that having to restart a repl session interrupts your flow.

Note: I only played with Clojure, haven't done anything serious in it. My favourite is Scala and it would be nice if the Scala repl would do a fast reload on file changes. I don't need it in Scala though, as in Scala you tend to rely less on the repl.

kleiba4• 13 years ago

I didn't know that Clojure puts function comments between the function name and the parameters. I personally find that a bit awkward - wouldn't it make more sense to have it after the parameters, to allow to simply glance at the function definition and see its signature, especially when comments extend over multiple lines?

Tuna-Fish3• 13 years ago

Functions can have several different parameter lists and separate implementations for each one. In practice, this is done by grouping the parameter list of each version with it's body. Where would you put the docstring in:

    (defn foo
        ([x] "bar")
        ([x y] "baz"))
?

kleiba4• 13 years ago

I'd probably put it after the parameter lists:

    (defn foo
        ([x] *docstring* "bar")
        ([x y] *docstring* "baz"))

because you want to be able to document the different implementations differently. The semantics would be: If the function body starts with a string literal, the latter serves as the documentation. If the body consists of any other code following the string literal, it will be ignored for run-time processing; if it's the only thing in the body, it also serves as the return value.

mcav• 13 years ago

It's ambiguous the other way:

   (defn some-string []
      "is this a docstring or a return value?")

DigitalJack• 13 years ago

Clojure works with it in either case, and it is not ambiguous due to the arity of defn.

snikeris• 13 years ago

Made me think of Racket's custodians:

http://docs.racket-lang.org/reference/eval-model.html#%28par...

My Clojure Workflow, Reloaded

Related Stories