The power offered by spec is probably better compared against dependent type systems like Idris. True static type systems run analysis at compile-time, but spec allows you to perform very complex checks because you have the power of full blown language.
For example, with spec you can write a function spec that says "Union is a function that takes two hashsets. The return value of this function is a hashset that contains all the values found in the hashset arguments". That's impossible to statically check in most languages. Some languages like Idris approach this level of expressibility, but when they fall short, you're sunk. In spec you can always pop the escape hatch and write a custom predicate in Clojure code. So for me that's the tradeoff. I loose compile-time checking, but gain a *ton* of power. And since types exist at run-time we can do cool things like introspect them and generate data, documentation, better error messages, or even run logic over them to write a static type checker. On Thu, Apr 6, 2017 at 2:57 PM, Jeaye <cont...@jeaye.com> wrote: > On Thu, Apr 06, 2017 at 01:47:17PM -0700, Raoul Duke wrote: > > I am writing to ignorantly sincerely ask how spec + Orchestra compares to > > other statically typed out of the box JVM languages. What are the succint > > wins over not Scala shudder but eg Kotlin Ceylon, heck Frege, et. al.? > > clojure.spec validates data at run-time. spec's instrumentation, and thus > Orchestra's, checks function arguments, return values, etc _when the > function is called_, not during AOT compilation. > > In contrast, a static type system would catch theses errors before the > program itself even runs. In my opinion, clojure.spec + Orchestra still > falls quite short of a static type system, but it's the best setup I've > seen for automated data validation as it moves through all parts of your > Clojure programs. Even in languages with static type systems (C++, even), > you almost certainly won't get automatic validation of the data, for each > function call, return, etc, given only a declarative spec. In that way, > clojure.spec alone provides something of great value. > > Aside from that, you're talking about the gains of Clojure versus all of > those languages you listed. That's not related to Orchestra and would > likely be better answered by people more knowledgeable than me. > > -- > 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. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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.
