Hacker News Reader

Comment by logistark | Hacker News Reader

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

View on HN

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.

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 practice, you wouldn't. You'd import at the top of the file, then type `Stream/of` instead of `java.util.stream.Stream/of`.

I almost never use Java directly though because there are so many great Clojure wrappers.

In Clojure that's:

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

so no Java Function to clojure Function automating mapping ? do people use macros to make it nicer ?

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

Not out of the box, probably because java.util.function.Function seems like an afterthought in a strictly object-oriented language while Clojure has first class functions. In practice you don't interop with Java very much, let alone functional Java (as Clojure itself is a much better fit). But if it was useful, it'd be easy to write helpers for converting functions back and forth.

functions. Macros are a super weapon and their use is reserved for very special cases. One reason is macros can't be composed as functions and also readability goes out the windows.

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.

Has been a long topic of conversation trying to figure out the best way to do some of these while also retaining best performance, etc. High in our list of candidate things to work on!

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.

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

I find that I tend to do very little interop nowadays, and it predominantly happens at the edges with things like database drivers, and so on.

Yes most of the things just work.

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.

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.

I'm looking at the docs -- is there a guide for targeting new host langs? As a starting point, what is the minimum "core" language that needs to be defined in the host lang so that the rest of the system can be bootstrapped by Clojure libs? (Clojure.core doesn't seem to be the answer -- there seem to be plenty of non-core/prim functions defined there.

Also, are Clojure libs (either automatically or via attribute on the package) flagged as "pure" (Clojure-only) vs. needing imports from a specific host lang?

Yes, the special forms.

https://clojure.org/reference/special_forms

Clojure follows the Lisp convention of providing platform specific behaviour via the reader.

https://clojure.org/guides/reader_conditionals

Not sure I follow -- there are certainly many primitives that must be defined by the host to bootstrap that are not special forms -- starting with list, cons/conj...

I doubt there’s a guide anywhere: it’s far from a trivial undertaking. If you want to look at the Java code that builds all the primitives, see the Clojure/Lang folder:

https://github.com/clojure/clojure/tree/master/src/jvm/cloju...

Part of what makes it Clojure instead of just a Java-based lisp are the persistent data structures that allow for efficient immutability, and the seq interface for working with collections smoothly. There’s a big (scary, to my eyes) set of classes that underlies all of the convenience. Thankfully it’s very stable so I don’t have to think about it.

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.

Clojure already has equivelent or better stuff to do the same thing. And you can still use it if you like.

Big pain point, Java 8 was release in 2014, and the java.util.Function interfaces have become very common in practice since then. Clojure is really dying...

I think it's because Clojure itself has been offering a better alternative to streams for years.

And let's be honest: @FunctionalInterfaces are a compiler hack, since Java doesn't really have functions.

And what I simply love about Clojure:

If writing (reify java.util.Function (apply [this arg])) is too verbose, roll your own macro or function. You could also add a tagged literal.

Oof, every single Clojure related HN post, there's always at least one person claiming that Clojure is dying. Clojure is not dying! Look around, Clojure today has more conferences, meetups, podcasts, jobs, and books. More than any of non-mainstream languages. More than Haskell, Elixir, OCaml, Elm, Rust.

I'm sorry for snapping at you. It just makes me sad to have to fight unwarranted skepticism all the time. People throw opinions out of the blue, sometimes without even considering a heartfelt attempt to try things out first.

Evangelizing for Clojure has become a moral issue. Just like arguing with gun-control, climate change opponents, and anti-vaxxers. No matter what arguments you bring to the discussion, those who don't want to listen - just wouldn't.

You say: "Clojure is very pragmatic",

They'd be: "I don't want to learn Emacs".

You say: "But you can use VSCode, Atom, Eclipse, Vim, IntelliJ to write Clojure",

They: "Too many parentheses..."

You say: "Other languages have more, and a bunch of other things like semicolons, commas, curly braces, and operator precedence rules... "

They: "But it's not statically typed"

You say: "It has Spec. Spec can do things, most type systems cannot"

They: "But I don't like JVM..."

You say: "JVM is a very robust, solid piece of tech..."

They: "Clojure is dying..."

---

Honestly, I don't understand this tribalism. Like people really don't want it to succeed. It isn't some zero-sum game - the success of one language ecosystem does not mean there's less pie for others. There are many things in other languages - Rust, Elixir, Javascript, etc. directly inspired by how they first were done in Clojure. Just think about it: Cognitect has a team of fewer than fifty developers, and the Clojure community has no more active members than engineers working for Google, yet there's a constant pace of innovation for the entire CS community. Maybe the language has something to do with that, after all?

Reply on news.ycombinator.com