This elegantly solves the problem of macros such as ns which are pretty complex and require a great deal of effort to parse. There should be another announcement later this week about applying this validation structure to macros. Noises have been made about all of clojure.core getting specs, and users being able to turn on specs “everywhere” for better errors at some performance hit.
It’s nice that this provides an “out of the box” standard for talking about the structure of data produced and consumed without having to take on a dependency such as prismatic/schema or worse roll an internal equivalent to any of the above.
That spec provides some destructuring/parsing “for free” is really handy, and will play nicely with other things.
That spec can hook into clojure.test and has data generators is really neat. EDIT: @tbaldridge informs me that test.check is out of the box. I was wrong..
The bad:
Really. You can’t write about a dynamic contracts system without making digs at static type systems. Sigh.
This doesn’t do anything to deal with Clojure’s existing woes around hinting (using and making explicit JVM types).
Not sold on having keys specified separately from their values. That I’ll have to play with.
No attempt is made to statically verify that specs “flow” (as they would if they were types), instrumentation/validation seems like it’s gonna be entirely user specified with all the pain that can bring.
We’re getting a new reader macro
Applying specs to fns isn’t the greatest thing ever. From @puredanger on HN:
As I understand it, this exists pretty exclusively to simplify the spec stuff, and whatever the final application of the spec stuff to macros is scheduled for later this week.
Namespaced keywords have always been a little clunky to me. There’s some kernel of something good in there, but I’m not quite sure I understand all the nuances or tradeoffs to it. Curious to see if spec and/or this reader macro causes a spike in namespaced keyword usage for things other than spec. Double curious to see what that actually means for Clojure programs.
I don’t think it’s very nuanced - namespaced keywords give you a global naming scheme, which is good as a key for other things. CLJ-1910 (and CLJ-1919 for namespaced key destructure) will remove most of the duplication of namespaces that make them more annoying to type (in the keyboard sense).
Additionally, we are evaluating a change to allow namespace aliases to refer to non-existent namespaces so that you could declare aliases there for keywords or symbols, purely for naming purposes. This would also ease another pain point around pervasive use of namepace aliases.
We don’t (and couldn’t) live in a world where we can’t make mistakes. Instead, we periodically check that we haven’t. Amazon doesn’t send you your TV via a UPS<Trucks<Boxes<TV>>>. So occasionally you might get a microwave, but the supply chain isn’t burdened with correctness proof. Instead we check at the edges and run tests.
I work in Ruby. Not only are we not burdened down by the obligations of ensuring correctness, we have a two drink minimum.
The good:
nswhich are pretty complex and require a great deal of effort to parse. There should be another announcement later this week about applying this validation structure to macros. Noises have been made about all ofclojure.coregetting specs, and users being able to turn on specs “everywhere” for better errors at some performance hit.prismatic/schemaor worse roll an internal equivalent to any of the above.clojure.testand has data generators is really neat. EDIT: @tbaldridge informs me thattest.checkis out of the box. I was wrong..The bad:
Where?
http://dev.clojure.org/jira/browse/CLJ-1910
As I understand it, this exists pretty exclusively to simplify the spec stuff, and whatever the final application of the spec stuff to macros is scheduled for later this week.
Namespaced keywords have always been a little clunky to me. There’s some kernel of something good in there, but I’m not quite sure I understand all the nuances or tradeoffs to it. Curious to see if spec and/or this reader macro causes a spike in namespaced keyword usage for things other than spec. Double curious to see what that actually means for Clojure programs.
I don’t think it’s very nuanced - namespaced keywords give you a global naming scheme, which is good as a key for other things. CLJ-1910 (and CLJ-1919 for namespaced key destructure) will remove most of the duplication of namespaces that make them more annoying to type (in the keyboard sense).
Additionally, we are evaluating a change to allow namespace aliases to refer to non-existent namespaces so that you could declare aliases there for keywords or symbols, purely for naming purposes. This would also ease another pain point around pervasive use of namepace aliases.
I work in Ruby. Not only are we not burdened down by the obligations of ensuring correctness, we have a two drink minimum.