2 ms·
Smart conclusions. I'd add to the Lisp-vs-release-management problem: The "I live inside the image" approach discourages delivering stable tested code changes,
by kunley 17y ago
Smart conclusions.
I'd add to the Lisp-vs-release-management problem: The "I live inside the image" approach discourages delivering stable tested code changes, as it's quite hard to isolate them. I agree using a REPL is great for prototyping, but if one never builds from scratch, he can create the unmaintable code which doesn't work outside of a few specially crafted and hacked Lisp images.
Luckily Clojure doesn't seem to hold this legacy. People usually seem to inject code into the repl when they code but then switch to builds using ant, maven or by some layer above them (see Leiningen). I do it as well, compile inside a repl as it's quicker, then compile from scratch before a commit. It seems to be a sane compromise. It's also good you can't save current "jvm image" so there's no temptation to never leave it. I have a sad observation that sticking to "live inside the image" actually produces lone-ego-superstar programmers not willing to cooperate.
- gruseom 17y agoI sadly agree that "lone-ego-superstar programmers not willing to cooperate" are more prominent in the CL world than in some others. (Edit: "semi-autistic pricks" is the term that comes to my mind. Still, many of us are not like that.) I'm also willing to believe that the Clojure community is refreshingly different in this respect. But I don't buy that "living inside the image" has anything to do with this, or at least anything to do with causing it, and I especially don't buy that a technical limitation of Clojure/JVM constitutes some sort of virtue.
- kunley 17y agoOTOH you can measure the technical limitation and then go around it in hours. That's a lot easier than struggling against social limitation for years (as w/ CL).