Hacker News Reader

Comment by rboyd | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com