|
|
|
|
|
|
by fulafel
2010 days ago
|
|
|
The tooling does support customizable stack trace filtering pretty well I think (at least in Calva and CIDER, probably Cursive too?). I wouldn't want to filter out clojure.core frames because you can click on those and see the line of code in the stdlib that is calling back into your code when you use higher order functions, it's useful. |
|
|
Apart from the principle of the language being not dependent on external tools, on practical terms: if you get a stacktrace in a production log, or on a terminal, you don't have that tooling available, for example.
This is precisely what mistersys was denouncing. This is an objective issue, that pushes newbies away, that consistently gets discussed in the annual survey, in HN, and in basically every conversation about clojure. Spec has improved somewhat the error messages, but still core functions are not specced officially, and still the error messages are hugely verbose and expose implementation details that should not be visible. We should at least acknowledge it instead of pretending it's solved, or not an issue due to tooling workarounds.
On your point about seeing the clojure.core stacktrace: the implementation of a core function shouldn't be something that you need to inspect to know how it's working, that should be clear from the public interface. That's part of the clojure philosophy, have small functions that are obvious and compose easily in your head, so you understand every piece easily. In any case, I've been using clojure on all my side project for about 8 years now and I've never had to do what you discuss, could you give an example of when would you need this?