Very useful. So it is a *bit* philosophical :) I guess the unabashedly hosted philosophy is one I wasn't so sure was intentional but it's good to understand; and embracing that changes the way you'd teach or introduce the language. Gotcha. Where I thought I "had to form" a dual mental model and I should have thought I "got to learn" one quickly. Cool!
And yeah lazyness and locality of error is always always hard. I loved elenas talk. At about the 16 minute mark she takes to task exactly the message I picked. Her solution looks tricky for non-instructional uses though, like when she rebinds map. And a big pile of stack regexps is tricky to maintain beyond teaching use cases I could imagine. Anyway, thanks for the links and thanks for the thoughtful answers. I really appreciate it. It has me thinking. Be well, - Paul > On Dec 6, 2016, at 10:54, Alex Miller <a...@puredanger.com> wrote: > > >> On Tuesday, December 6, 2016 at 5:55:52 AM UTC-6, Paul Walker wrote: >> Wow thank you for the fulsome responses >> >> A couple of thoughts. I brashly said >> >> > I cherrypicked a case where the runtime difference would be tiny >> >> and I appreciate the clarifications - especially that my naive >> add-one-bytecode calculation in my head (the code I pasted has a pretty >> meaty “analyze” call called before it every time which is why I thought I >> cherry-picked) didn’t think about things like byte code inlining or, really, >> the pile-of-sand one-more-bytecode syndrome. So thanks for that! > > I think in the case you picked that you're right that the performance impact > is minimal. This happens at compile-time and generally we are less sensitive > there than in calls during the runtime. Colin's talk from last year's conj > gives a good idea of some of the challenges in working on this stuff. > https://www.youtube.com/watch?v=kt4haSH2xcs > >> And my favorite response from Alex: >> >> > If I can make a request, it would be that instead of saying "errors are >> > bad" (which is honestly, not helpful by itself), but to step back and >> > either take a broader approach towards systemic issues >> >> This is so reasonable I’m embarrassed I was a bit glib in my first note. I >> mean it’s not like they are C++ template errors from 1998 (my gold standard >> for bad errors). So let me expand on “bad” a little. >> >> I think the error messages are “bad” in 3 particular but related ways. I’d >> be happy to expand on these, but the themes are: >> >> 1: They are “large” and “far from my code”. This is partly an issue with >> java stack traces, but the intermixing of java and clojure and the >> presentation of clojure names in java name-like things in the stacks is >> obscuring. The line numbers are obscured instead of displayed prominently. >> And so on. > > Personally, I don't have a problem with stack traces - there's a ton of > useful information in a stack trace. The issues of "distance from code" are > interesting in Clojure though. One area I mentioned is due to errors in > macros where it reports either the error in the macro rather than in the > source OR where you get a runtime code that is based on code that was written > by the macro (not by you). The first problem is significantly improved by > spec. Another source of "distance" is laziness - sometimes a nested operation > will not error until a lazy seq is forced, possibly far from the core of the > problem. Eager transformations (we have more options for this now with > transducers) can help with that, as can spec in reporting more accurately the > error when it occurs. > >> 2: Similarly, they expose internals of the runtime implementation to the >> user. Stacks intertwine java and clojure (CIDER error screen has a toggle to >> supress the stack partially for this). They show java exceptions as clojure >> errors when they aren’t part of a clojure program. etc… > > Again, Clojure is an unapologetically hosted language. There is no desire to > hide that fact or to shield you from it. That means that learning Clojure > inevitably means learning something about the JVM or Java as well. > >> 3: These, plus a few other things, mean the error messages are semantically >> far away from the program you write. You stay happily in LISP-y land until >> you get a stack, then you realize you are in java. There are lots of >> examples of this, but take the dumb one I picked - (1 + 1) in a REPL. That >> shows two concepts (java.lang.Long and clojure.lang.IFn) which you don’t >> deal with in lisp. I’ve written quite a lot of clojure in the last 5 months >> and never typed clojure.lang.IFn once. It’s a java error message but I’m a >> clojure programmer. Instant semantic break. And since many error messages >> are generated at the runtime level, which is java / JVM, I experience this >> semantic break often. Add the excellent comments in this thread on macro >> expand non-locality of error and the problem expands. > > I get this and it's unfortunate when it exposes to you more than you need to > know initially. But at the same time, I think developing that knowledge is > essential to make the best use of Clojure in the long term. > >> So if you imagine a guide like “the error should be as close to the error >> causing code as possible and presented in the semantics of the problem” then >> I think I conclude clojure messages are “bad”. (But I love clojure) >> >> It seems spec, inasmuch as it acts as a sort of optional type system which >> is in the space of the clojure language and produces information in that >> space, would address many of these. >> >> And as to why I mentioned this: I mean I haven’t had a problem. I just built >> a dual mental model of clojure and the clojure runtime while I learned the >> language and swapped between when an error popped. > > That seems like a good thing to me. :) > >> And I’ve written a lot of java (and interpreters and compilers too) so that >> was easy enough for me to do. And I have been hugely productive in your kit. >> I love clojure! >> >> But indeed for teaching it’s an obstacle, but also for teaching’s adjacent >> problem, using a language or toolset in a group of programmers of mixed >> abilities, I was thinking errors would be something I’d improve. > > There are some interesting gradations even in this depending on whether > you're talking very new programmers, or experienced programmers new to > Clojure, or experienced *Java* programmers new to Clojure, etc. Elena > Machkasova has been working through how to present Clojure error messages for > new developers at U of Minnesota. An older talk on this is at > https://www.youtube.com/watch?v=k5erDyDPzgc. Elena has actually done some > user studies on this as well (which Cognitect funded). I don't think she > would say that this work is appropriate for all Clojure developers though. > >> But really, it seemed like a place I could lend a shoulder if work was >> afoot, so the comments on the ticketing approach are appreciated and I will >> dig into them. >> >> Thank you for your rapid and thoughtful responses >> >> - Paul >> >> >>> On Dec 6, 2016, at 2:56 AM, Mars0i <marsh...@logical.net> wrote: >>> >>>> On Monday, December 5, 2016 at 10:36:59 PM UTC-6, Sean Corfield wrote: >>>> Several of the Clojure/core folks have said at various times over the >>>> years that Clojure is deliberately not optimized for novices, on the >>>> grounds that whilst everyone starts out as a novice, most of your time >>>> spent with Clojure is beyond that stage (and an optimization for novices >>>> can be a de-optimization for everyone else). >>> >>> This makes sense for anyone with significant programming experience. It's >>> a shame, though, that Clojure would be a great language for novice >>> programmers except for the error messages, which are probably a >>> show-stopper for some p teachers thinking of using it for teaching. I know >>> that there are people involved in Clojure Bridge and other teaching >>> programs, but as a teacher (in another discipline), I personally would have >>> a hard time choosing Clojure over Scheme at this point, if I was teaching >>> an intro programming course. Clojure's probably a better language for >>> later growth though, given its easy integration with Java and Javascriptl. >>> >>> I'm not arguing for a change. I like run-time performance, too. Spec >>> messages are not any good for novice programmers, either, but I'd guess >>> that down the road it will be possible to build a friendly error system on >>> top of spec. Can't do that as easily with JVM stacktraces. :-) >>> > > -- > 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 a topic in the Google > Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/ANKq6XD1nW8/unsubscribe. > To unsubscribe from this group and all its topics, 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.
