Hacker News Reader

Comment by roenxi | Hacker News Reader

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

View on HN

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.

I remember spec being pitch for something you only use at dev time and turn off in production because it makes your runtime very very slow, what has change? Seems users are using it for everything now.

No. It was always designed to be configurable so you can keep on the API endpoints, but deactivate them internally.

We don't have instrumentation in production, ie. we spec much more at dev time. But for things you'd validate anyway spec is a good match and probably about as performant as hand-written validation.

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.

I bet you are thinking of https://clojure.org/guides/spec#_instrumentation_and_testing - it was always just one use of spec among many.

Spec has numerous uses. We use it heavily in production for data validation/conformance: https://corfield.org/blog/2019/09/13/using-spec/

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.

Raitit (rye-tit) is a Finnish word too: the plural of "a lone village road splitting the village in half".

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

It's more like "ray-tit". A colleague at Metosin came up with a good alternative: "rate it!" Used in sentence like "I reitit 5 out of 5!"

It's a Finnish word. Google Translate's text-to-speech is pretty decent - click the speaker icon on the left: https://translate.google.com/#view=home&op=translate&sl=fi&t...

Thank you!

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.

But there are certain undeniable benefits of static typing that you miss out on: documentation, and IDE hints.

And performance.

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

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.

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

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

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.

One use case is API input validation.

Reply on news.ycombinator.com