Live data from Hacker News

Clojure 1.11 planning

insideclojure.org

11–20 of 72 posts

Re: Clojure 1.11 planning

#11

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

Clojure is a different language. Being "fully compatible" with (more similar to) Java was never a goal.

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.

Re: Clojure 1.11 planning

#12
post #11

Earlier quoted context omitted.

Clojure is a different language. Being "fully compatible" with (more similar to) Java was never a goal.

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.

That is true for guest languages designed to overcome specific issues in a given language (think CoffeeScript vs. JavaScript in 2012 and then in 2019). But I don't think it really applies to Java vs. Clojure, which both pretty much force a specific (different) programming paradigms and have completely different design.

Re: Clojure 1.11 planning

#13
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…

My daily usage:

- input and message streams validation.

- data generation for testing.

- spec is the best data structures documentation!

- sequential data structures parsing and transform

More magic, but based on everything mentioned: dev-time macro input and destructuring sanitizing and error report.

Re: Clojure 1.11 planning

#14

Spec is very useful, but please implement it without macros. Metosin did a great job to make it more usable, but we still struggle because specs could only exist in Namespaces. We want to use spec as EDN with pure functions. (+ recursive specs would be awesome)

For schemas as EDN you might want to take a look at malli:

https://github.com/metosin/malli

Re: Clojure 1.11 planning

#15
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…

The dream for me is to model things like HTML5 specification as data instead of English

Re: Clojure 1.11 planning

#16

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 to their Java counterparts like that, but if you need to work with Java objects it's possible.

Re: Clojure 1.11 planning

#17
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 use it often as a giant sanity assert that guards my application state in dev mode. In lieu of static types. Helps me catch dumb type errors early at the site of mutation.

Re: Clojure 1.11 planning

#18
post #11

Earlier quoted context omitted.

Clojure is a different language. Being "fully compatible" with (more similar to) Java was never a goal.

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.

Unless they follow up and keep up with the host platform. This is the biggest pain point with Clojure for me, the java interop has some limitations that we could not come by.

Re: Clojure 1.11 planning

#19
post #12
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.

That is true for guest languages designed to overcome specific issues in a given language (think CoffeeScript vs. JavaScript in 2012 and then in 2019). But I don't think it really applies to Java vs. Clojure, which both pretty much force a specific (different) programming paradigms and have completely different design.

True but you need to access the libraries in Java. That is a little bit hard in some cases.

Re: Clojure 1.11 planning

#20
post #11

Earlier quoted context omitted.

Clojure is a different language. Being "fully compatible" with (more similar to) Java was never a goal.

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
Post reply on HN