https://github.com/metosin/malli

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 something to this spec if it warrants a v2. It just isn't obvious whether it solves my problems, library maintainer problems or professional problems. It is very different to the immutable-everywhere design where a Clojure beginner is forced in to understanding it to even try trivial experiments.

Similarly you can do HTML form validation, etc.

We even use honeysql with nice helper functions that ensure that data-changing SQL queries are of the expected form. Say, you want to update just one row, you have a helper function that checks the honeysql data has a where clause with a unique column and only then runs the query. Someone should maybe blog about that sometime.

What I've found, though, is that trying to use spec like type checking is usually not a great idea. I expect better from static analysis / compile-time checking, with clj-kondo being the most promising tool atm.

The only strange use of spec I mentioned is validating db queries. For us updates and deletes are rare enough that perf doesn't matter.

Would make a nice library name. Wonder if Metosin takes requests...

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

And performance.

- 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.

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.

They just got a round of funding this year, and they've got several good talks posted on their homepage about the quirks of working on .NET.

[0]https://github.com/arcadia-unity/Arcadia

Godot is a decent OSS alternative to Unity, but no Clojure/Lisp so far as I know :(

And somebody made Arcadia bindings for Godot [2], but the project isn't actively maintained. Would be great if somebody picked it up again.

[1] https://www.youtube.com/watch?v=LbS45w_aSCU [2] https://github.com/arcadia-unity/ArcadiaGodot

https://github.com/godotengine/godot/issues/24890

  ; 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]

    (map #(* % 2) [1 2 3 4 5])

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

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

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?

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

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 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.

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?

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.