My Increasing Frustration with Clojure • Hacker News Board

Re: My Increasing Frustration with Clojure

#11

Post by catnaroek » Sat, Jun 11, 2016, 3:21 PM UTC

There are basically four possible attitudes to abstraction:

(0) We don't need no stinkin' abstractions! Obviously not befitting a high-level language like Clojure, move along.

(1) We enforce abstractions in our heads. Running into an undocumented scenario is undefined behavior. (Yes, in the C sense.)

(2) We enforce abstractions via compile-time checks. Clojure won't have this anytime soon, move along.

(3) We enforce abstractions via sensible coercions (whenever possible, if desired) or runtime exceptions (anywhere else).

Like the author, I find (3) the most sensible choice, and I'm surprised that the Clojure team would rather choose (1), which is known to be a major productivity killer.

Re: My Increasing Frustration with Clojure

#12

Post by rurban » Sat, Jun 11, 2016, 3:21 PM UTC

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.

Re: My Increasing Frustration with Clojure

#13

Post by lkrubner » Sat, Jun 11, 2016, 3:22 PM UTC

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 "special cases" was more deliberate. I recall, back in 2003, reading the interview between Matsumoto and Bill Venners: http://www.artima.com/intv/ruby.html -- and I thought that Ruby had a beautiful philosophy. But having worked with Ruby for many years, I now see how much it is undermined by the many special cases it allows, and the wild ambushes that its most imaginative features allow (monkey patching).

I don't want to see Clojure go down that path. I want Clojure to remain beautiful, and that means the implementations must also be beautiful. There is a limit on how much the core team can say "That bug is only an implementation detail". If you take away all the implementation details, then Clojure is only a theory, not a real technology that can be used by real people to do real things.

In a truly ideal world, Clojure could be the practical Lisp that pushes itself to bring in as much of the experimental Lisp's beauty as is practical. I would love to see the best ideas from Racket and what Fogus refers to as the Fluchtpunkt Lisps:

http://blog.fogus.me/2011/05/03/the-german-school-of-lisp-2/

These are ideas that can make the world better. I have high hopes that Clojure will be the project that makes some of these beautiful ideas practical. I will be very sad if Clojure ends up like Ruby or Groovy or Scala, becoming a bit too muddy to reach its full potential.

Re: My Increasing Frustration with Clojure

#14

Post by village-idiot » Sat, Jun 11, 2016, 3:26 PM UTC

nidu wrote: 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.

Oh, that's really annoying too.

Re: My Increasing Frustration with Clojure

#15

Post by village-idiot » Sat, Jun 11, 2016, 3:30 PM UTC

catnaroek wrote: post #11

There are basically four possible attitudes to abstraction: (0) We don't need no stinkin' abstractions! Obviously not befitting a high-level language like Clojure, move along. (1) We enforce abstractions in our heads. Running into an undocumented scenario is undefined behavior. (Yes, in the C sense.) (2) We enforce abstractions via compile-time checks. Clojure won't have this anytime soon, move along. (3) We enforce…

Wow, wish I'd actually enumerated that list for the article. This is a really good summary of my points on the set/union type bugs.

Re: My Increasing Frustration with Clojure

#16

Post by agumonkey » Sat, Jun 11, 2016, 3:35 PM UTC

lkrubner wrote: post #13

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…

I kinda despise non dogfooding projects. Like realizing that IBM rarely ever uses it's own modeling tools and principles to develop internal or commercial software (at least arount that time). And yes I liked lisp because of its underlying beauty. Scheme did one step further. It reuses itself in many ways. That clojure implementation isn't leveraging it's own quality feels unlispy but alas... it's also a huge effort to blend an immutable first lisp onto a JVM ecosystem. Reminds me of Scala a bit.. one lead dev quit over frustration about the state of the compiler. Maybe seeking 'beauty' is just an immature phase and after a while whatever works enough for you to sell ...

Re: My Increasing Frustration with Clojure

#17

Post by daniel-levin » Sat, Jun 11, 2016, 3:42 PM UTC

Do you have any experience with attempting to fix these bugs and then submitting patches / pull-requests? Yes, the core team should just fix these bugs. But if they're receptive to upstream changes you want made, then that makes this much less of an issue, in my mind. An open source project's openness depends critically on the core team's acceptance of user patches.

Re: My Increasing Frustration with Clojure

#18

Post by sethev » Sat, Jun 11, 2016, 3:45 PM UTC

catnaroek wrote: post #11

There are basically four possible attitudes to abstraction: (0) We don't need no stinkin' abstractions! Obviously not befitting a high-level language like Clojure, move along. (1) We enforce abstractions in our heads. Running into an undocumented scenario is undefined behavior. (Yes, in the C sense.) (2) We enforce abstractions via compile-time checks. Clojure won't have this anytime soon, move along. (3) We enforce…

It seems disingenuous (in the blog post) to act as if Rich was saying that the results of applying union to a list were correct when he was clearly saying that the fact that it produced any value at all was an implementation detail.

Re: My Increasing Frustration with Clojure

#19

Post by aaron-lebo » Sat, Jun 11, 2016, 3:50 PM UTC

jonnybgood wrote: post #6

Clojure is not a community-driven language. It belongs to Rich Hickey and by extension Cognitect. The bugs that will be fixed and the features that will be added are the ones Hickey cares about. Not saying this is good or bad. It's just how Clojure development is ran.

This is the most realistic answer.

Steve Yegge was making similar criticisms years back, saying Clojure was "user-hostile". That's probably not fair and largely a matter of opinion (see the link for a back and forth), but it is another piece of evidence that says the Clojure community does things their own way. Not shocking, it's a lisp!

https://www.reddit.com/r/Clojure/comments/3jjit5/what_does_s...

Clojure development is opinionated, for good and bad.

Re: My Increasing Frustration with Clojure

#20

Post by dustingetz » Sat, Jun 11, 2016, 3:52 PM UTC

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 incorporated lessons of the first gen. Improvement is accelerating. So when the core team focuses on new features like CLJC, Spec, Transit, Transducers, Datomic, ClojureScript, they are doing things that only the core team can do. There are other more opinionated things (like frameworks) that the core team isn't suited to do, everyone's app is too different.

The thing i love most about clojure is that all the pieces seem to fit together and be working towards a grander architectural vision much larger than just a language or just a database. I use Clojure not because it lets me code my java/javascript stuff a little better, but because this grander vision makes impossible things possible. The thing I am trying to build is not possible in any other ecosystem today.

So I am willing to eat the many little pains described in the article, pains I feel every day, because the grand vision is so powerful, and hope that one day the little stuff will be better.