Live data from Hacker News

My Increasing Frustration with Clojure

ashtonkemerling.com

31–40 of 240 posts

Re: My Increasing Frustration with Clojure

#31
post #23

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 think the author is right in his assessment that it's a community problem: the Clojure core team does not want outsiders to participate in the future of the language, but does not clearly communicate this up front. I absolutely support the right for them to do this (I'm a happy user of the non-open C# language, after all), but they should clearly state that Clojure is defined by Cognitect, not the community. Even o…

While I don't know enough about Clojure politics to weigh in on general NIH trends, this specific patch actually has a strong rationale for further debate before acceptance.

http://dev.clojure.org/jira/browse/CLJ-1517?focusedCommentId...

Re: My Increasing Frustration with Clojure

#32
post #28

Earlier quoted context omitted.

I think you misread the author's complaint. He's complaining that the `union` abstraction is leaky - it exposes its own ad-hoc implementation choices.

I think you may have misread it - he's pretty clear that he considers these bugs that clojure core chooses to ignore because they either a) don't understand them b) want to do cool new stuff

> he's pretty clear that he considers these bugs

Design bugs, not implementation ones. In other words, the author of the post acknowledges that the existing implementation does what Hickey wants, but the author would prefer that it did something else.

Re: My Increasing Frustration with Clojure

#33

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.

Re: My Increasing Frustration with Clojure

#34
Respect and treatment of people is a real concern. I made a decision not to pick a certain library after seeing people being shut down in the issue tracker in the most unnecessarily abrasive way possible.

Clojure does have a lot of amazing people though, and I've been very welcome reaching out to people for help as a whole.

Re: My Increasing Frustration with Clojure

#35
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 function and that single if blew the JVM inline budget causing that function to never be inlined. And that improvement had to he yanked out.

When we talk about patches for a language, we have to realize that if we don't want constantly breaking APIs we have to test that a patch doesn't break existing code, that it also doesn't slow down existing code (or at least not enough that users would care), that in all sorts of cases the JVM won't freak out and do something bad. Then we also have to make sure that the change doesn't restrict the language in the future. Does making some interface public mean it will always be public? Are we happy to keep it that way for all time?

Taking all that into consideration, I have to sit back and say , yeah, maybe I'll just remember to only hand sets to the functions in `clojure.set`. Or maybe I'll help out by adding clojure.spec annotations for these functions so I can turn them on during testing.

In the end, I'd much rather have a rough-around-the-edges language that takes a garbage-in-garbage-out approach, than one that breaks the API at every turn. Perhaps they aren't mutually exclusive, but it certainly takes a heroic effort, and a lot of prioritization.

Re: My Increasing Frustration with Clojure

#36
post #27

> The thing I am trying to build is not possible in any other ecosystem today Umm... what? I'm afraid I don't understand how the "grand vision" behind Clojure adds pixie dust that makes it capable of something another Turing complete language isn't. Care to elaborate?

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.

Re: My Increasing Frustration with Clojure

#37
post #27

> The thing I am trying to build is not possible in any other ecosystem today Umm... what? I'm afraid I don't understand how the "grand vision" behind Clojure adds pixie dust that makes it capable of something another Turing complete language isn't. Care to elaborate?

All Dustin had to say to make the "impossible" argument real is to add the qualifier "practically", so while it is possible to build a highly dynamic, enterprise application entirely out of HTML/CSS (recall CSS3 is turning complete) [1] it is "practically impossible" to do so.

[1] http://my-codeworks.com/blog/2015/css3-proven-to-be-turing-c...

Re: My Increasing Frustration with Clojure

#38
post #9

Once I tried to make a union of a sorted set and an unsorted one. Result set inherits behaviour of a bigger input set so when i first got my sometimes-sorted set i thought like loosing my mind.

Avoiding madness like this is why I have come to really prefer statically typed languages.

Re: My Increasing Frustration with Clojure

#39
post #27

> The thing I am trying to build is not possible in any other ecosystem today Umm... what? I'm afraid I don't understand how the "grand vision" behind Clojure adds pixie dust that makes it capable of something another Turing complete language isn't. Care to elaborate?

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

Re: My Increasing Frustration with Clojure

#40

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.

1)install leiningen 2)install lighttable 3)??? 4)Clojure

Edit: You really don't need an IDE for clojure. A repl and a text editor are your best friends IMO

Post reply on HN