8 ms·

Yes this is something clojure users take for granted. I dont know the state of Scala right now but a year back even minor version bump was horrible in scala in

by kul_ 11y ago

Yes this is something clojure users take for granted. I dont know the state of Scala right now but a year back even minor version bump was horrible in scala in terms of backward compatibility. Really impressive job by clojure code devs in terms of maintaining such stable releases.

xixixao 11y ago
Is the job simpler because Clojure is not statically typed?
- raspasov 11y ago
  Or because it's a lisp? : )
- arohner 11y ago
  I'm not a Scala user, but Clojure the language tends to be extremely stable. Existing stdlib functions almost never get updated, unless they add a new (backwards-compatible) arities. Releases tend to consist mostly of new features, and a small number of bugfixes.
- dragonwriter 11y ago
  Probably, more because its a lisp, whereas Scala was more of a fundamentally new language that isn't a member of such a well-studied family, but instead was led by inspiration from lots of different places, and has a lot more work in shaking out how to reconcile those influences into a coherent whole. Though Scala being not merely statically typed by aimed at both interoperating with Java's type system and supporting a more robust and powerful type system than Java does did pose particular challenges.
- yogthos 11y ago
  Part of it is that the standard library API has been stable for years, where new things are added but no breaking changes are introduced. The second reason is that Clojure libraries are typically shipped as source. This avoids the whole binary compatibility problem you see in Scala. Typically, you only compile the end applications to byte code.
- pron 11y ago
  I don't think so. It's because of a strong commitment to users not to introduce breaking changes. I've been mostly using Java and Clojure in recent years, and before that C/C++ and I'm pretty surprised people don't take backwards compatibility for granted, and that there are languages that don't consider it a top priority. (Well, new C++ compiler versions sometimes broke existing code, but that was quite rare)
- bad_user 11y ago
  No, it's because Scala's dependencies / libraries get distributed as compiled .class files, whereas Clojure's get distributed as source-code. Tried explaining this above: https://news.ycombinator.com/item?id=9807323 https://news.ycombinator.com/item?id=9807323
bad_user 11y ago
Scala's minor versions don't break compatibility. A year ago Scala 2.11 (major) was being released, which means you're talking about either 2.10.x or 2.11.x, neither of which broke binary compatibility between minor versions. And major versions usually have source level compatibility, our upgrade from 2.10 to 2.11 being pretty smooth. The fundamental difference is that Clojure gets distributed as source and not as compiled .class files. Being an interpreted language that gets compiled on the fly does have some advantages. But it also has drawbacks. Startup performance suffers, the Java interoperability story is worse, many tools such as Android's toolchain expect bytecode, etc ... The problem that Scala has (and also Clojure, as soon as you do AOT) is that Scala's idioms do not translate well into Java bytecode, as Java's bytecode is designed for, well, Java. Therefore even small and source-compatible changes, like adding another parameter with a default value to a method or like adding a method to a trait, can trigger binary incompatibilities. The plan for Scala is to embed in the .class, besides the bytecode, the abstract syntax tree built by the compiler and then the compiler can take a JAR and repurpose it for whatever platform you want. This is part of the TASTY and the Scala-meta projects. If you think about it it's not that far from what Clojure is doing, except that this is done in the context of a static language that doesn't rely on the presence of an interpreter at runtime. Of course, LISPs are pretty cool. And of course, you'll still need to recompile your projects, but at least then the dependencies won't have to be changed.
- pron 11y ago
  > and also Clojure, as soon as you do AOT Not so much. You can do separate compilation with Clojure to a far greater extent than Scala (perhaps even completely). The Java interfaces of Clojure functions haven't changed in incompatible ways in a very, very long time.
  - mateuszf 11y ago
    That's just the power of good upfront design.
  - bad_user 11y ago
    The Java interfaces that Clojure relies on don't matter that much. On the other hand what is the bytecode representation of a protocol or of a multi-method? Scala has an equivalent representation for everything it has. For example traits are just Java interfaces but with corresponding static methods. Another example is default parameters (a concept Java doesn't have) is done with method overloading. The Scala compiler has to infer Scala-specific stuff (like signatures using Scala features) from compiled bytecode. Functions that aren't methods (e.g. anonymous functions) get compiled either to static methods, or to classes that have to be instantiated (in case it's about closures closing over their context). Scala does not have the concept of static methods, but it has singleton objects, which can also implement interfaces. Of course, these get compiled to static methods, but there's also a singleton instance instantiated for those cases in which you want to use that singleton object as a real polymorphic instance. Etc, etc... So there's a protocol in place for how to encode this in the bytecode, there's a protocol for everything. And so even small changes in Scala's standard libraries can trigger big bytecode changes that end up being backwards incompatible. Clojure doesn't have to do this, because Clojure dependencies get distributed as source-code, as I've said.

