Clojure 1.11 planning
insideclojure.org
Clojure 1.11 planning
1–10 of 72 posts
Re: Clojure 1.11 planning
#2Clojure had kept the core lean and simple and has grown through the years with libraries for features like spec. It makes the language as a whole stable with features developed and tested like spec being a library in alpha.
Re: Clojure 1.11 planning
#3I 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 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.
Re: Clojure 1.11 planning
#4I 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…
One use case is API input validation.
Re: Clojure 1.11 planning
#5I 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…
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 route tree and specs, including samples of input and output for all routes.
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.
Re: Clojure 1.11 planning
#6Cool, cool. When is full compatibility with Java 8 be available? I mean Java 8 SAMs, Java 8's Stream, Optional and CompletableFuture...
Re: Clojure 1.11 planning
#7Cool, 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.
Re: Clojure 1.11 planning
#8Spec 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)
Re: Clojure 1.11 planning
#9I 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…
You won't necessarily have to use it directly to reap benefits from it. API authors can use it to provide you with excellent error messages which pinpoint the exact location something is wrong
Re: Clojure 1.11 planning
#10I 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…
We use it extensively as a kind of "incremental typing" - that is, I can assert that what goes in to a function has a given shape and what goes out complies as well. Even in production, the overhead is quite low (think 5% in our use case).