3 ms·
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 ab
by mwcampbell 13y 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 13y agoIt also allows for multiple copies of the same application to run on the same VM. That is a nice dev feature.
- deleted 13y ago[deleted]
- bad_user 13y agoWhen 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.