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!
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.
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…
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.
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. 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.
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
> <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
> <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
> <mailto:clojure+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <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.
