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.

Reply via email to