On Monday, December 5, 2016 at 7:28:21 PM UTC-6, p...@pwjw.com wrote: > > Hi! >
Hi Paul, > > Boy I really think you've all done a nice job with Clojure. I've used > quite a few environments over the years and clojure + CIDER + etc is a > great experience. The immutability and threading are smart. I've been able > to finish a hobby project in clojure which I've been mulling for a long > time and never found the right environment. Super stuff. > > And the error messages are not good. > 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 or to file and work tickets for specific cases/messages, so they can actually be fixed. > So I was wondering: Is this a philosophical thing? > There is certainly no philosophy that errors should be bad. I would say that the state of things right now is more a side effect of prioritization and choices over many years. Rich's focus has typically been on building powerful expressive tools vs the beginner experience (I'd recommend watching his Design, Composition & Performance talk for more background on that). That said, there is no reason not to also improve the experience for newer users. > Or is it an effort thing? And if it is an effort thing, is there some sort > of plan for what effort to put in? And if so, can I help by closing tickets? > My first wish would be that you log tickets for stuff like the one below. Providing patches would be a helpful next step. Everything is gated by the rate at which Rich looks at tickets though. > Here's one, for instance, which bugs me (using a build of branch master in > clojure from github just now) > > user=> (+ 1 1) > > 2 > > user=> (1 + 1) > > ClassCastException java.lang.Long cannot be cast to clojure.lang.IFn > user/eval17 (NO_SOURCE_FILE:10) > > > > > OK but what sort of noob would actually type in 1 + 1? (That's a joke. > Lots of people would. And I do sometimes when switching between java and > clojure) But that same error pops up if you misalign in parenthesis or > confuse an argument order or do a variety of other things. > > And that error message is terrible. I mean I know why it is there. Clojure > needs the first element of a list be the function position and 1 is not a > function, it is a long. But you have to squint rather generously at that > message to get to the problem. Or just learn what that message "really" > means, which seems a bit unfriendly. > > And so when I go look inside the source > > user=> (print-stack-trace *e 20) > > java.lang.ClassCastException: java.lang.Long cannot be cast to > clojure.lang.IFn > > at user$eval9.invokeStatic (NO_SOURCE_FILE:6) > > user$eval9.invoke (NO_SOURCE_FILE:6) > > clojure.lang.Compiler.eval (Compiler.java:6978) > > clojure.lang.Compiler.eval (Compiler.java:6941) > > > > Compiler.java has > > IFn fn = (IFn) fexpr.eval(); > > return fn.invoke(); > > > Which of course throws a class cast exception. > > > But there's so much information right there. Imagine this (in pseudo-code) > as > > > Object f = fexpr.eval(); > > if (f instanceof IFn) return (IFn)f.invoke() > > else throw ClojureNotAFunctionEvaluationError "First position in form at > line " ... " of environment " ... " is not a function object. You handed me > " + fexpr.first() " in form " ... " which has type " fexpr.first().class() > " and value " fexpr.first().toString() > > > or whatever (like maybe don't toString values - that's why you'd want a > plan. And maybe use a string table so you can internationalize. Again, plan > :) ) > Another thing to keep in mind is that you may be underestimating the full set of paths that lead to this particular error and whether the error message you are crafting makes sense in all of them. In runtime code, constructing better errors changes the size of the generated code, which can affect the ability of the JVM to inline code and lead to unexpected performance degradations (we've had to pull error message improvements for this in the past). I say this not to dissuade us, but just to highlight that things are not always as easy as they seem at first. > so I almost want to whack this sort of stuff into a local copy as I hit > error messages which bug me, but that seems foolish. And anyway I'm new > here. > Logging bugs is helpful. A search for dupes is helpful, but not essential. I am mostly aware of what's in the system already and will dedupe as needed. > Sorry if I have accidentally stepped into some sort of landmine or if this > has been rehashed a million times. > > > But I figured, in the spirit of being willing to help if there's help to > be applied, I would ask if there's some sort of thinking on this topic for > 1.9.1 or 1.10 or something? > I have spent some time thinking about systemic classes of problematic errors and error reporting. One class of problems come from macros with complex syntax - these tend to have hand-written parsers that make a lot of assumptions and also typically report their errors as the location of the macro code rather than the user code. Another class are functions in core that tend to either fail on unexpected types or bottom out several layers down in RT java code. All of these are substantially improved by the presence of specs which can produce more accurate errors at the earliest point in the stack where an invalid value is passed. Another area that Stu and I have talked about a bit is in error reporting, particularly around compiler errors (as compared to runtime errors) - right now we are tied to only an internal compiler exception class for reporting errors with location, but this could definitely be better. And then I think some of the existing tooling does a pretty poor job of showing the best info when an error is received. Alex -- 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.
