3 ms·
I didn't find that comparison very useful/accurate (having used clojure heavily for a year or two and scala full-time for the past month). The main differences
by jamii 13y ago
I didn't find that comparison very useful/accurate (having used clojure heavily for a year or two and scala full-time for the past month). The main differences I find are:
When evaluating language tradeoffs the scala community values power more and the clojure community values simplicity more.
Scala wants to provide you with the most powerful language possible. Clojure wants to make it easy for you to mold your own language.
Scala language tooling works at compile-time and analyses the language statically. Clojure language tooling connects to a running environment and uses introspection. Scala has much better static checking and clojure has much better introspection. While both languages have a repl, the clojure community puts much more emphasis on live, interactive programming.
Clojures syntactic extension mechanisms are much simpler, being based on sexps. Scalas are powerful (eg can access the lexical environment) but much more heavy-weight.
Clojure has run-time eval. This makes it possible to do eg domain-specific jit (eg compiling DSLs -> clojure code -> java bytecode on the fly). Scala has a run-time interpreter which I haven't used but is reputed to be slow.
I haven't yet explored non-jvm backends for scala but I suspect that clojure will eventually dominate on that front for two reasons: 1) when clojure-in-clojure is finished porting clojure to a new platform will be far easier than scala and 2) clojure was designed from the beginning to be a parasitic language and delegates many features to the underlying platform.
Scala breaks backwards compatibility much more often than clojure. Whether this is a pro or con is up for debate. There are lots of small niggling things in clojure I would like to change but on the other hand maintaining scala code across compiler updates is a pain in the ass.
Personally, I believe that the number one problem a language needs to address is managing complexity. The clojure community largely seems to get that and is driving for simple, orthogonal language features and libraries to an extent that I've not seen in any other community (eg http://blog.getprismatic.com/blog/2012/10/1/prismatics-graph-at-strange-loop.html http://blog.getprismatic.com/blog/2012/10/1/prismatics-graph...). In addition, the most exciting research I've seen on that front (eg http://www.vpri.org/pdf/tr2011004_steps11.pdf http://www.vpri.org/pdf/tr2011004_steps11.pdf http://boom.cs.berkeley.edu/ http://boom.cs.berkeley.edu/ ) and most of my favorite tools rely on powerful introspection and runtime code generation. I think Yegge describes this better than I can - http://steve-yegge.blogspot.co.uk/2007/01/pinocchio-problem.html http://steve-yegge.blogspot.co.uk/2007/01/pinocchio-problem....
- Uchikoma 13y agoAfter 5yrs of Scala usage, "but on the other hand maintaining scala code across compiler updates is a pain in the ass." this is really a pain, especially if you come from Java where probably 15yrs old code still runs. I would no longer go with Scala for a new project but give Clojure a try.
- happy_dino 13y agoQ: What does java.lang.NoSuchMethodError: clojure.lang.RestFn.<init>(I)V mean? A: It means you have some code that was AOT (ahead-of-time) compiled with a different version of Clojure than the one you're currently using. If it persists after running lein clean then it is a problem with your dependencies. Note that for your own project that AOT compilation in Clojure is much less important than it is in other languages. There are a few language-level features that must be AOT-compiled to work, generally for Java interop. If you are not using any of these features, you should not AOT-compile your project if other projects may depend upon it. https://github.com/technomancy/leiningen/blob/stable/doc/FAQ.mdhttps://github.com/technomancy/leiningen/blob/stable/doc/FAQ.md https://github.com/technomancy/leiningen/blob/stable/doc/FAQ...
- jamii 13y agoI've never even seen AOT compiled code. If it becomes common (maybe in proprietary projects?) then I would argee that its important to maintain binary compatability.
- happy_dino 13y agoI just wanted to highlight how bizarre this discussion has become in general (nothing against you, it seems to be a common theme): “““ I'm unhappy with Scala's compatibility guarantees, therefore I'll pick a language which a) does not provide any binary compatibility guarantees at all, b) has no tool to figure out whether incompatible changes have actually happened, c) lacks any sort of guidance to figure out if library A is compatible with library B short of downloading and executing them together, d) provides no clean way to cross-compile libraries against multiple versions. But hey, let's bash Scala for caring about these issues and deride them for shipping actual, working solutions addressing those issues. ””” Scala guarantees: - Source compatibility between major versions - Source and binary compatibility (both backward and forward) for all minor and update releases of that major version People will have a hard time to find another modern language which gives them these guarantees. Hypocrisy and cognitive dissonance FTW, I guess.