3 ms·

I always use something like clj-stacktrace[1] to pretty print error messages and I've never had any issues figuring out what the problem was. Most of the time

I always use something like clj-stacktrace[1] to pretty print error messages and I've never had any issues figuring out what the problem was. Most of the time you're working from the REPL inside your editor anyways so the iteration loop is much, much better than any other language's. Even without clj-stacktrace I'd still prefer Clojure development to anything else. Rebooting a program and losing state is always worse than error messages taking a bit longer to understand at first. [1]: https://github.com/mmcgrana/clj-stacktrace https://github.com/mmcgrana/clj-stacktrace

jgalt212 10y ago
this seems a jillion times better than a standard stacktrace. why isn't it in built into the core?
- jeremiep 10y ago
  The core just uses whatever the VM under it has for error handling. Clojure is a hosted language and one of the best decisions it made was not to hide the VM its sitting on (either the JVM, CLR or JS - all have slightly different exception handling). I see it more as a development library and don't ship it to production. There's also cljs-devtools and dirac to enhance the chrome devtools with ClojureScript support. Once you try them you're not going back :)
  - jgalt212 10y ago
    I guess. But core could spit back a verbatim VM stacktrace and and Clojure specific/pretty printed version.
misterbowfinger 10y ago
Rebooting a program and losing state is always worse than error messages taking a bit longer to understand at first. Not sure if it's _always_ worse. I've worked in imperative & functional languages, and the quality of error messages is key to solving bugs and understanding a sufficiently complex system, regardless of what language it's coded in.
- jeremiep 10y ago
  Maybe not always, but its important enough to consider. You often have much more information at runtime than at compile time. Sure I can run the compiler and scan its errors but I feel its much more productive to poke around the program as its running. Even when working in C++/whatnot I learn more about programs by running them in the debugger than reading the code (reading UE4's source code will be weeks of head scratching because its so huge - 2 days of stepping into its boot process and you know and _understand_ most of its architecture). I'd argue that the hardest bugs to find are the ones your type-system is completely helpless against. Few languages protect against null pointers and every time you have a cast you're breaking out of the type system and its guarantees. Dependent types aren't frequent either so you're now augmenting the type-system with asserts and guards and whatnot. I find that in C++/Java/C# complex systems are the norm because everything is built out of mutable blocks and misconceptions about what makes programs fast. Every project I did in Clojure was a fraction of the complexity it would've had in imperative languages. You're reducing complexity _so much_ that the "type-system is good for complex bugs" argument almost vanishes.
  - misterbowfinger 10y ago
    ... I learn more about programs by running them in the debugger than reading the code Agreed - in Ruby, most of my development was driven by a REPL & debugger, and tests. That's an example of a primarily imperative language, though it borrows some ideas from Lisp. But there, again, understanding error messages was key.
lispm 10y ago
The example shows what's wrong: 1) bad error message. There error is explained in terms of some other machine, but not on the language level. 2) a zillion lines of useless stacktrace information: I don't want to debug the REPL, but the wrong call. The stacktrace also lacks argument information. Generally I would hope for a 'live' backtrace. > Most of the time you're working from the REPL inside your editor anyways so the iteration loop is much, much better than any other language's. Any other language, but not compared to those who have a similar or better REPL or debugger. Which is a zillion. > Rebooting a program and losing state is always worse than error messages taking a bit longer to understand at first. Not sure how that is related...

jgalt212 10y ago

this seems a jillion times better than a standard stacktrace. why isn't it in built into the core?

jeremiep 10y ago
The core just uses whatever the VM under it has for error handling. Clojure is a hosted language and one of the best decisions it made was not to hide the VM its sitting on (either the JVM, CLR or JS - all have slightly different exception handling). I see it more as a development library and don't ship it to production. There's also cljs-devtools and dirac to enhance the chrome devtools with ClojureScript support. Once you try them you're not going back :)
- jgalt212 10y ago
  I guess. But core could spit back a verbatim VM stacktrace and and Clojure specific/pretty printed version.

misterbowfinger 10y ago

Rebooting a program and losing state is always worse than error messages taking a bit longer to understand at first. Not sure if it's _always_ worse. I've worked in imperative & functional languages, and the quality of error messages is key to solving bugs and understanding a sufficiently complex system, regardless of what language it's coded in.

jeremiep 10y ago
Maybe not always, but its important enough to consider. You often have much more information at runtime than at compile time. Sure I can run the compiler and scan its errors but I feel its much more productive to poke around the program as its running. Even when working in C++/whatnot I learn more about programs by running them in the debugger than reading the code (reading UE4's source code will be weeks of head scratching because its so huge - 2 days of stepping into its boot process and you know and _understand_ most of its architecture). I'd argue that the hardest bugs to find are the ones your type-system is completely helpless against. Few languages protect against null pointers and every time you have a cast you're breaking out of the type system and its guarantees. Dependent types aren't frequent either so you're now augmenting the type-system with asserts and guards and whatnot. I find that in C++/Java/C# complex systems are the norm because everything is built out of mutable blocks and misconceptions about what makes programs fast. Every project I did in Clojure was a fraction of the complexity it would've had in imperative languages. You're reducing complexity _so much_ that the "type-system is good for complex bugs" argument almost vanishes.
- misterbowfinger 10y ago
  ... I learn more about programs by running them in the debugger than reading the code Agreed - in Ruby, most of my development was driven by a REPL & debugger, and tests. That's an example of a primarily imperative language, though it borrows some ideas from Lisp. But there, again, understanding error messages was key.

lispm 10y ago

The example shows what's wrong: 1) bad error message. There error is explained in terms of some other machine, but not on the language level. 2) a zillion lines of useless stacktrace information: I don't want to debug the REPL, but the wrong call. The stacktrace also lacks argument information. Generally I would hope for a 'live' backtrace. > Most of the time you're working from the REPL inside your editor anyways so the iteration loop is much, much better than any other language's. Any other language, but not compared to those who have a similar or better REPL or debugger. Which is a zillion. > Rebooting a program and losing state is always worse than error messages taking a bit longer to understand at first. Not sure how that is related...