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