[mistersys]

Okay, why is there this attitude about dynamic typing vs. static typing that we can't have debates about it? As if it's an inherently subjective debate, not worth discussing? How is it ludicrous to say that for big programs, rules that allow the computer to automatically verify things for you can never be proven useful?

Modern statically typed languages are not the abtrusive, verbose dinosaurs of yesteryear. They can be used without type annotations quite often, and have almost no expressiveness limitations compared to dynamic languages.

I love clojure. It's almost my favorite language, the syntax is amazing and the experience of using paredit and the many bespoke control flow structures that make your problems easy to model make it feel like God's language. But yeah, debugging is massively painful. Stack traces are useless, and the lack of types makes errors pop-up in places you wouldn't expect.

That's not a subjective thing. It's a weakness of the language. There's no drawback to having optional static guarantees. Can we stop pretending this debate is not worth having?

[harperlee]

I love clojure and I wholeheartedly agree with what you say, if that serves anything.

I don't understand, for example, why stacktraces do not fold by default everything from clojure.core. Can't we assume that the language implementation is right for 99.999% of the world's stacktraces, and only show functions in other namespaces? In case some day someone finally triggers an error in clojure, you toggle a parameter and get the full stack.

[fulafel]

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.

[harperlee]

This should be a default at the language level, not require tooling to filter out verbose noise.

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?

[fulafel]

I agree the default filtering should be better, but disagree strongly about showing what the standard library is doing in debugging contexts.

[harperlee]

I'm just arguing about the default case. If you need to introspect the standard library that can be a flag / global variable toggle / whatever, but that's not typical.