Saw this thread on the REPL, interesting discussion. On Tuesday, October 3, 2017 at 10:57:34 AM UTC-7, Alex Miller wrote: > > > It's not about easier, it's about possible. Open grows, closed breaks. > >
I agree with the broad brush, but it's important to listen to this usability feedback before releasing an important feature like Spec. As an aside, seriously great work with Spec; it's the biggest thing Clojure was missing for institutional support I think. At Google, we use Protocol Buffers <https://developers.google.com/protocol-buffers/> heavily to achieve some similar goals to Spec, and I think there are good lessons to look at. Like you said, the spec (whether proto or capital-s Spec) needs to be forwards compatible across distributed clients if it's going to describe data in an useful way as the project evolves. Protos achieve that by convention - best practice recommends fields are always optional and the type can never change - and technically by always accepting unknown fields. Where they differ highlights the pain points that people in this thread mentioned. - Protos cannot be created with extra fields, so there's nothing like the sanitizing issue puzzler mentioned. The generalization is to strictly specify the output of a function/system, but gracefully handle input. This makes me think there should be something like a s/conform-strict function that coerces data to only the Spec'd keys, and ensures keys are defined. - Protos specify the type of a field along with its name, and both are checked at compile time, so there aren't the late-caught errors like the OP pointed out. Rich has good reasoning for wanting to re-use keys, but typically the solution is to create a named composite type (a message in proto terms) that is trivial to re-use as a field type. The idea of specifying keys separately is different from how literally every type system does things, so it's inherently not "easy" in Rich's definition of being mentally at hand. That's going to create pain for people learning the tool. You should strongly think about ways to reduce that friction. Protos describe a strictly specified open message, which doesn't neatly fit in your categories or open or closed. It's an important technical precedent to think about though. -- 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.
