8 ms·

> It is more useful to think of error messages as non-existent than to think of them as bad. If this is true, my respect for Clojure just completely dropped.

> It is more useful to think of error messages as non-existent than to think of them as bad. If this is true, my respect for Clojure just completely dropped. Error messages are a crucial part of a language and they are instrumental to the robustness of the programs it helps create. The fact they have been so severely neglected by the Clojure teams makes me think the authors of the language don't really understand modern large scale programming.

abc_lisper 8y ago
That’s not true at all. I have built pretty big applications in clojure, and it’s been nothing but joy to use. There are times when I don’t know how I came to a situation, but that’s very rare. Most of the time I make a large change and it works on the first try; brings a smile to my face every time. I think, I may be wrong here, clojure works very well for people with a little bit of experience and those who think things through before they write code. I have my guards when I write clojure though. I always write tests, and in the beginning I used to make small git commits, though I don’t need to do that now anymore.
- hota_mazi 8y ago
  > That’s not true at all. I have built pretty big applications in clojure, and it’s been nothing but joy to use. I'm happy for you but your experience doesn't invalidate my claim. > clojure works very well for people with a little bit of experience and those who think things through before they write code. All languages work well for people who think before they write code. Clojure makes that harder than necessary, though, being dynamically typed.
  - abc_lisper 8y ago
    Hmm. I can’t disprove theoretically what you said. Practically, it is much easier to build a large scale application in clojure, than say, java.
    - d4mi3n 8y ago
      Going to have to disagree with you there—if for no other reason than the tooling around Java is much more robust and available than for Clojure. I’m thinking static analysis, IDE support, fuzzers, linters, etc. Clojure has potential, but the lack of good feedback when things go wrong makes it _very_ hostile to users of the language, especially when first trying to pick it up.
      - didibus 8y ago
        I guess all we can do is provide our individual datapoints. From my experience, I find it much easier to do so with Clojure. Systems generally last longer, almost never need refactoring, accumulate a lot less tech dept, and easily accommodate future requirements when written in Clojure as opposed to Java. I come from a team who has a 50/50 set of systems in java and clojure, been the case for 3 years. Team size averages around 8 devs. Tooling in Clojure is actually pretty great. Generative testing, linters and IDEs I find work better then in Java personally. Where I agree with you is learning curve. Clojure is definitly difficult for new users to pick up. The community and core team I think are more focused on improving that now then ever though. So hopefully it'll change. Also, I'm not sure hostile is a good word, if anything, the best part about Clojure is the community is actually really nice, helpful and supportive, even to new users. There's no trolls, and a lot of great open dialogue, active members ready to help you on chat and forums at all times, etc.
        BWStearns 8y ago
        As an aside: which linter do you use? Been looking for one.
        didibus 8y ago
        I always have my projects setup to use Kibit and Eastwood. And depending on my editor, I might use Joker for syntax checking as I type. Cursive has pretty good inbuilt linting too.
      - abc_lisper 8y ago
rboyd 8y ago
That's quite a judgement call to make based on the utility of error messages. I can't remember the last time I was blocked based on a Clojure error message anyway. Errors are less frequent and usually pretty obvious. I think you're wrong to say core devs don't understand modern programming, but you'd probably be right to say that they didn't prioritize making it approachable and stooping to the lowest common denominator. And it's not just Clojure, but datomic, core.async, spec -- all solving real problems in modern large scale programming with elegance. Watch Rich's 'Effective Programs' talk [1] and lmk if you still feel that he's out of touch with modern large scale programming. I think he's pretty in tune. [1] https://www.youtube.com/watch?v=2V1FtfBDsLU https://www.youtube.com/watch?v=2V1FtfBDsLU
- dmitriid 8y ago
  > making it approachable and stooping to the lowest common denominator. Why do people assume that being dev-friendly is the "lowest common denominator"? Devs are not stupid. Beginners are not stupid. Moreover, the more senior you are, the more you begin to appreciate clear precise error messages that directly point to the problem. There's only so much brainpower, and I'd rather spend it on solving a problem, and not on figuring out/memorizing yet another cryptic error message. And yes, no amount of fluffy talks or "large scale apps built with datomic" will convince me that those devs are in touch with modern programming. They are just used to what they work with.
  - rboyd 8y ago
    My point was simply that Rich built Clojure to solve his own problems, not to coddle beginners. Beginners are the lowest common denominator not because they are stupid but because they are inexperienced, by definition. > Moreover, the more senior you are, the more you begin to appreciate clear precise error messages that directly point to the problem. Hopefully the more senior you are, the less you encounter errors in the first place. > There's only so much brainpower, and I'd rather spend it on solving a problem, and not on figuring out/memorizing yet another cryptic error message. And I'm saying that's not the Clojure experience once you're up and rolling. You iterate over program construction in small manageable chunks, with immediate feedback from an editor jacked into a cider repl, and your repl experiments evolve into long-standing tests. Also, even if the Clojure language doesn't necessarily cater to the beginner, the Clojure community definitely does. There are constant efforts to evolve better docs, extend tooling, and build user groups that reach out to beginners.
