3 ms·

I 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

I 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.

jamii 13y ago
I was not 'bashing' scala. I discussed the tradeoff between removing old cruft from the language and breaking old crufty code. I was careful throughout that entire comment to only discuss differences between the languages and communites and not make or imply any value judgement. I'm trying to provide useful information for people deciding between scala and clojure, not start a fight. With regards to binary compatibility, what I think you are missing is that clojure libraries are almost always distributed as source code. The clojure compiler is fast enough to just compile everything at runtime (during development at least) and clojure has not broken source / api compatibility since the first major version. Where AOT compilation is useful is: a) Improving application startup time b) Shipping libraries which generate java classes at compile-time (usually to c) Shipping proprietary libraries without source code I would definitely like to see the community figure out binary compatibility between libraries to improve cases b and c but it's really not a pressing concern. EDIT: On AOT compilation http://dev.clojure.org/pages/viewpage.action?pageId=1572898 http://dev.clojure.org/pages/viewpage.action?pageId=1572898
- happy_dino 13y ago
  Fair enough, as mentioned, it was not targeted at you. Sorry if I didn't make that clear enough. I was mainly summarizing my impression of the (sad) current standard of debate in interested circles.
Uchikoma 13y ago
1. Java. 2. The problem of binary compatibility is two folded: a. What Scala considers major versions (usually minor changes) b. An open source library community that jumps to beta Scala releases for minor updates These two together create a nightmare to upgrade libraries or Scala versions
- happy_dino 13y ago
  > 1. Java. I said "modern language". > 2. First, the changes are too large, then the changes are too small? What now? It's bad if new Scala versions don't ship with full-scale library support, but it's also bad if developers start testing their libraries early? I guess it is impossible to make you happy.
  - Uchikoma 13y ago
    Sorry to not be able to formulate my concerns in a way you can understand them.

jamii 13y ago

I was not 'bashing' scala. I discussed the tradeoff between removing old cruft from the language and breaking old crufty code. I was careful throughout that entire comment to only discuss differences between the languages and communites and not make or imply any value judgement. I'm trying to provide useful information for people deciding between scala and clojure, not start a fight. With regards to binary compatibility, what I think you are missing is that clojure libraries are almost always distributed as source code. The clojure compiler is fast enough to just compile everything at runtime (during development at least) and clojure has not broken source / api compatibility since the first major version. Where AOT compilation is useful is: a) Improving application startup time b) Shipping libraries which generate java classes at compile-time (usually to c) Shipping proprietary libraries without source code I would definitely like to see the community figure out binary compatibility between libraries to improve cases b and c but it's really not a pressing concern. EDIT: On AOT compilation http://dev.clojure.org/pages/viewpage.action?pageId=1572898 http://dev.clojure.org/pages/viewpage.action?pageId=1572898

happy_dino 13y ago
Fair enough, as mentioned, it was not targeted at you. Sorry if I didn't make that clear enough. I was mainly summarizing my impression of the (sad) current standard of debate in interested circles.

Uchikoma 13y ago

1. Java. 2. The problem of binary compatibility is two folded: a. What Scala considers major versions (usually minor changes) b. An open source library community that jumps to beta Scala releases for minor updates These two together create a nightmare to upgrade libraries or Scala versions

happy_dino 13y ago
> 1. Java. I said "modern language". > 2. First, the changes are too large, then the changes are too small? What now? It's bad if new Scala versions don't ship with full-scale library support, but it's also bad if developers start testing their libraries early? I guess it is impossible to make you happy.
- Uchikoma 13y ago
  Sorry to not be able to formulate my concerns in a way you can understand them.