Clojure 1.7 is now available • Hacker News Board

Re: Clojure 1.7 is now available

#91

Post by jwhitlark » Tue, Jun 30, 2015, 8:36 PM UTC

27182818284 wrote: post #2

>Transducers are composable algorithmic transformations. They are independent from the context of their input and output sources and specify only the essence of the transformation in terms of an individual element. Because transducers are decoupled from input or output sources, The biggest thing holding me back from learning Clojure is that I fear it will take me a decade to become remotely competent in it.

Basic competence comes pretty quick, it's a small core language, compared to most. Most things like transducers you can ignore for a long time. The longest part of learning it for me was learning to think functionally, but you can do that in pieces, and nearly all of what you learn is applicable to any functional language, or even imperative languages with functional aspects.

Re: Clojure 1.7 is now available

#92

Post by zak_mc_kracken » Tue, Jun 30, 2015, 8:43 PM UTC

bad_user wrote: post #81

pron wrote: post #76

Earlier quoted context omitted.

> Clojure doesn't have to do this, because Clojure dependencies get distributed as source-code Clojure doesn't have to do this because it was designed to allow separate compilation as much as possible[1], and because it hardly ever changes binary representation in backwards-incompatible ways. Protocols and multimethods are indeed handled at the call-site, but in such a way that a change to the protocol/multimethods d…

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 CoffeeSc…

> for the simple reason that Java is designed to be mainstream,

Not really. Java was designed to be practical, and it ended up being mainstream.

Most languages want to become mainstream (including Scala), most of them just fail to achieve that goal for a variety of reasons, often due to their design decisions (but not always).

Re: Clojure 1.7 is now available

#93

Post by puredanger » Tue, Jun 30, 2015, 8:45 PM UTC

bad_user wrote: post #63

kul_ wrote: post #50

Earlier quoted context omitted.

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.

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 co…

Clojure itself actually is distributed as compiled .class files. We take some effort to ensure that there are not changes that break binary compatibility from AOT-compiled Clojure code (which is not uncommon) and break its calls into the Clojure compiler or runtime.

Re: Clojure 1.7 is now available

#94

Post by puredanger » Tue, Jun 30, 2015, 8:49 PM UTC

pron wrote: post #89

sreque wrote: post #79

Earlier quoted context omitted.

This doesn't seem true. See http://comments.gmane.org/gmane.comp.java.clojure.user/85930 "Binary compatibility across releases is not guaranteed, but it is something we strive to maintain if possible. "

If you read what it says, they've changed an implementation of a function which may change ordering of unordered collections, and that may break some people's code if they relied on some specific ordering. They are not talking about breaking interfaces. In fact, they specifically say they are not aware of any binary incompatibilities. Their "strive to maintain" works out very well in practice, so far.

I wrote that sentence and you should take it as written. In general, we strive to maintain binary compatibility (old AOT-compiled Clojure code should continue to run on newer version), we do not exhaustively test for or guarantee that. At times we have broken this in alphas etc and we take it as a high priority to fix such things.

Re: Clojure 1.7 is now available

#95

Post by jonase » Tue, Jun 30, 2015, 8:54 PM UTC

bad_user wrote: post #88

jonase wrote: post #86

Earlier quoted context omitted.

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?

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 c…

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.

Re: Clojure 1.7 is now available

#96

Post by puredanger » Tue, Jun 30, 2015, 8:57 PM UTC

jonase wrote: post #86

bad_user wrote: post #81

Earlier quoted context omitted.

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 CoffeeSc…

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?

Maybe a mitigating factor is that any Clojure 2-arg function extends AFunction which implements Comparator. So any Clojure function that returns -1/0/1 will work transparently. Example, use - as a comparator:

=> (sorted-set-by - 2 9 3 5 4) #{2 3 4 5 9}

Re: Clojure 1.7 is now available

#97

Post by giancarlostoro » Tue, Jun 30, 2015, 9:03 PM UTC

andrewvc wrote: post #29

giancarlostoro wrote: post #24

My only negativity with Clojure isn't really with the language itself, but with the Debian / Ubuntu packages, they're way outdated. Not sure who ever maintained them, or why they stopped doing so 1.4 being the last version. Outside of that for anyone wanting to check it out, you could try downloading LightTable and using ClojureScript, seems to be close enough I am able to use Clojure books with ClojureScript, not su…

It really doesn't make sense to 'install' clojure the language. Generally one would use apt to install java. Then, you'd download 'lein' the clojure build tool (which does not require a clojure 'install'), and then specify the clojure version in your project.clj file. Lein builds your project and downloads the correct clojure version. For distributing your app, you just compile it to a JAR, and the user only needs pl…

Ah, I see. I never knew 'lein' was capable of doing this. Very useful thanks!

Re: Clojure 1.7 is now available

#98

Post by puredanger » Tue, Jun 30, 2015, 9:09 PM UTC

