6 ms·

When the canonical example of an fdef takes significantly more code than the function itself, I think you have to re-evaluate your approach: https://clojure.org

When the canonical example of an fdef takes significantly more code than the function itself, I think you have to re-evaluate your approach: https://clojure.org/guides/spec#_specing_functions https://clojure.org/guides/spec#_specing_functions

tekacs 7y ago
Hm the /amount/ of syntax isn't something I think about I guess, this being a Lisp. I think they've taken the approach of making the system thorough and capable and this being a Lisp, we users can skin it with any level of shorthand that we please. Datomic (the database from Cognitect) has a similar approach with its schema, which is quite verbose, but many folks that I know tend to simply write a function which spits out the schema, since it's 'just data'. I tend to use Ghostwheel [1], but there's also spec-tools [2] and others. [1]: https://github.com/gnl/ghostwheel https://github.com/gnl/ghostwheel [2]: https://github.com/metosin/spec-tools https://github.com/metosin/spec-tools
- keithasaurus 7y ago
  Schema is a pretty nice alternative: https://github.com/plumatic/schema https://github.com/plumatic/schema
- peferron 7y ago
  spec.alpha is implemented as a bunch of macros that make it difficult to work with spec forms as if they were "just data". This is one of the issues that spec-alpha2 tries to address [1]. Sure, you can import libraries to try to work around it but that's hardly ideal. [1] https://github.com/clojure/spec-alpha2/wiki/Differences-from-spec.alpha https://github.com/clojure/spec-alpha2/wiki/Differences-from...
andreareina 7y ago
That seems an unfair criticism, most of that fdef is about the relationship between the args/return as opposed to just the types.
- keithasaurus 7y ago
  Perhaps. I was trying to find something pithy to give as an example. It's difficult to express all the things about spec that feel off to me. I'll try to enumerate some: - verbosity (I think schema does this better https://github.com/plumatic/schema https://github.com/plumatic/schema) - because it tries to not be about validating types of inputs and outputs, and rather treats everything as predicates, it tends to live in a grey area between type validation and unit-testing, and I think hinders both - it only helps at run-time - over-abundance of macro-usage
  - thom 7y ago
    I suspect what you consider a 'gray area', spec considers the whole point. What is the specification for this function? It has a signature and a return value and some behaviour in between. Spec verifies all of that together because it doesn't make sense to do it separately. Also I'm not sure what you mean about run-time, you can and should use spec as part of your development workflow. Other two points are totally fair though, and the macros are part of the reason it never got out of alpha before a rewrite.
  - andreareina 7y ago
    Fair. I find that I naturally tend to think about the general properties of argument/return values and not just the types (or perhaps equivalently expand the meaning of "type" to encompass such usage) so I like the design, but I haven't yet used spec in anger and so might yet change my mind.

tekacs 7y ago

Hm the /amount/ of syntax isn't something I think about I guess, this being a Lisp. I think they've taken the approach of making the system thorough and capable and this being a Lisp, we users can skin it with any level of shorthand that we please. Datomic (the database from Cognitect) has a similar approach with its schema, which is quite verbose, but many folks that I know tend to simply write a function which spits out the schema, since it's 'just data'. I tend to use Ghostwheel [1], but there's also spec-tools [2] and others. [1]: https://github.com/gnl/ghostwheel https://github.com/gnl/ghostwheel [2]: https://github.com/metosin/spec-tools https://github.com/metosin/spec-tools

keithasaurus 7y ago
Schema is a pretty nice alternative: https://github.com/plumatic/schema https://github.com/plumatic/schema
peferron 7y ago
spec.alpha is implemented as a bunch of macros that make it difficult to work with spec forms as if they were "just data". This is one of the issues that spec-alpha2 tries to address [1]. Sure, you can import libraries to try to work around it but that's hardly ideal. [1] https://github.com/clojure/spec-alpha2/wiki/Differences-from-spec.alpha https://github.com/clojure/spec-alpha2/wiki/Differences-from...

andreareina 7y ago

That seems an unfair criticism, most of that fdef is about the relationship between the args/return as opposed to just the types.

keithasaurus 7y ago
Perhaps. I was trying to find something pithy to give as an example. It's difficult to express all the things about spec that feel off to me. I'll try to enumerate some: - verbosity (I think schema does this better https://github.com/plumatic/schema https://github.com/plumatic/schema) - because it tries to not be about validating types of inputs and outputs, and rather treats everything as predicates, it tends to live in a grey area between type validation and unit-testing, and I think hinders both - it only helps at run-time - over-abundance of macro-usage
- thom 7y ago
  I suspect what you consider a 'gray area', spec considers the whole point. What is the specification for this function? It has a signature and a return value and some behaviour in between. Spec verifies all of that together because it doesn't make sense to do it separately. Also I'm not sure what you mean about run-time, you can and should use spec as part of your development workflow. Other two points are totally fair though, and the macros are part of the reason it never got out of alpha before a rewrite.
- andreareina 7y ago
  Fair. I find that I naturally tend to think about the general properties of argument/return values and not just the types (or perhaps equivalently expand the meaning of "type" to encompass such usage) so I like the design, but I haven't yet used spec in anger and so might yet change my mind.