I do not have an idea of what the final end point will look like exactly. I don't get the feeling that there is any answer that you will find satisfying, so I'm not sure what else I can do for you. We expect Clojure users to become familiar with spec and its output as it is (now) an essential part of the language. You will see specs in error messages.
The focus in Clojure has always been biased towards building a powerful and expressive tool that is rewarding for experts vs optimizing for novices. Rich has talked at length about why that is (see https://www.infoq.com/presentations/design-composition-performance-keynote / https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/DesignCompositionPerformance.md in the section around languages as instruments). Pertinent bit (but you should watch the whole thing for context): So we need players. I would rant here, but I won't. But look at this guitar player with blisters. A harpist has blisters, a bass player with blisters. There's this barrier to overcome for every musician. Imagine if you downloaded something from GitHub and it gave you blisters. [Audience laughter] Right? The horrors! And yet how many people here play an instrument or have at one point in their lives? Yeah, a lot of programmers do. And for how many people did you just pick it up and it was awesome? How many wished, like, something could have made it more straightforward to get started with and, like, just made it easy? And how many would have believed after that that they could play it later? No, not at all. This is - it's actually quite important. The level of engagement that's required is quite important. So we shouldn't sell humanity short. Humans are incredible. In particular, they're incredible learners. One of the things that's really cool is you give a five-year-old or, I don't know, eight, maybe, a cello and some decent instruction, and they will learn how to play cello if they spend enough time doing it. In fact, humans will pretty much learn how to do anything that they spend enough time doing. We're incredibly good at it. And we're also really good teachers, in general. So I don't think we need to go to our tools and our instruments and make them oriented towards the first five seconds of people's experience because that's not going to serve them well. It's especially not going to serve anyone well who wants to achieve any kind of virtuosic ability with the tools. No one would become a virtuoso on the cello if they had red and green lights when they started. So neither of these two things is effort free, but we shouldn't be in a game to try to eliminate effort because we are novices, right? There's a sense in which we're only going to briefly be novices. You're only a complete beginning at something for an incredibly short period of time, and then you're over it. It's like we should not optimize for that. But, on the flipside, we're always learners no matter how much time you spend on the violin. Who sits there and says, "I'm done. I've completed learning violin. I finished it"? That's awesome. I personally don't play violin at all, but I don't think there would be a player on earth, no matter how great they are, who would say, "Yeah, I finished violin and I moved on to something else." We're constantly. It's just the human condition to do this. Things take effort. Just like we shouldn't target beginners, we shouldn't try to eliminate all effort. ...and there's more there - it's really worth reading/watching the whole thing. We are not apologetic about this bias. We expect you to engage and learn this tool that you're going to use for serious work because there's also deep payoff on the other side, just like learning to play the guitar or is more rewarding than learning to play the kazoo. I'm absolutely not talking about making something hard on purpose and I'm not saying that making things easy to learn is bad. I'm stating an ordering of priorities. It's more important to us to build a system of many parts that can be composed together into specifications that work as validators, and conformers, and sample generators, and error explainers, etc. We *also* want the automatic errors created from that to be useful and helpful and understandable thus this is a WIP. But creating error messages that are optimal for a user with no knowledge or Clojure or spec is just not the goal. Elena Machkasova has been doing research (supported in part by Cognitect) on figuring out what totally new users of Clojure need from error messages for her CS education classes and the answer there is just different from what an experienced user needs. That's ok. We care more about the latter. On Tuesday, August 23, 2016 at 8:49:38 AM UTC-5, Brian Marick wrote: > > > On Aug 22, 2016, at 7:50 PM, Alex Miller <a...@puredanger.com> wrote: > > > You've complained in other channels about the "learning to read" error > messages part and I think you've taken it entirely the wrong way or maybe I > just disagree. There are benefits from reporting errors in a generic, > consistent way. […] > > > Do there exist examples of what is desired for error messages in > 1.9-final? Not promises, but a “this is what we’re shooting for”? What > would you all like the specific error messages complained about in this > thread to look like? > > Colin Fleming wrote: "The error message produced by the code I demoed at > the conj last year would be: > > Unexpected symbol 'require' at <exact error location> while parsing > namespace clauses. Expected :refer-clojure, :require, :use, :import, :load > or :gen-class.” > > Is that the goal? I fear that the goal is that it should be my job to > understand "(cat :attr-map (? map?) :clauses > :clojure.core.specs/ns-clauses)”. For what little it’s worth, I consider > that completely unacceptable. > > - Getting the error data (specifically the explain-data output) to be both > sufficient and generically useful is the first priority. I think at this > point that's pretty close and unlikely to change significantly. > > > My bias here is that I come from the learned-from-bitter-experience > tradition that believes it’s very risky to (1) get the infrastructure > right, and then (2) pop down the user-visible features on top of it. Very > often, the infrastructure turns out to be a poor match for the actual needs > of the features. But, since (1) is already done, the features - and > consequently the users - suffer. > > Please understand I’m not being insulting when I say that everyone has > weaknesses and blind spots, even undoubted geniuses. In Clojure, error > messages and documentation (especially doc strings) have long been glaring > weaknesses. So I am wishing to be helpful when I counsel *quickly* getting > to worked examples of output, especially output that novices are likely to > encounter. And exposing those messages to typical users, ones who are not > familiar with core.spec. > > That seems prudent. > > I believe strongly enough in good error messages that I would be willing > to do some of the scut work, if needed. > -- 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.
