Hi Beau, Yes. Nevermind and everyone should learn to read spec. :-)
That said, such customizations allow people to experiment and flesh out a bunch different ideas in parallel. Best, Stu On Wed, Aug 24, 2016 at 1:17 PM, Beau Fabry <imf...@gmail.com> wrote: > Just specifically on a custom REPL printer, wouldn't that negate the > benefits Alex sees in people becoming accustomed to reading spec error > messages? If every error report from each different environment potentially > looks different? Also, from the position of a community maintainer Brian is > most commonly going to be seeing the lowest common denominator error > messages in bug reports filed, and it probably wouldn't be helpful for him > to be getting multiple representations of the same error in different > reports. > > On Wednesday, August 24, 2016 at 6:39:51 AM UTC-7, stuart....@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.ma...@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 <mondr...@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- >>>>>> performance-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 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 >>> 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.
