Live data from Hacker News

My Increasing Frustration with Clojure

ashtonkemerling.com

51–60 of 240 posts

Re: My Increasing Frustration with Clojure

#51

Earlier quoted context omitted.

You're getting down voted; probably because the way you worded your question. I'm giving you an up, because I, too, am very curious how something is possible only in Clojure and nothing else.

This is one architecture that is made possible by clojure: http://tonsky.me/blog/the-web-after-tomorrow To build it outside of clojure ecosystem, you would need to first build all the pieces of the clojure ecosystem

Thanks for pointing me to that article. I've been mulling over for years how to architect apps to remove the server, that layer never sat well with me. I've also found I couldn't discuss the problem with anyone because "clients can't access the database directly!" is such a knee-jerk reaction.

Re: My Increasing Frustration with Clojure

#52

Something that is often very hard to understand (it took me years to do so). Is that maintaining a language is insanely hard. Everything has a cost. Let me give a good example: A few years back someone submitted a patch that improved the error messages in Clojure. Worked great, just a single extra "if" and a message. It was committed to master. Then people's code got way slower. Why? Well this was a often used functi…

Sounds like there might be a potential for a dev and production codebase?

Re: My Increasing Frustration with Clojure

#53

I love Clojure, and I use it in every project where I have control over the technology, but I do agree with the points raised by Ashton Kemerling. Clojure is beautiful, and backed by beautiful theories, but its implementation needs to be clean or it will eventually develop enough special cases that its beauty will be ruined. In some sense, you could say this is what happened to Ruby, though there the allowance of "sp…

> Clojure is beautiful, and backed by beautiful theories, but its implementation needs to be clean or it will eventually develop enough special cases that its beauty will be ruined.

A bit like communism.

Whenever I watch one of Rich Hickey's signature talks, I'm enthused, but actually looking and using the concepts leaves a rather stale taste compared to the promise.

Re: My Increasing Frustration with Clojure

#54

I think this article is spot on. But. I think the root cause here is that many of the tools are build by the community. Great tools cost a lot of money to build, and you need to build the right thing at the right time, the cost needs to be spread across the comminuty. The community is growing and tools are improving. The first generation tools with all their rough edges are being replaced by simpler tools that have i…

I couldn't agree with you more. I've been wanting to learn Clojure for years now, but I'm not going to fight with an IDE for hours to do so.

I do it with vim and fireplace.vim, it took about 45 minutes to get going. Definitely worth it.

Re: My Increasing Frustration with Clojure

#56
post #12

The underlying issue to me seems to be that Clojure is still not developed by a team, but by a single developer, who cannot think out of the box. union and intersect not doing the same thing as in common lisp (accepting lists and vectors), and returning buggy values instead is just a bug, even if the developer didn't have that in mind originally, and doesn't like to support that.

Of all the people in the world I can think of with the inability to think outside the box, Rich Hickey has to be at the bottom of the list :)

Re: My Increasing Frustration with Clojure

#57
post #46

Odd, in two years I've never been bit by a single one of these bugs. And if I had, I could probably pretty easily shrug them off. My frustration came from the lack of a type system, and that there's no "myThing." (myThing-dot) to give you intellisense. Even many dynamic language editors have some variant of this now. So coding in Clojure involves too much looking stuff up and memorizing stuff, and is way slower than…

What editor do you use? Emacs Cider does this, and does it much better than IDEs (IMO).

Re: My Increasing Frustration with Clojure

#58

Something that is often very hard to understand (it took me years to do so). Is that maintaining a language is insanely hard. Everything has a cost. Let me give a good example: A few years back someone submitted a patch that improved the error messages in Clojure. Worked great, just a single extra "if" and a message. It was committed to master. Then people's code got way slower. Why? Well this was a often used functi…

Critiques from Clojure users should really try tradeoff analysis, as Hickey advocates. Which means I should analyze the costs of what I advocate, not just the benefits. For clojure.set/intersection (CLJ-1682?), Alex Miller clearly mentioned the speed consideration — one all users would have to bear. Not to mention spending time on this versus other things.

Also, it was ironic to read elsewhere in the article, "Even more obnoxious, it was closed as wontfix. Apparently a single sentence in the docs is good enough for the Clojure team..." Then in the next paragraph: "I was treated pretty shabbily by..."

(One can go on. Take the headline, "Ignorance or Apathy of Underlying Principles")

Calling hardworking people (who do free work for one's own company) "obnoxious" and ignorant/apathetic seems shabby too. While demanding "fixes" from them, and putting down their "big highlights from the past year or so" (Transit, Transducers, Spec) with a backhanded "These are okay, I guess." I'd never tolerate a client/manager with that attitude about my hard work, and that's someone paying me. No wonder free software maintainers burn out.

Re: My Increasing Frustration with Clojure

#59
post #8
post #7

Earlier quoted context omitted.

I see a lot of issues but not a lot of PRs. As a maintainer there is a lot of prioritization going on, and it seems that the things that bother the blog author are not things that bother the maintainers. I also agree with some of the replies on the issues - garbage in garbage out for a function is ok behavior. One of the cool things about clojure and other languages like this is that these things can often be fixed a…

In what way is "garbage in garbage out" better than consistent handling and explicit failure, especially for something so well-defined mathematically? That's sort of a lazy argument, imo. I shouldn't need to pull in more libs for baseline language expectations, either. Core libraries are what languages really are, much more important than just syntax.

Because checks to avoid some kinds of garbage can incure significant performance penalty. There is always a tradeoff in that sense, and I think Clojure is pretty well balanced in that way. So, read the docs, try the functions out to see how they work, write tests, and sanitize the data at the appropriate place.

Re: My Increasing Frustration with Clojure

#60

Earlier quoted context omitted.

You're getting down voted; probably because the way you worded your question. I'm giving you an up, because I, too, am very curious how something is possible only in Clojure and nothing else.

This is one architecture that is made possible by clojure: http://tonsky.me/blog/the-web-after-tomorrow To build it outside of clojure ecosystem, you would need to first build all the pieces of the clojure ecosystem

> To build it outside of clojure ecosystem, you would need to first build all the pieces of the clojure ecosystem

That's simply untrue, and even the author's conclusions contradict your point. You can already do all of these things with just javascript. And if you're arguing that javascript has rebuilt the entire clojure ecosystem, then what is the non-aesthetic case for clojure?

I like clojure a lot and I've made a few toy projects with it, but I see its primary value as helping me write better code in all languages I use.

Post reply on HN