didibus 8y ago
What is meant is that Clojure rarely throws its own errors. Instead you'll get the underlying JVM error. And the underlying JVM errors are normally very noisy and often a little indirect to exactly what you did wrong. As someone who knew Java very well though, I've never had much trouble connecting the underlying JVM error to my Clojure code. That said, for beginners or people unfamiliar with Java, its an extra burden to have to decipher. And I myself wouldn't mind errors that point me more directly to my Clojure code, instead of towards its implementation.
didibus 8y ago
Error messages or exceptions? Clojure has errors, its actually quite strict in that regard compared to other popular dynamic programming languages. Its types are strict, argument count matters, dependent vars and functions must be declared in advance. The problem is the errors aren't easy to understand what you did wrong exactly. As in, the message isn't very precise. But the errors are there. Well, except with get I guess, but that seems like it was on purpose, the implementation would have to specifically check for and return nil.
idontpost 8y ago
Having written a substantial full-stack Clojure app, I really don't find the lack of meaningful error messages to be a problem. I think you're underestimating how radically different Clojure is from most other languages. Idiomatic Clojure code is written in atomic, easily tested units. If you're throwing exceptions, you should be using ex-info and creating the error message yourself when its thrown (so a bad message is your own damn fault). If the error is thrown by clojure.spec, it's a type error and the source is obvious. If the error is thrown by the JVM, the stack trace often points to the exact line of code causing the error because your code is written in small, atomic functions in the first place. In short, if you approach Clojure like Java, yes, the error messages are a problem. If you approach it like Clojure, it's really just not a problem.
puredanger 8y ago
I'm the most junior member of the Clojure dev team and I have been programming professionally for 27 years (and started programming about 10 years before that). All of us have worked on large scale systems for the majority of our career in a variety of languages, both statically and dynamically typed (Java, C++, C#, Ruby, Lisp, Clojure, etc). I mention this not in defense (you can make your own judgements as you will) but as background. I don't think any of us would agree with the characterization of Clojure errors in the article.
- ken 8y ago
  Can you elaborate? What's the alternative view? Are you suggesting that this behavior is all by design?

abc_lisper 8y ago

That’s not true at all. I have built pretty big applications in clojure, and it’s been nothing but joy to use. There are times when I don’t know how I came to a situation, but that’s very rare. Most of the time I make a large change and it works on the first try; brings a smile to my face every time. I think, I may be wrong here, clojure works very well for people with a little bit of experience and those who think things through before they write code. I have my guards when I write clojure though. I always write tests, and in the beginning I used to make small git commits, though I don’t need to do that now anymore.

hota_mazi 8y ago
> That’s not true at all. I have built pretty big applications in clojure, and it’s been nothing but joy to use. I'm happy for you but your experience doesn't invalidate my claim. > clojure works very well for people with a little bit of experience and those who think things through before they write code. All languages work well for people who think before they write code. Clojure makes that harder than necessary, though, being dynamically typed.
- abc_lisper 8y ago
  Hmm. I can’t disprove theoretically what you said. Practically, it is much easier to build a large scale application in clojure, than say, java.
  - d4mi3n 8y ago
    Going to have to disagree with you there—if for no other reason than the tooling around Java is much more robust and available than for Clojure. I’m thinking static analysis, IDE support, fuzzers, linters, etc. Clojure has potential, but the lack of good feedback when things go wrong makes it _very_ hostile to users of the language, especially when first trying to pick it up.
    - didibus 8y ago
      I guess all we can do is provide our individual datapoints. From my experience, I find it much easier to do so with Clojure. Systems generally last longer, almost never need refactoring, accumulate a lot less tech dept, and easily accommodate future requirements when written in Clojure as opposed to Java. I come from a team who has a 50/50 set of systems in java and clojure, been the case for 3 years. Team size averages around 8 devs. Tooling in Clojure is actually pretty great. Generative testing, linters and IDEs I find work better then in Java personally. Where I agree with you is learning curve. Clojure is definitly difficult for new users to pick up. The community and core team I think are more focused on improving that now then ever though. So hopefully it'll change. Also, I'm not sure hostile is a good word, if anything, the best part about Clojure is the community is actually really nice, helpful and supportive, even to new users. There's no trolls, and a lot of great open dialogue, active members ready to help you on chat and forums at all times, etc.
      - BWStearns 8y ago
        As an aside: which linter do you use? Been looking for one.
        didibus 8y ago
        I always have my projects setup to use Kibit and Eastwood. And depending on my editor, I might use Joker for syntax checking as I type. Cursive has pretty good inbuilt linting too.
    - abc_lisper 8y ago

