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

> 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.

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.

> coddle beginners > stooping to the lowest common denominator

You keep saying that people are stupid. And since you keep iterating it, I believe this is the point you are making, not some speculation about what Rich Hickey does or does not.

> if the Clojure language doesn't necessarily cater to the beginner

A dev-frienndly language does not cater just to beginners. Everyone benefits.

> There are constant efforts to evolve better docs, extend tooling, and build user groups that reach out to beginners.

So, they do stoop to the lowest common denominator and coddle? Why can't Clojure?

> You keep saying that people are stupid

I didn't say that, because I don't feel that way.

I think that you're doing it right as long as you're using a language that helps you be productive and brings you joy. Sounds like you're already good where you're at.

Enjoy the rest of your weekend.

> I didn't say that, because I don't feel that way.

Yet your language betrays your feelings.

I would never in my life use words like "stoop to lowest common denominator" or "coddle beginners" when talking about beginners (or other developers in general).

The rest of your message is a thinly veiled contempt at best. So, good weekend to you, too.

> My point was simply that Rich built Clojure to solve his own problems, not to coddle beginners.

And if Rich likes Clojure, he can go nuts with it.

But a significant chunk of Hackernews believes that Clojure is the greatest thing since sliced bread, or even the obvious successor/replacement to all other Lisps. As an experienced programmer myself, if someone told me that Clojure is better suited to my application needs than CL or Scheme, I would tell them no, and fuck you. And this is part of why; there are other deficiencies and quibbles I have with Clojure's design.

As a clojure programmer myself, it surprises me to see other clojure programmers say this. Error messages are an important part of programming and that you didn't face many errors doesn't mean others won't and doesn't mean they don't know how to program either. Even the article above clearly states that error messages are bad.

Which part do you disagree with? Are you commonly blocked by Clojure errors where you have to stop and spend a material amount of time deciphering them?

Nowhere have I said that if you see an error message you don't know how to program.

I face errors every day, but I don't face errors that are so cryptic that they block my productivity. We agree errors are useful even if we disagree that Clojure's errors are bad.

I did find the errors very confusing when I was getting started, but I think that was because the errors use Clojure terminology that I had not yet learned.

> Nowhere have I said that if you see an error message you don't know how to program.

> making it approachable and stooping to the lowest common denominator.

> We agree errors are useful even if we disagree that Clojure's errors are bad.

I would assume that you disagree with the article then, in which case I can't make any other point to emphasize that

The simple fact that Clojure is dynamically typed tells me that this language is simply not suited for large scale programming.

The trend in programming languages is pretty clear, we are moving more and more strongly toward languages that are statically typed and with type inference.

And for good reasons, in my opinion.

The trend is as you said, a fashion trend.

The truth is, the issues that come out of your current model of programming makes you seek something that trades them out for other issues. Right now, those other issues are unknown to you, and you're not feeling the pain they bring. 10 years from now, they'll be all you complain about, and the trend will go back.

Now, maybe I'm wrong, but its rare that a truly better paradigm shows up. It happened before though, so might happen again. Maybe that'll be inferred static types, but we've had those for so long already that I'm doubtful. For example, Clojure has infered static types, a lot of people tried it and felt it was more trouble then worth. So in the small Clojure world, the trend to infered static types already happened and passed by back to runtime contracts.

It's not really clear to me what you mean with "scale" here. Are you referring to the scale of a program, i.e. size in LoC and/or complexity of components, or to the scale of a team of developers, i.e. the number of persons working on a given codebase?

Both.

Scale in performance, since dynamically typed languages have fundamental hurdles that will always make programs slower than when written in a statically typed language.

And scale in code base and developer strain. The fact that it's mathematically impossible to reliably refactor code automatically if the types are absent encourage spaghetti code bases that developers are afraid to modify because they can never be sure they're not breaking anything.

Such hesitations never happen in statically typed languages.

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.

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.

> 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.

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.

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.

I've worked with large Java applications and large Closure applications. The effectiveness of the tooling in clojure, in particular Emacs and nREPL-based tooling, makes local and remote programming and debugging, even in production miles better than anything I experienced in Java. I don't remember how it was when I started, but as an expert user (the only case I particularly care about), nothing I've tried except Common Lisp approaches Clojure.

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.

As an aside: which linter do you use? Been looking for one.

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.

True, but I don’t need most of the those tools. Static analysis is most useful when working on large teams. When 3 or 4 people are working on a project, it is mostly unnecessary. I’m not saying error messages are not useful, or static analysis isn’t, they are, but not as much as people are thinking here(wrt clojure)

There is 3-5x difference in productivity between java and clojure most of the time, just because I don’t have to read a lot of code to make a change. Clojure, written right, feels like math equation on a board. My eyes don’t dart around up and down figuring out the code. It is terse, to the point and immutable.

It is subjective, but clojure vs Java is like doing math with Arabic numerals vs doing them with Roman numerals. I’m sure we need lot more help when doing math with Roman numerals, but that level of help is simply not necessary, and is more about the medium than the message

> Practically, it is much easier to build a large scale application in clojure

There is a vast amount of evidence that shows the opposite. Most of the code bases you use on a daily basis today, such as Google, Amazon, eBay, etc... are built on Java.

Very few (if any) are built on Clojure.

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.

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.

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

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.