bad_user wrote: post #81

pron wrote: post #76

Earlier quoted context omitted.

> Clojure doesn't have to do this, because Clojure dependencies get distributed as source-code Clojure doesn't have to do this because it was designed to allow separate compilation as much as possible[1], and because it hardly ever changes binary representation in backwards-incompatible ways. Protocols and multimethods are indeed handled at the call-site, but in such a way that a change to the protocol/multimethods d…

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 CoffeeSc…

Re collections: There are Java interfaces you can implement to make your own collections that work as built-ins. In general, nothing in the Clojure compiler or runtime is written based on concrete collection classes, only on the internal interfaces. It's perfectly feasible to write a deftype that implements Counted and Associative and whatever else and make your own things that work with all the existing standard library. There are plenty of examples of this.

Re sorted-set: Any 2-arg Clojure function that returns -1/0/1 comparable semantics will work.

Re staying "in vectors": The subtle blurring of the sequential collections between the collections and sequences is part of what makes so much of working with data in Clojure easy. However, there are certainly times when you want more control over this; fortunately in 1.7 with transducers you have the ability to control your output context (with functions like into or conj) and this is easier now than ever.

Re rx: several people have already implemented the use of transducers with Rx. I know there's a RxJs and I'm pretty sure I saw something re JavaRx although I can't put my finger on it right now.

Re: Clojure 1.7 is now available

#99

Post by pron » Tue, Jun 30, 2015, 9:09 PM UTC

bad_user wrote: post #81

pron wrote: post #76

Earlier quoted context omitted.

> Clojure doesn't have to do this, because Clojure dependencies get distributed as source-code Clojure doesn't have to do this because it was designed to allow separate compilation as much as possible[1], and because it hardly ever changes binary representation in backwards-incompatible ways. Protocols and multimethods are indeed handled at the call-site, but in such a way that a change to the protocol/multimethods d…

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 CoffeeSc…

> given that Clojure is a dynamic language

Yes, that helps in this case, but that doesn't mean being statically compiled allows you to disregard extra-linguistic downsides.

> however it has many things that need to be cleaned out.

No! There are things that could have been better; sure. But they don't need to be cleaned out because that would break backwards compatibility. Backwards compatibility is a very, very, very important thing. So much more important than a "perfect implementation" (something that can never be achieved anyway). This is something that is very hard for PL purists to understand, but extra-linguistic features and guarantees trump 100% consistency almost every time.

> It's also disheartening to see that the sorted-set wants things that implement Java's Comparable.

That's only disheartening if you're a purist. If you care about extra-linguistic concerns, such as Java interoperation, this is a mark of great design. You see how the language designers took into account concerns outside the language itself. Every Clojure map is a Java map and vice versa. Every Clojure sequence is a Java collection and vice versa. Every Clojure sorted set is a Java sorted set and vice versa. This is great design around constraints and what Rich Hickey always talks about. The language itself is no more important than how it fits within the larger ecosystem and its constraints.

> as I can't see how it can be applied to reactive streams (e.g. Rx) when back-pressure is involved

Clojure is an imperative language first and functional second. It is even more imperative than Scala (in spite of Scala's mutability) -- at least with Scala's (recent-ish) emphasis on pure-functional concepts (a terrible idea, BTW, but that's a separate discussion). Back-pressure is therefore automatic (and implicit) with pull-based channels (that transducers can be applied to).

> I prefer languages that fix their mistakes

Because you're a purist. I prefer languages that see the big picture consider what's important in the grand scheme of things, and realize that code is important but secondary to working programs. As Rich Hickey is not a PL researcher, I am sure that those mistakes will only be fixed if they don't break compatibility or Java interoperability, which are more important for the industry than a perfectly clean language.

> not sure why we're having this conversation

Because supporting separate compilation -- if not perfectly then at least treating it as a top-priority concern -- is one of the key ways to ensure binary compatibility between runtime-library versions.

> On the other hand certain features, like traits providing method implementations or default parameters are landmines.

That's exactly my point. Separate compilation (as many other crucial extra-linguistic concerns) is just not a priority for Scala. Kotlin, OTOH, implements default arguments on the receiver end rather than at the call-site, so changing default values in the target doesn't necessitate recompiling the caller.

Re: Clojure 1.7 is now available

#100

Post by puredanger » Tue, Jun 30, 2015, 9:14 PM UTC

birdsbolt wrote: post #82

puredanger wrote: post #35

Earlier quoted context omitted.

Re the last sentence, that is not true, nor was it a claim.

I think I saw a talk, or a statement somewhere, made by Rich Hickey - https://news.ycombinator.com/item?id=8342718 . I believe it was in this talk. Not that I was being negative about it.

Rich didn't claim you couldn't implement it. He just claimed that some aspects of transducers are difficult to represent as types. Or at least, that's how I took it.