> > I’d be very wary of any claim that the performance overhead of “keeping > instrumentation on fully” is “small” in the general case. >
I wonder if we're eventually going to start seeing some professional instrumentation libraries poping up, which could provide more fine grained control and better performance. On Wednesday, 20 September 2017 13:15:59 UTC-7, Sean Corfield wrote: > > 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 <javascript:> > *Sent: *Wednesday, September 20, 2017 12:40 AM > *To: *Clojure <javascript:> > *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 clo...@googlegroups.com <javascript:> > 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 <javascript:> > 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 <javascript:>. > 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.
