And I've also found that a lot of people actually leave their specs in production, with some even keeping instrumentation on fully. It seems that failing fast is often prioritized over the small performance overhead.
Just as a data point, since this was brought up on Slack the other day: if you run a program based on clojure.java.jdbc with the optional clojure.java.jdbc.specs ns loaded and instrumentation on, there is a very noticeable performance overhead – a factor of 3-5x slower for java.jdbc’s test suite for example (which is, naturally, full of calls that get checked). I’d be very wary of any claim that the performance overhead of “keeping instrumentation on fully” is “small” in the general case. Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood From: Didier Sent: Wednesday, September 20, 2017 12:40 AM To: Clojure Subject: Re: Is it wrong that I'm thinking about this? There's a lot of value in separating the specs from the functions. You can put them in different places and only use just the specs (to spec an API for example) or just the functions (for production use where you don't need the specs). And downsides are that it obscures which parts are fn and which parts are spec in the definition, and that there is no place to define the :fn spec. I take from this that there's nothing terribly wrong if I implemented a macro of my own, but I understand that for the core offering, its more flexible to standardize around function specs to be separate. I'm sure I can get creative about where to put the fn spec :p. I was thinking the attr-map could optionally be a spec instead, or contain an :fn key if you want both. Having said that, it does seem to me like a lot of people are struggling with "Where do I put my function specs?", me included. And from my research, most people like to put them right above the function, or right below. So I thought that for most use cases, where you don't want to spec an existing API, this would make it unambiguous. And I've also found that a lot of people actually leave their specs in production, with some even keeping instrumentation on fully. It seems that failing fast is often prioritized over the small performance overhead. Anyways, I'll give it a shot and experiment, see how it goes. I think that sort of thing should be possible, but too opinionated for how 'core' clojure.spec is intended to be. Decisions like that are for application architectures. I think yes, to some extent, but we should also be careful about the Lisp curse. If core has too little opinion, each Clojure code base will be like its own dialect full of secret functions and macros. On Tuesday, 19 September 2017 14:43:53 UTC-7, Gary Trakhman wrote: I think there's the spec is a 'side-band' system (well except we want to the compiler to know about it for macros) design constraint, but additionally, I think it's worth thinking about: Defn right now is primitive enough to be fast and powerful enough for large programs. There are many general and competing things a developer might want to be available in a more powerful or opinionated defn, but I think we'd agree the benefit of what you propose scales as a convention across a larger codebase and so do other general defn wrappers. I can think of a few other examples like this, how about plumatic's defnk graph function macro? How about core.match pattern-matching with the 'defun' project? How about the schema s/defn? How would someone combine them when macros generally don't compose too well? I think that sort of thing should be possible, but too opinionated for how 'core' clojure.spec is intended to be. Decisions like that are for application architectures. On Tue, Sep 19, 2017 at 5:29 PM Didier <did...@gmail.com> wrote: I've been thinking since using Clojure.spec fdef that I'd like something like this: (defns foo [x string? y int?] string? forms) Where an s/fdef spec automatically build of this form: (s/fdef foo :args (s/cat :x string? :y int?) :ret string?)) And obviously the foo var and function would also be created. I feel like the core team didn't choose this route though, and so I'm curious why, and if its actually a bad idea? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clo...@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+u...@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+u...@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. -- 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.