A suggestion for making all errors better would be to give not only the precise file and line _of the beginning of the top level form containing the problem_, but a more precise line and column of _the part of the form that spec is complaining about_. Multi-line forms are the biggest and hardest to figure out which part spec is complaining about.
Andy On Wed, Aug 24, 2016 at 6:39 AM, Stuart Halloway <stuart.hallo...@gmail.com> wrote: > Brian originally raised 5 points that were concrete & specific, and > therefore potentially actionable. That is usefully-shaped feedback, thanks > Brian! My take on those points, which I will recast in my own words: > > 1. "Loosen rules about ns form to match what people have actually done." > This is pretty unlikely, for reasons already covered. > > 2. "You can tailor a much better specific message for 'require should be a > keyword' than what spec makes today." There are several possible things to > explore here. The most interesting one is "can spec come closer to a > bespoke message while maintaining its simplicity and composability?" We > want to make all errors better, not one error awesome. Ideas welcome! > > 3. "Follow the inverted pyramid so people see what is most important." > This kind of thing is easily done in a layer above spec, e.g. a custom > REPL printer for spec macro errors. Worth working on but not critical to > getting spec right. > > 4. "Name the problem namespace." Spec does way better than this already, > finding the precise file and line. If there are places where this is > busted we should fix them. > > 5. "I don't want to see the stack trace." Then filter it out of your > REPL. Intermediaries should never discard telemetry, but end consumers can > choose to. > > Cheers, > Stu > > > > On Wed, Aug 24, 2016 at 5:57 AM, Colin Fleming < > colin.mailingl...@gmail.com> wrote: > >> Sure, at the end of the day I don't really care about thre >> require/:require issue, it just seems a little incongruent with previous >> decisions which have promoted backwards compatibility. I generally prefer >> increased strictness, so I'm fine with the change. I do care about the >> error messages, though. >> >> On 24 August 2016 at 21:32, Mond Ray <mondraym...@gmail.com> wrote: >> >>> I agree Colin, this feels more like the beatings shall continue until >>> morale improves ;-) >>> >>> More seriously, I understand the point of the musical instruments >>> analogy to be a reminder to programmers that learning a language and >>> understanding it in depth will increase your power and expressivity with >>> that language. That should not be used as a reason to increase the >>> difficulties caused by obscure error reporting. My initial understanding of >>> the sales pitch for specs was that it would serve to improve error messages >>> as the macro expansions / transformations would be more tractable in the >>> compiler. I get that it is a work in progress but let's retain that >>> original goal. >>> >>> Unlike you however, I would prefer correctness and the consequent >>> ripples over the continuing acceptance of incorrect expressions. My >>> reasoning is that code which has fewer compatibility style branches will be >>> easier to equip with the necessary instrumentation for generating more >>> human friendly error messages. >>> >>> Ray >>> >>> PS I think this require vs :require thing comes from the way that >>> novices confuse the ns macro with the function that pulls dependencies in >>> at the REPL. Cutting / pasting between the REPL and the file can allow that >>> to bleed in. I know it confused me. >>> >>> On Wednesday, 24 August 2016 01:09:48 UTC+2, Colin Fleming wrote: >>>> >>>> But creating error messages that are optimal for a user with no >>>>> knowledge or Clojure or spec is just not the goal. >>>> >>>> >>>> This is a totally false dichotomy. No-one in this thread is asking for >>>> that. This thread has several examples of expert Clojure users for whom the >>>> error messages are incomprehensible. >>>> >>>> I am equally unapologetic about thinking that the musical instrument >>>> analogy is mostly bogus here. There are things that will always be >>>> difficult about learning Clojure because they're conceptual, such as >>>> functional programming. I think the analogy is fair there, they are just >>>> things that will require effort and practice to learn. But the error >>>> messages are about giving people the information they need *so that >>>> they can actually learn from their mistakes*. Clojure has historically >>>> been appallingly bad at that, and no-one should expect their users to flail >>>> around randomly trying things to see what works. I've spoken to various >>>> smart people who have described their experience of using Clojure as >>>> exactly that, even after a non-trivial amount of time using it. I hope spec >>>> can improve on that experience. >>>> >>>> >>>> On 24 August 2016 at 02:45, Alex Miller <al...@puredanger.com> wrote: >>>> >>>>> 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-perfo >>>>> rmance-keynote / https://github.com/matthiasn/t >>>>> alk-transcripts/blob/master/Hickey_Rich/DesignCompositionPer >>>>> formance.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 <al...@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 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. >> > > -- > 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.
