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