3 ms·

In my opinion choosing a different language than the host (in this instance Java) has to bring enough advantages to balance out the disadvantages, like less (id

In my opinion choosing a different language than the host (in this instance Java) has to bring enough advantages to balance out the disadvantages, like less (idiomatic) libraries, less documentation, less tools, less developers available on the market. Not to pick on Kotlin, I'm sure there are people that love it, however I personally don't see what advantages a language like Kotlin brings over Java 8, being CoffeeScript versus Javascript all over again. With Clojure or Scala we are talking about languages going into territories that Java will never venture into, for the simple reason that Java is designed to be mainstream, which really means appealing to the common denominator. Of course, as we've seen with CoffeeScript, the market can be irrational, but it started to go away already, after a new version of Javascript plus the realization that everything brought by those small syntactic differences was bullshit. Going back to Clojure and the need or lack thereof to recompile call-sites, given that Clojure is a dynamic language that doesn't have to concern itself with much static information and that does get distributed as source-code, I feel that this is an apples versus oranges discussion. But anyway, lets get back to protocols. So protocols do generate corresponding Java interfaces, just like Scala's traits. Except that Clojure being a dynamic language, there isn't much to do when your functions look like this to the JVM: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java https://github.com/clojure/clojure/blob/master/src/jvm/cloju... There's also the issue that Clojure's standard library has been more stable. Well, that can be a virtue and in the eye of the beholder can be seen as a good design, however it has many things that need to be cleaned out. As a Clojure newbie I couldn't understand for example why I can't implement things that work with map or filter or mapcat, or things that can be counted, or compared, only to find out that its protocols and multi-methods aren't used in its collections and that there isn't a Clojure specific thing I can implement to make my own things that behave like the builtins. It's also disheartening to see that the sorted-set wants things that implement Java's Comparable. Clojure's collections have sometimes surprising behavior - like for example I might choose a Vector because it has certain properties, but if you're not careful with the operations applied you can end up with a sequence or a list and then you have to back-trace your steps (e.g. conj is cool, but the concept should have been applied to other operators as well IMHO). Transducers are freaking cool, however I feel that the protocol of communication isn't generic enough, as I can't see how it can be applied to reactive streams (e.g. Rx) when back-pressure is involved (might be wrong, haven't reasoned about it enough). As any other language or standard library, Clojure is not immune to mistakes and personally I prefer languages that fix their mistakes (which I'm sure Clojure will do). EDIT: on "separate compilation", not sure why we're having this conversation, but generally speaking Scala provides backwards compatibility for everything that matches Java. Adding a new method to a class? Changing the implementation of a function? No problem. On the other hand certain features, like traits providing method implementations or default parameters are landmines. Along with Java 8 things might improve, as the class format is now more capable. As I said, there's a roadmap to deal with this and with targeting different platforms (e.g. Java 8 versus Javascript versus LLVM) through TASTY, but I don't know when they'll deliver.

jonase 11y ago
Sorry to jump in on an interesting discussion but I got interested in this part: > It's also disheartening to see that the sorted-set wants things that implement Java's Comparable. Could you quickly explain what's disheartening about Java's Comparable interface and what the available options are?
- bad_user 11y ago
  In a static language like Scala or Haskell you usually work with a type-class, which is pretty cool because you can provide implementations for types you don't control (not implying that Scala's Ordering is perfect). Instead of Java's Comparable interface I was expecting a protocol, which are almost equivalent to type-classes, or a multi-method. Of course, in many implementations you usually also get a version of a constructor that uses a provided comparison function. However certain things, like plain numbers or strings, have a natural ordering to them, hence the need to have the sorted-set in Clojure also work with Java's Comparable. But again, I was expecting a Clojure specific protocol. The reason for why this happens, I believe, is because protocols weren't there from the beginning, being a feature introduced in Clojure 1.2. From what I understood, in ClojureScript protocols are "at the bottom" as they say, so there's hope :-)
  - jonase 11y ago
    Thanks! So if I read your comment correctly there is nothing inherently wrong with the Comparable interface it's just that Clojure's sorted sets and maps could have used protocols instead. I can see why that would be useful for extending existing types (as you mentioned). OTOH it’s not often I’ve seen third-party types that I wanted to be comparable but were not. In general I think that if a type does not implement a core interface you have to consider the possibility that the designer chose not to implement it for a reason.
  - puredanger 11y ago
    Protocols were added in Clojure 1.2, well after the Clojure collections or stdlib were created. In a perfect world, Clojure itself could leverage protocols more widely across the stdlib. For practical reasons, this is difficult now.

jonase 11y ago

Sorry to jump in on an interesting discussion but I got interested in this part: > It's also disheartening to see that the sorted-set wants things that implement Java's Comparable. Could you quickly explain what's disheartening about Java's Comparable interface and what the available options are?

bad_user 11y ago
In a static language like Scala or Haskell you usually work with a type-class, which is pretty cool because you can provide implementations for types you don't control (not implying that Scala's Ordering is perfect). Instead of Java's Comparable interface I was expecting a protocol, which are almost equivalent to type-classes, or a multi-method. Of course, in many implementations you usually also get a version of a constructor that uses a provided comparison function. However certain things, like plain numbers or strings, have a natural ordering to them, hence the need to have the sorted-set in Clojure also work with Java's Comparable. But again, I was expecting a Clojure specific protocol. The reason for why this happens, I believe, is because protocols weren't there from the beginning, being a feature introduced in Clojure 1.2. From what I understood, in ClojureScript protocols are "at the bottom" as they say, so there's hope :-)
- jonase 11y ago
  Thanks! So if I read your comment correctly there is nothing inherently wrong with the Comparable interface it's just that Clojure's sorted sets and maps could have used protocols instead. I can see why that would be useful for extending existing types (as you mentioned). OTOH it’s not often I’ve seen third-party types that I wanted to be comparable but were not. In general I think that if a type does not implement a core interface you have to consider the possibility that the designer chose not to implement it for a reason.
- puredanger 11y ago
  Protocols were added in Clojure 1.2, well after the Clojure collections or stdlib were created. In a perfect world, Clojure itself could leverage protocols more widely across the stdlib. For practical reasons, this is difficult now.