rboyd 8y ago

That's quite a judgement call to make based on the utility of error messages. I can't remember the last time I was blocked based on a Clojure error message anyway. Errors are less frequent and usually pretty obvious. I think you're wrong to say core devs don't understand modern programming, but you'd probably be right to say that they didn't prioritize making it approachable and stooping to the lowest common denominator. And it's not just Clojure, but datomic, core.async, spec -- all solving real problems in modern large scale programming with elegance. Watch Rich's 'Effective Programs' talk [1] and lmk if you still feel that he's out of touch with modern large scale programming. I think he's pretty in tune. [1] https://www.youtube.com/watch?v=2V1FtfBDsLU https://www.youtube.com/watch?v=2V1FtfBDsLU

dmitriid 8y ago
> making it approachable and stooping to the lowest common denominator. Why do people assume that being dev-friendly is the "lowest common denominator"? Devs are not stupid. Beginners are not stupid. Moreover, the more senior you are, the more you begin to appreciate clear precise error messages that directly point to the problem. There's only so much brainpower, and I'd rather spend it on solving a problem, and not on figuring out/memorizing yet another cryptic error message. And yes, no amount of fluffy talks or "large scale apps built with datomic" will convince me that those devs are in touch with modern programming. They are just used to what they work with.
- rboyd 8y ago
  My point was simply that Rich built Clojure to solve his own problems, not to coddle beginners. Beginners are the lowest common denominator not because they are stupid but because they are inexperienced, by definition. > Moreover, the more senior you are, the more you begin to appreciate clear precise error messages that directly point to the problem. Hopefully the more senior you are, the less you encounter errors in the first place. > There's only so much brainpower, and I'd rather spend it on solving a problem, and not on figuring out/memorizing yet another cryptic error message. And I'm saying that's not the Clojure experience once you're up and rolling. You iterate over program construction in small manageable chunks, with immediate feedback from an editor jacked into a cider repl, and your repl experiments evolve into long-standing tests. Also, even if the Clojure language doesn't necessarily cater to the beginner, the Clojure community definitely does. There are constant efforts to evolve better docs, extend tooling, and build user groups that reach out to beginners.

didibus 8y ago

What is meant is that Clojure rarely throws its own errors. Instead you'll get the underlying JVM error. And the underlying JVM errors are normally very noisy and often a little indirect to exactly what you did wrong. As someone who knew Java very well though, I've never had much trouble connecting the underlying JVM error to my Clojure code. That said, for beginners or people unfamiliar with Java, its an extra burden to have to decipher. And I myself wouldn't mind errors that point me more directly to my Clojure code, instead of towards its implementation.

didibus 8y ago

Error messages or exceptions? Clojure has errors, its actually quite strict in that regard compared to other popular dynamic programming languages. Its types are strict, argument count matters, dependent vars and functions must be declared in advance. The problem is the errors aren't easy to understand what you did wrong exactly. As in, the message isn't very precise. But the errors are there. Well, except with get I guess, but that seems like it was on purpose, the implementation would have to specifically check for and return nil.

idontpost 8y ago

Having written a substantial full-stack Clojure app, I really don't find the lack of meaningful error messages to be a problem. I think you're underestimating how radically different Clojure is from most other languages. Idiomatic Clojure code is written in atomic, easily tested units. If you're throwing exceptions, you should be using ex-info and creating the error message yourself when its thrown (so a bad message is your own damn fault). If the error is thrown by clojure.spec, it's a type error and the source is obvious. If the error is thrown by the JVM, the stack trace often points to the exact line of code causing the error because your code is written in small, atomic functions in the first place. In short, if you approach Clojure like Java, yes, the error messages are a problem. If you approach it like Clojure, it's really just not a problem.

puredanger 8y ago

I'm the most junior member of the Clojure dev team and I have been programming professionally for 27 years (and started programming about 10 years before that). All of us have worked on large scale systems for the majority of our career in a variety of languages, both statically and dynamically typed (Java, C++, C#, Ruby, Lisp, Clojure, etc). I mention this not in defense (you can make your own judgements as you will) but as background. I don't think any of us would agree with the characterization of Clojure errors in the article.

ken 8y ago
Can you elaborate? What's the alternative view? Are you suggesting that this behavior is all by design?