Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure 1.10 release

clojure.org

Post reply on HN
Print view View original

21–30 of 97 posts

Re: Clojure 1.10 release

#21

Post by JBiserkov »

krn wrote: post #12
jwr wrote: post #10

Earlier quoted context omitted.

> Swift was designed by highly experienced and mature compiler devs "Compiler devs". I think that is exactly my point. I should have said "app developers" or "system designers". If you listen to a Rich Hickey talk, you'll see that he is all about Getting Things Done in the real world, and much less about theoretical concepts. Language design is subservient to app developer needs.

I would put it simply: Clojure was designed by a thinker , who creates when he is away from the keyboard, not in front of it. When one releases and breaks the code in his head first, very few breaking changes are left for the public releases.

Rich Hickey is a great thinker. But he's also an application developer (Datomic). So breaking changes don't just break "other people's code" in the abstract. The pain is real and immediate. By wearing multiple hats he's finding the right balance in a way that language designers who don't code day-to-day simply can't.

Re: Clojure 1.10 release

#22

Post by thaumasiotes »

roenxi wrote: post #20
thaumasiotes wrote: post #16

Earlier quoted context omitted.

I'm going to bring up again how + used to autopromote ints if your result was out of the primitive int range, and now throws an error instead.

If you want to demand perfection, then Clojure isn't going to meet your standards (what would?). The issue here is that, based on the way they (particularly Rich) talk, we can expect they will not do Bloody Stupid things like the old Python 2->3 changeover. Things like big, breaking changes that require architectural changes to keep current, or break all the available tutorials. If the problem can be fixed with a mac…

You don't think a breaking change to + is any more significant than a breaking change to some other part of the language?

Re: Clojure 1.10 release

#23

Post by solussd »

thaumasiotes wrote: post #15
jwr wrote: post #3

From the perspective of a (fairly large-scale at this point) app developer: I find it great that Clojure places such emphasis on backwards compatibility. In general, migration to newer Clojure versions is completely painless. The language has been designed by experienced and mature people and doesn't go through "let's throw everything out and start again" phases like so many other languages do.

Didn't Clojure change the + function (hardly obscure!) from automatically updating ints to bigints and therefore never overflowing to throwing an exception if you added ints that were too big? I've got a Clojure book with a spirited defense of why it's good that the simple symbol + just does what you'd expect instead of throwing exceptions based on an implementation detail, and it kind of falls flat now.

Yes, very early in Clojure's life and only after testing the change across several popular libraries.

Re: Clojure 1.10 release

#24

Post by kbd »

Are there any plans for a native version of Clojure? I'd rather avoid the JVM if possible, but I suppose the whole ecosystem is dependent on it so that's unlikely?

Re: Clojure 1.10 release

#25

Post by preordained »

kbd wrote: post #24

Are there any plans for a native version of Clojure? I'd rather avoid the JVM if possible, but I suppose the whole ecosystem is dependent on it so that's unlikely?

I guess I might ask what this stance is founded on? The JVM is just a binary that runs byte code. It's stable and runs well pretty much everywhere. If you insist the JVM has cooties, you could use Docker and abstract it away, it might be an ideal way to use it anyways depending on your work.

The JVM /= Oracle JVM by the way. There is OpenJDK

EDIT: Also I think recent Java releases have gotten into making self contained binaries (which just means they package the JVM...it's in there, it might jump out and bite you!). But, as long as you are careful what you are shipping, packing up a JVM has always been an option

Re: Clojure 1.10 release

#26

Post by dan-f »

kbd wrote: post #24

Are there any plans for a native version of Clojure? I'd rather avoid the JVM if possible, but I suppose the whole ecosystem is dependent on it so that's unlikely?

In what context are you trying to avoid the JVM?

Re: Clojure 1.10 release

#27

Post by atarian »

jwr wrote: post #3

From the perspective of a (fairly large-scale at this point) app developer: I find it great that Clojure places such emphasis on backwards compatibility. In general, migration to newer Clojure versions is completely painless. The language has been designed by experienced and mature people and doesn't go through "let's throw everything out and start again" phases like so many other languages do.

Which languages threw everything out and started again?

Re: Clojure 1.10 release

#28

Post by dragandj »

kbd wrote: post #24

Are there any plans for a native version of Clojure? I'd rather avoid the JVM if possible, but I suppose the whole ecosystem is dependent on it so that's unlikely?

You can use GraalVM, I guess? But keep in mind that the code typically runs faster on the JVM.

https://www.graalvm.org/

Re: Clojure 1.10 release

#29

Post by souenzzo »

Onde clojure is coded in edn, I think that is no reason to break changes. If one day we need to change something in core, we can make clojure.core2 and make the ns2 macro.

Re: Clojure 1.10 release

#30

Post by dannyobrien »

I've just started toying with Clojure, and while I've enjoyed it a great deal, the error messages were definitely one of the more unfriendly parts. Fortunately, my last two hobby languages were Elm and Haskell, so Clojure was always going to be in the middle between those two extremes). Good to see it being worked on!
Post reply on HN