So I see Clojure Spec as an "internal DSL if you squint" for describing invariants that are enforced at runtime. Static typing is also an "internal DSL if you squint" for describing data-shape-invariants at compile time. With Clojure Spec you have the entirety of Clojure to describe those invariants, with a static typing lib you are limited to whatever constructs language provides. So Clojure Spec is much more open and extensible in that regard.
<flamesuit> However, I see a lot of people stopping the discussion there without accounting for the fact that you _also_ have the "entirety of language-X to describe those invariants" for any given language. Pre and Post conditions have been around since the dawn of time and most languages (I know about) have asserts. If the language has support for AOP then even better as the description and application of those invariants don't need to be embedded in the code in question. This means that any given language, purely from a "can it enforce this?" is at least as powerful as Clojure Spec. And Clojure Spec's ability to feed the generative testing machine is awesome if you can describe your accepted inputs in that way. So, in terms of "can I express this invariant" in both static and statically typed languages? Yep, of course. </flamesuit> Clojure Spec and static type systems are both tools for enforcing invariants. Can Clojure Spec describe invariants that StaticTypingLanguage-X can't? No, of course not. Is the machinery around Clojure Spec useful - absolutely. I have longed for a statically compiled language with type inference with the simplicity and consistency of Clojure's syntax that also supports generative testing and works on the JVM but alas, I have not found one. Frege and PureScript both look interesting but I am unsure of Frege's longevity and PureScript's performance on the JVM's Javascript environment. On 7 April 2017 at 06:07, Didier <didi...@gmail.com> wrote: > It's different, yet related. > > Static type systems and clojure.spec both try to prevent bugs. They're tools > to help you write correct programs, the same way that a testing framework is. > Neither of them will catch all your bugs unfortunately. > > Static type systems catches bugs where you would try to do an operation over > a type which does not support it. Types are not very precise though, like it > will catch 10/"123", but not 10/0, because the type isn't more precise then > int. So int/int will be ok, but int/string will be caught at compile time as > a bug. > > The advantage of static type systems is that what they do catch, they will > catch 100% of the time and they generally run pretty quickly. > > Clojure.spec catches bugs where you'll try to do something on a value which > isn't acceptable, as well as catch bugs where the relationship between the > input and output values is wrong. So it can catch 10/0 and 10/"123". If a > parameter was true and functionally that means the output should be false, > but a bug causes it to be true instead, well it can also catch that. > > The disadvantage of clojure.spec is that you cannot be sure it caught 100% of > those bugs. It will catch some, but maybe not all. It will also be much > slower to run. > > Now, clojure.spec has one more trick up its sleeves. It can be used for > static analyses on steroids. If you've ever used Find bugs in java, you know > a little what I'm talking about. If you use Spectrum, it will try to catch > some of those same bugs at compile time, and it could in theory be made to > catch 100% of the bugs static type systems catch. Spectrum is new and not > fully featured yet, but so is clojure.spec, so this is a possible future > which you can have a taste for today. I recommend checking it out: > https://github.com/arohner/spectrum > > Alright, that's the part about catching bugs. Now there's more to it. Type > declarations are normally helpful documentation too, and so is clojure.spec. > Spec, once again, can be way more precise in documenting. Similarly, types > can help tooling and error messages, so can spec. > > Finally, spec also allows some things types don't even cover, such as parsing > and validation of non typed data like json. Spec can parse a complex > structure into an AST. It can also validate EDN, or json that was > unmarshalled into clojure. > > As time goes on, I'm sure someone will find other use cases for it too. > > Hope this helps. > > P.S.: Clojure also has a static type system called core.typed. It is not as > widely used though, and has only one developer working on it. It also doesn't > compare to the languages you listed, since it is a gradual type system, more > inline with typescript, typed racket and hack. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
