Fork me on GitHub

@matan I have no say in matters involving what gets accepted into Clojure, but I would ask you to at least consider what might meet your goals that could be written as a separate library that didn't require changes to its core code. My main motivation for suggesting this is that if you find a way to achieve that, then you own your own destiny schedule-wise for releasing something useful.


@noisesmith you are right, the core problem is preserving sufficiently explanatory context at every point that can throw. that is the rudimentary thing. although in the example put forth up there, would input validation have avoided the need? (at the cost of some runtime cpu cycles, in dev mode)


yes, in that case input validation could tell you that it needs map-entries or hashmaps, and lists are not accepted - in fact input validation will do a lot more to clarify than automatic rewrite of error messages will


and I have a strong hunch this is the point of having spec in clojure.core


I tend to agree!


Alas, it would probably take years until validation is added in the core language, I suspect that would never happen because the community will favor the needs of already experienced developers (over helping those spending time with error messages which is what beginners spend a large amount of their time with)


validation is already being added - for example 1.9 has a spec for the ns form and no longer accidentally works if you use require instead of :require


Wow, interesting developments...


Is it widely used in clojure's core in 1.9?


I'm not sure how extensively it's in there, but this is why spec is in core instead of being a library, so that core specifications can give better errors


@noisesmith that's very good I think. as a beginner, I spent maybe 20% of my time deciphering error messages.


I think the problem here is that solving the error message issue is extremely hard in the general case, but in reality there's a handful of "weird error messages" that Clojure produces that everyone just has to learn as a beginner, and folks need to learn a little bit about how to read a stacktrace (which is a very valuable skill for life).


So there's a big trade off between the complexity and difficulty of solving the "bad error messages" without affecting performance vs the (relatively) short period of pain as each newcomer comes up to speed.


Some people have already started complaining about the explanations produced by spec failures, even tho' the messages provide the exact details of what's wrong -- but they provide a lot of information.


seancorfield: For what it’s worth I think these complaints against spec are definitely warranted. For what its worth the spec errors are incredibly useful but very poorly formatted which makes them very hard to read; simply because there tends to be a lot of noise.


True. The formatting leaves a lot to be desired!


I honestly think it’s the main problem with spec just now, and think some basic formatting would go a long way to convert people from saying “Clojure has terrible error messages” to “Clojure has great error messages”. See here for a pitch I made:


right- but for cases where all you are doing is slowing down the compiler - many of us are willing to pay that price since we already avoid compiling new code in our code hotspots if we aren't totally insane


I have some reservations about "short period of pain". In my philosophy, usability should be a property of developer tools, not just the applications they create.


I'd say most Clojure developers would not accept that slowdown -- if you don't AOT everything (and AOT is horribly fraught with all sorts of problems!) then you'll pay the compilation cost during the initial warm up of your application.


Aren't clojure.spec validations only activated in dev mode?


all I'm talking about is the extra work spec introduces...


@matan I think it's reasonable for Clojure tooling to try to ease the beginner curve -- but it is not reasonable to expect the compiler to do that if it slows it down.


@noisesmith I am happy to have spec instrumentation in place during development, but it's potentially a big overhead in production.


The current use of spec in core is around macros so it's a compile-only penalty.


(or rather, it's a read-time penalty 🙂 )


I think that's where we humbly defer. I want developers joining my team with clojure, all personality types not just those that never err or are willing to dig up the core language's stack trace to analyze why the core language is having trouble with their input on ocassion.


Doesn't spec come with that feature to disable all validations outside dev mode?!


But as a Clojure (or Java or any JVM language) developer, you'll always have to read stacktraces...


@matan That's exactly what I said:


Of course. The question is whether an error is explanatory, v.s. requiring analyzing the core language's source code...


It's more than you enable instrumentation in dev mode (but not in production unless you want to).


Yes right, correct


And I'm saying you get used to the error messages very quickly.


Well I think spec enables both types of devs then


@seancorfield is that a statistic? or a sample of 1 persons? 🙂


It's opinion 🙂


I think this varies with different people lol


Well thanks for the discussion!


Yup, but I do agree with the core team's overall prioritization so far...


In light of this discussion, me too, as much as spec will possibly be used to improve additional core library pieces, in that humble regard


Would I like error messages to be better? At this point, I don't care much for myself, but yeah it would be nice for all the future Clojure devs so, yeah, it's worth spending some time on but I think systemic approaches (like Spec) are going to provide better leverage.


If the language is to persevere, I think you might be underestimating how important this vector of improvement might be though. We don't see the world flooding the clojure download page do we? 🙂


I suspect there are a few key places in the core code where catching a particular exception and throwing a better one might really help -- but I'd be concerned about performance and how to ensure any performance penalty could be limited to dev-only.


I don't think Clojure needs to flood the world tho'. Clojure is "successful enough". It's never going to go truly mainstream, because "OMG! Parens!", so the error messages are much less of an obstacle than other key aspects of the language.


@matan For a while, I was very upset about clojure.string's behavior when faced with null string inputs. Given that (str nil) produces "", I argued for a while that having nil input be treated like "" in clojure.string would make the library a lot less frustrating...


...I figured that 9 times out of 10, the most expected behavior would be ""-for-`nil`... so I built a version of clojure.string that behaves like that... and it was nice to use but it was noticeably slower 😞


And then other folks convinced me that treating nil as "" would not universally be good behavior and would mask all sorts of other errors.


@seancorfield Yes we all had such examples indeed


Going back to "OMG! Parens!", that too can be alleviated with proper error messages!


It can be alleviated by tooling 🙂 An editor that auto-balances parens and colors them (rainbow for matching parens is good, as well as pastel colors to make them less visible).


Well, at least I forwarded your note on upcoming use of spec inside clojure.core in 1.9, to that project that tried to accomplish similar things ( If I get it right, they also try to match exception text and replace messages in-flux.


In email, I'm notified the codebase is currently unstable and should be for the meanwhile avoided


Thanks for the yesterday/morning discussion