Live data from Hacker News

My Increasing Frustration with Clojure

ashtonkemerling.com

181–190 of 240 posts

Re: My Increasing Frustration with Clojure

#181
post #152

And that he is a well known troll.

Not so well known that this doesn't cross into personal attack. Please don't like this here. We detached this comment from https://news.ycombinator.com/item?id=11884356 and marked it off-topic.

It is in his post history here, I didn't know "look at the other things this person says" was considered a personal attack.

Re: My Increasing Frustration with Clojure

#182

The thing to realise about Clojure is that it isn't an open source language like Python. It is a language controlled very tightly by Rich Hickey and Cognitect. Major work is done in secret (transducers, reducers, spec), then announced to the world as a "Here it is!" and then suggestions are taken. This goes well mostly, though it took a lot of outside persuasion that Feature Expressions weren't the best idea, and to…

Please everyone, upvote dantiberian's answer. He nails it.

The moment you get over expecting Clojure to behave like a typical "open source" project and understand it is Rich Hickey's personal project (+ Cognitect's), which happens to also be available to you, if you want to use it, then the whole thing makes more sense. Some frustration disappears. You know where you stand, and what to expect.

Hickey and Cognitect have every right to run it the way they like. IMO, the only thing they don't do right is to communicate their intentions. There's a pretense maintained around it being an "open source" project, when it really isn't, not in the way that python is open source.

Use it if it works for you. Otherwise don't. Don't expect to have a voice, and don't expect you'll be able to contribute much, and don't expect that something will be fixed unless it suits Hickey's Cognitect's agenda.

I use ClojureScript, knowing and accepting these things (with some sadness), because I think the language gives me a competitive edge.

Re: My Increasing Frustration with Clojure

#183

I'm sad to see someone so clearly disappointed by this interesting and innovative product. But considering his frustration, I think it's fair he get a refund. But that's not possible, because it is free. In his own words, he writes Clojure all day and loves his job, all because of this interesting and free product called Clojure. Clojure is far from a perfect language, but what language is? I also love C++ and you'd…

Just because something is free do not make it holy and free from critique.

I left Clojure because its inherit both Java and Lisp flaws: memory hungry, difficult setup, enterprise frameworks and hard to read, impure and slow.

I believe that there still chance for Lisp in Web Assembly.

Re: My Increasing Frustration with Clojure

#184

Clojure is a language for people who know what they are doing by people who know what they are doing. If you're giving sequences to the set functions, you either (A) don't know what you're doing or (B) have yet to discover that clojure.set is not what you want. Set union can't be done efficiently on arbitrarily sized sequences. At least one of the two arguments needs to offer fast set membership; ideally the larger o…

> Clojure is a language for people who know what they are doing by people who know what they are doing.

Oh, goodie. I'm part of an elite club with high barriers to entry.

Re: My Increasing Frustration with Clojure

#185
post #178

Earlier quoted context omitted.

I'm not questioning that python api isn't clear. Neither is clojure one. Both require the user to read them in order to properly apply them. I think pythons resolutes only seem less surprising because someone would be used to them? Maybe that coercion is easier to reason about. Im honestly not sure. Like this example: In [19]: s = set([1, 2, 3]) In [20]: s.union({"x", "y"}) Out[20]: {1, 2, 3, 'y', 'x'} Is that more c…

Oh, I think I understand your question. This is a set literal, not a map literal: {"a", "b", "c"} This is a map: {"name": "Fido", "age": 8} Note the colons. The point I was making is that Python doesn't make performance trade offs with these set APIs. Set union is in no way surprising. It either gives the correct intuitive result or raises an exception because of incorrect argument types.

I'm having quite the day. I think switching between clojure and python is frying my circuit. I know the difference between a map syntax and set and somehow managed to use set in place of map. I think this happened in part because my point is that any output of union(set, dict) is up to the language designer and has no basis in set theory (though i would be interested to here other wise)

    >>> s = set([1, 2])
    >>> d = dict(x="hi")
    >>> s.union(d)
    set([1, 2, 'x'])
apologies for the confusion... I need to proof read my comments more throughly.

Re: My Increasing Frustration with Clojure

#186

Clojure is a language for people who know what they are doing by people who know what they are doing. If you're giving sequences to the set functions, you either (A) don't know what you're doing or (B) have yet to discover that clojure.set is not what you want. Set union can't be done efficiently on arbitrarily sized sequences. At least one of the two arguments needs to offer fast set membership; ideally the larger o…

