11–20 of 33 posts
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).
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 env…
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 env…
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 env…
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.
Earlier quoted context omitted.
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 i…
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.)
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.
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?
(defn foo
([x] "bar")
([x y] "baz"))
?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?
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")) ?
(defn foo
([x] *docstring* "bar")
([x y] *docstring* "baz"))
Earlier quoted context omitted.
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")) ?
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; i…
I disagree with this. Since the normal functions cannot dispatch on type⁺, only arity, the different implementations are typically very related and should share same documentation. Your proposal would lead to massive duplication, and reduce the likelihood of people actually documenting the functions.
⁺ There are two separate mechanisms for providing richer function dispatch, both allow more granular documentation.