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

Clojure 1.11 planning

insideclojure.org

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Clojure 1.11 planning

#51

Post by Uhuhreally »

airstrike wrote: post #31
dancek wrote: post #16

Earlier quoted context omitted.

What parts of compatibility are missing? The interop works just fine, as with all other Java. ; example: Stream.of(1,1,2,3,5).map(x -> 2*x).collect(Collectors.toList()) user=> (.. (java.util.stream.Stream/of (to-array [1 1 2 3 5])) (map (reify java.util.function.Function (apply [this x] (* 2 x)))) (collect (java.util.stream.Collectors/toList))) [2 2 4 6 10] Of course it's not practical to convert lists and functions…

Slightly off-topic, but as someone who's normally using Python / R, my hands feel tired just from thinking about typing all of that

In Clojure that's:

  (map (fn [x] (* 2 x)) [1 1 2 3 5])
  => (2 2 4 6 10)

Re: Clojure 1.11 planning

#52

Post by logistark »

dancek wrote: post #16
logistark wrote: post #6

Cool, cool. When is full compatibility with Java 8 be available? I mean Java 8 SAMs, Java 8's Stream, Optional and CompletableFuture...

What parts of compatibility are missing? The interop works just fine, as with all other Java. ; example: Stream.of(1,1,2,3,5).map(x -> 2*x).collect(Collectors.toList()) user=> (.. (java.util.stream.Stream/of (to-array [1 1 2 3 5])) (map (reify java.util.function.Function (apply [this x] (* 2 x)))) (collect (java.util.stream.Collectors/toList))) [2 2 4 6 10] Of course it's not practical to convert lists and functions…

I think first class support would remove a lot of boilerplate in that code. For the purpose of writing that, i prefer to write it directly in Java.

Re: Clojure 1.11 planning

#54

Post by wry_discontent »

dkersten wrote: post #42
dancek wrote: post #5

Earlier quoted context omitted.

Spec is great for validation. For example, we have a HTTP API built using https://github.com/metosin/reitit where we have specs for each endpoint. We have a coercion middleware that checks each request (and optionally response) conforms to a spec (and coerces things like integer ids from path to the correct type). And there's a swagger handler that automatically generates a full documentation of the API just from the…

I have a somewhat off-topic question I've been wondering about... How do you pronounce "reitit"? I've been considering giving a talk on it at my local clojure group, so I should probably learn how to actually say the word!

In my brain I usually say re-it-it, but sometimes I think "rye-tit" which makes me laugh and definitely seems wrong.

Re: Clojure 1.11 planning

#55

Post by pjmlp »

Scarbutt wrote: post #44
pjmlp wrote: post #11

Earlier quoted context omitted.

This is why guest languages tend to fade away, as the platform evolves and the platform system languages adopt the features that made those guest languages appear in first place.

Kotlin seems promising (because of android).

Not really.

Kotlin already has an impedance mismatch with the JVM, because like all guest languages they have come up with their own ideas, which don't follow how the platform ended up implementing them.

Examples are sequences vs streams, lambdas vs SAM types, default interface methods, co-routines vs fibers, inline classes vs records, reflection.

Only first class support on JetBrains products, while many Java shops are still Eclipse, NetBeans and Oracle Studio users.

Additionally, since they want to stretch outside the JVM, there are semantic restrictions if the code is also supposed to be compiled by Kotlin/Native.

Kotlin has indeed a future on Android, given that Google is unwilling to move their support beyond the Android Java flavour (aka Google's own J++) and with #KotlinFirst, Android has become the KVM.

So, on Android I do agree that Kotlin has a bright future, however in what concerns the JVM I forsee an adoption cycle like every other JVM guest language.

Re: Clojure 1.11 planning

#56

Post by pjmlp »

dustingetz wrote: post #20
pjmlp wrote: post #11

Earlier quoted context omitted.

This is why guest languages tend to fade away, as the platform evolves and the platform system languages adopt the features that made those guest languages appear in first place.

Clojure accepts multiple hosts and is simple enough to port to new ones – a hugely underappreciated reason that Clojure is permanent

Just like many Lisp and Scheme implementations that came before it.

Re: Clojure 1.11 planning

#57

Post by Uhuhreally »

Scarbutt wrote: post #53
Uhuhreally wrote: post #50

Earlier quoted context omitted.

you'd use Clojure not Java for an example like the above

I think the context is when doing interop.

yes but I got the feeling the grandparent was confused so I tried to clarify that the only reason for the verbosity is interop - the Clojure code is much more concise than the Java - the interop code is like listening to a speech being translated between English and Spanish

Re: Clojure 1.11 planning

#58

Post by keymone »

logistark wrote: post #52
dancek wrote: post #16

Earlier quoted context omitted.

What parts of compatibility are missing? The interop works just fine, as with all other Java. ; example: Stream.of(1,1,2,3,5).map(x -> 2*x).collect(Collectors.toList()) user=> (.. (java.util.stream.Stream/of (to-array [1 1 2 3 5])) (map (reify java.util.function.Function (apply [this x] (* 2 x)))) (collect (java.util.stream.Collectors/toList))) [2 2 4 6 10] Of course it's not practical to convert lists and functions…

I think first class support would remove a lot of boilerplate in that code. For the purpose of writing that, i prefer to write it directly in Java.

Why wouldn’t you prefer writing it directly in Clojure?

    (map #(* % 2) [1 2 3 4 5])
Even less boilerplate, even more signal/noise.

Re: Clojure 1.11 planning

#59

Post by _bxg1 »

> Spec 2 has been kind of stalled out as Rich is thinking through some of the work we were doing on how to rework function specs and the use case of automating form/map versions of the specs.

It's fascinating to watch a major enterprise language with a Steve Jobs figure at the top, who maintains a firm grip on the wheel, keeping it on track with his clear vision even as its community grows in scale, to the point where he alone would be a bottleneck in its design process.

I mean it's clearly working out - as it worked out for Jobs - it's just highly unusual.

Re: Clojure 1.11 planning

#60

Post by _bxg1 »

roenxi wrote: post #3

I enjoy Clojure and spec is very interesting; but it remains uncertain if I have any problems that spec will solve. I'm not really that interested in the generative testing aspect since I write mostly amateur code. So I can't figure out if it is more like a debugger for targeted location of difficult bugs or more like compiler error messages where it becomes a pervasive part of the workflow. There is obviously someth…

I see it mainly as an answer to static types. Clojure (like most Lisps) places emphasis on dynamic types, for some valid reasons (https://lispcast.com/clojure-and-types/). But there are certain undeniable benefits of static typing that you miss out on: documentation, and IDE hints. Spec, the way I see it, is a way to reclaim some of those benefits without giving up the dynamic paradigm. It also has some advantages over static type systems; most notably you can describe any arbitrary assertion, which makes it more expressive than regular types. You can also check things at runtime, which can be useful for validating foreign inputs that aren't available at build time.

Personally I'm still a static-types person, but I get it. And if I used Clojure regularly, I'd be all over Spec.

Post reply on HN