> they work crazy hard to build and shepherd something awesome for free. I'm not so sure about that. I'd say that Clojure now exists and thrives to help Cognitect make money. This is no way a bad thing, only a reminder that there is no such thing as a free lunch. In a similar vein, Go exists to help make Google money. The original purpose of open sourcing it was different for Google (make the language more robust/bet…

> The original purpose of open sourcing Go was different for Google (make the language more robust/better)

I'm not so sure about that. I like the 'baseball cap' argument more. The quote is about React, but it may be relevant for Go as well

> Facebook doesn't care if you use the Web, it only cares that you use Facebook.

> So why release an open source Web framework at all? Because Facebook is battling Google for engineers. So you've got a big fight between two companies over which company is the coolest place to work, and both of them are companies that your grandparents love. How are you going to win this fight? One way is to have the hippest Web framework.

> Basically, both Google and Facebook are desperate to find a baseball cap that they can put on backwards. Angular is Google's baseball cap. React is Facebook's.

https://www.pandastrike.com/posts/20150311-react-bad-idea

Re: My Increasing Frustration with Clojure

#187

Earlier quoted context omitted.

The C standards take the rather unique approach of dividing behavior into 4 categories: * standard-defined . You can rely on this; if the code you write is limited to this, you're good to go. * erroneous . The compiler is supposed to give you an error message when you write code like this. * implementation-defined . A particular compiler can do something reasonable with the code. If you write code depending on implem…

Thanks for this long and elaborate reply. Clojure tries to put as many user faults into "erroneous" as possible but in the OPs complaint it doesn't have the required information at compile time because it is typed dynamically. This is the fundamental problem with dynamic typing that more problems keep ending up in runtime. Behavioral concerns like security etc. are then often addressed by runtime checks. Clojure avoi…

Clojure tries to put as many user faults into "erroneous" as possible

I would absolutely disagree with this. Clojure has long had a Garbage-In-Garbage-Out philosophy, which puts it clearly into "undefined" territory. The examples with clojure.set are pretty clearly GIGO in my opinion, but "erroneous" would mean a runtime check and an exception clearly stating which invariant was violated, not returning something totally unexpected.

You could argue that it's under "implementation-defined", where the number of implementations is one, but I don't see how you could consider the set operations accepting and returning non-set things as consistent.

Re: My Increasing Frustration with Clojure

#188

The thing to realise about Clojure is that it isn't an open source language like Python. It is a language controlled very tightly by Rich Hickey and Cognitect. Major work is done in secret (transducers, reducers, spec), then announced to the world as a "Here it is!" and then suggestions are taken. This goes well mostly, though it took a lot of outside persuasion that Feature Expressions weren't the best idea, and to…

Please everyone, upvote dantiberian's answer. He nails it. The moment you get over expecting Clojure to behave like a typical "open source" project and understand it is Rich Hickey's personal project (+ Cognitect's), which happens to also be available to you, if you want to use it, then the whole thing makes more sense. Some frustration disappears. You know where you stand, and what to expect. Hickey and Cognitect ha…

I agree - this is the only right answer. Like you, I'm sad to have to accept it, but it's the only way to a frustration-free (or lower-frustration) Clojure experience.

Re: My Increasing Frustration with Clojure

#189

Earlier quoted context omitted.

A+ extreme reductionism. I never said "nothing is free", nor implied that, but merely that users need to cognizant of the goals of "free" language maintainers (especially when there is a corporation rather than a person as BDFL) that do not necessarily align with the goals of the median or average user. Now that we are on this topic, I'm starting to think maybe it's worth paying for a programming language so that the…

There is a history here. Please read: 1. https://web.archive.org/web/20100220100027/http://clojure.or... 2. https://web.archive.org/web/20140704050611/http://clojure.or... My own interpretation: programmer culture has such problems that someone actually considered corporate funding healthier than user donations.

There are many definitions of the term 'healthier'. But the links are pretty amusing. And now we have a first fork https://github.com/jaunt-lang/jaunt

Re: My Increasing Frustration with Clojure

#190
Interesting bit to me is the communication problems, not so much the technical ones, we live with tradeoffs.

The thing is communicating takes time and busy people are entitled to prioritise "doing" over "talking".

As a community, Clojure is defined by the promises made and the processes established. I think "Brand Clojure" is defined by some truly wonderful attributes but it could be improved.

Perhaps this could this be fixed with process? For example

* Document architectural decisions [1] [2]

* Close tickets WONTFIX with a link to the relevant architectural decisions

Make that a process/promise so that it becomes a consistently applied approach and it would give the community confidence they are being treated well, heard and respected. "Brand Clojure" becomes more lovable.

But these processes also take time and we don't want to burden Clojure core devs. (More realistically, I doubt they'd allow us to impose on their precious time.)

So, can this happen without adding overhead for the core developers? I don't know. It's an interesting question though. Can we learn from others online communities on this topic? Are those who do this well based on dev leads who are naturally inclined to communicate? Are any using community funded positions to deliver on communication" outcomes?

Sounds like a community advocate/support role:

* Triaging tickets ensures inbound communication is effective and helpful. That helps by saving core dev effort. That helps avoid confusion on both sides.

* Generate architectural decision docs which can be linked from tickets

* Ensure WONTFIX doesn't feel like a dead end. Link to ADs, blog topical workarounds.

* Keep architectural decision docs fresh as consequences become more apparent over time.

Few ideas in there. Just a thought exercise.

--

[1] See Documenting Architecture Decisions http://thinkrelevance.com/blog/2011/11/15/documenting-archit...

[2] Is the 'garbage in/garbage out' architectural decision documented?

Post reply on HN