I wish leiningen wouldn't take so long to run. The only real trouble with Clojure is how unbearably _slow_ the tools are. I can deal with the runtime taking its time to get going (mostly), but the tooling...
back
3 comments
It's not my experience that Clojure tooling is fundamentally slow, Leiningen is just one option. For many projects I don't use anything more than Maven bash scripts, inf-clojure, and clojure-mode - all overhead free. And projects like CursiveClojure drive home how powerful and responsive tooling for Clojure(Script) can be.
Even so the point of the post is not to bash on Leiningen but to demonstrate how the overhead issues are not insurmountable - it just requires really knowing the tools (surprise) and which knobs to turn. In fact an implicit free idea for someone to explore is to automate all the optimizations for Leiningen that I covered.
I rarely start/stop the repl. I have one running for weeks. And incremental testing or updates in browser(figwheel) is all sub-second.
Same here. No problem at all if a command I run once a week per project takes a few seconds. I can't imagine coding in clojure without leiningen. It stops me from having to deal with a tonne of complexity I really don't want to think about.
As for cljsbuild, I'm guessing this is more a clojurescript compiler issue since again, I run leiningen once and leave it to recompile on file change in the background. Yes would be nice to have some compiler speed improvements but really it isn't that bad. I wait a second or two, not tens of seconds. At least, this is the case for me but then my cljs projects tend too be a couple of thousand lines at most.
That's not even a Clojure thing really. That's been the Achille's Heal of every interactive java app ever.
Hence the need for: http://docs.oracle.com/javase/6/docs/api/java/awt/SplashScre...
Only for those that inside in using only the OpenJDK.
There are JVMs with JIT caches and AOT compilers.
Even the reference JDK can start in a few ms using tiered compilation.