by kul_ 11y ago

xixixao 11y ago

Is the job simpler because Clojure is not statically typed?

raspasov 11y ago
Or because it's a lisp? : )
arohner 11y ago
I'm not a Scala user, but Clojure the language tends to be extremely stable. Existing stdlib functions almost never get updated, unless they add a new (backwards-compatible) arities. Releases tend to consist mostly of new features, and a small number of bugfixes.
dragonwriter 11y ago
Probably, more because its a lisp, whereas Scala was more of a fundamentally new language that isn't a member of such a well-studied family, but instead was led by inspiration from lots of different places, and has a lot more work in shaking out how to reconcile those influences into a coherent whole. Though Scala being not merely statically typed by aimed at both interoperating with Java's type system and supporting a more robust and powerful type system than Java does did pose particular challenges.
yogthos 11y ago
Part of it is that the standard library API has been stable for years, where new things are added but no breaking changes are introduced. The second reason is that Clojure libraries are typically shipped as source. This avoids the whole binary compatibility problem you see in Scala. Typically, you only compile the end applications to byte code.
pron 11y ago
I don't think so. It's because of a strong commitment to users not to introduce breaking changes. I've been mostly using Java and Clojure in recent years, and before that C/C++ and I'm pretty surprised people don't take backwards compatibility for granted, and that there are languages that don't consider it a top priority. (Well, new C++ compiler versions sometimes broke existing code, but that was quite rare)
bad_user 11y ago
No, it's because Scala's dependencies / libraries get distributed as compiled .class files, whereas Clojure's get distributed as source-code. Tried explaining this above: https://news.ycombinator.com/item?id=9807323 https://news.ycombinator.com/item?id=9807323

bad_user 11y ago

Scala's minor versions don't break compatibility. A year ago Scala 2.11 (major) was being released, which means you're talking about either 2.10.x or 2.11.x, neither of which broke binary compatibility between minor versions. And major versions usually have source level compatibility, our upgrade from 2.10 to 2.11 being pretty smooth. The fundamental difference is that Clojure gets distributed as source and not as compiled .class files. Being an interpreted language that gets compiled on the fly does have some advantages. But it also has drawbacks. Startup performance suffers, the Java interoperability story is worse, many tools such as Android's toolchain expect bytecode, etc ... The problem that Scala has (and also Clojure, as soon as you do AOT) is that Scala's idioms do not translate well into Java bytecode, as Java's bytecode is designed for, well, Java. Therefore even small and source-compatible changes, like adding another parameter with a default value to a method or like adding a method to a trait, can trigger binary incompatibilities. The plan for Scala is to embed in the .class, besides the bytecode, the abstract syntax tree built by the compiler and then the compiler can take a JAR and repurpose it for whatever platform you want. This is part of the TASTY and the Scala-meta projects. If you think about it it's not that far from what Clojure is doing, except that this is done in the context of a static language that doesn't rely on the presence of an interpreter at runtime. Of course, LISPs are pretty cool. And of course, you'll still need to recompile your projects, but at least then the dependencies won't have to be changed.

pron 11y ago
> and also Clojure, as soon as you do AOT Not so much. You can do separate compilation with Clojure to a far greater extent than Scala (perhaps even completely). The Java interfaces of Clojure functions haven't changed in incompatible ways in a very, very long time.
- mateuszf 11y ago
  That's just the power of good upfront design.
- bad_user 11y ago
  The Java interfaces that Clojure relies on don't matter that much. On the other hand what is the bytecode representation of a protocol or of a multi-method? Scala has an equivalent representation for everything it has. For example traits are just Java interfaces but with corresponding static methods. Another example is default parameters (a concept Java doesn't have) is done with method overloading. The Scala compiler has to infer Scala-specific stuff (like signatures using Scala features) from compiled bytecode. Functions that aren't methods (e.g. anonymous functions) get compiled either to static methods, or to classes that have to be instantiated (in case it's about closures closing over their context). Scala does not have the concept of static methods, but it has singleton objects, which can also implement interfaces. Of course, these get compiled to static methods, but there's also a singleton instance instantiated for those cases in which you want to use that singleton object as a real polymorphic instance. Etc, etc... So there's a protocol in place for how to encode this in the bytecode, there's a protocol for everything. And so even small changes in Scala's standard libraries can trigger big bytecode changes that end up being backwards incompatible. Clojure doesn't have to do this, because Clojure dependencies get distributed as source-code, as I've said.