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/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 <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.
