Rich Hickey's response to “On whose authority?”
reddit.com
reddit.com
I really wonder this whenever I see some new-fangled open source project putting out a CODE_OF_CONDUCT.md stating community is a top value. Look, you are primarily writing software not trying to foster a community. A community can be helpful to produce great software, but a community can also mean additional mental and emotional toll, and clowns introducing discussions with little merit.
The dictionary definition of community:
> n. A group of people having common interests: the scientific community; the international business community.
The "Clojure community" is a group of people having a common interest in Clojure.
The sentence doesn't disparage the community, or discourage engaging with the community. Rich Hickey's 1000 word response makes the case, and is evidence itself, that he and other Clojure contributors care about the community. He is explaining that he will continue to design and develop the language as a Rich Hickey thing instead of a consensus or community driven process.
> A true community respects the autonomy of its participants... the ultimate authority and stewardship of Clojure remains with me
I actually read the response first and the weird thing is: I couldn't really tell you what exactly the response is replying to. I feel like the whole thing is a huge amount of verbiage expressing frustration and broken motives but any actual solid facts mentioned are peripheral at best to what's being said.
I could write multiple pages on how I fell out of love with Clojure but I doubt it would benefit anyone and it'd be a huge pain to do.
Clojure is the product of a singular aesthetic, for better or worse.
In the poorly written Chris Zheng rant, there was a link to a more mature blog post by Eric Normand.[1] (It would have been better use of Rich Hickey's time to ignore CZ and respond to Eric, but alas.)
In any case, CZ is upset that Cognitec drives the evolution of Clojure and its libraries more than the community outside of Cognitec. E.g. one of his frameworks he liked (Noir) was ignored while Cognitec pushed its own.
Here's my question, what mainstream programming language community actually meets CZ's criteria that the outside community drives the language with equal or more power than the internal team? It's certainly not Golang (Rob Pike, Brad Fitzgerald, Ross Cox, etc), nor C# (A Heilsberg, et al), nor Clang (Apple devs). Yes, they have github repos but the pull requests from outsiders is not the same priority as the internal teams agenda. Which language & community actually meets CZ's ideal?
I don't think it's necessarily the responsibility of a project to validate its users. But there are examples like Node where the emphasis is on retaining and involving contributors.
https://medium.com/the-node-js-collection/healthy-open-sourc...
I'm not sure it fits everywhere but based on later posts, it seems to be working for them.
That's a weasel-word. For all we know, you could be using it as a synonym for a programming language community that's controlled by a corporation. Then your whole argument would be a tautology.
The number of facts like this that at just plain wrong in the OP just add to the offensive tone. Why should I listen to someone who has no respect for they truth?
Tim Ewald **
Bob Calco ***
Jamie Kite **
Jay Martin
David Nolen *
Mike Nygard *
Russ Olsen *
Marc Phillips
Nola Stowe
Stuart Sierra *
Luke VanderHart *
---
(honorable mention) _halgari == Tim Baldridge *
* Currently @ Cognitect
** Ex-Cognitect
*** Affiliated (https://cognitect.com/services.html)I'd suggest Perl might get close to that.
I love Clojure and many of its libraries, but I think there are some aspects inhibiting its growth. Here they cover a few of these aspects:
http://www.lispcast.com/cognitect-clojure
It worries me a bit, since I would really like to have a practical Lisp that is on par with other mainstream languages in terms of tools, libraries and community. Clojure is quite healthy now, but some items need to be addressed in order not to fall behind.
I'm also quite enthusiastic about Racket getting to run on top of Chez Scheme, which may give it a bit of momentum. Besides, Clasp, with its LLVM capabilities, is the most promising Common Lisp to me right now. Sadly, it's mostly one-man project and the whole Common Lisp scene is a bit stagnant.
I can't speak for the author Rich is replying to, but I have seen many in the community comment on the opaqueness of Cognitect, even comparing it to Apple. That's not necessarily bad, but it does have the unfortunate effect of letting some people's imaginations run with negativity in their assumptions about a company's motivations.
Even if Cognitect did make money on Clojure, not sure why that should be a source of frustration. It's quite an amazing language, people should have some reward for their contributions to the industry, right?
[0] http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScal...
I don't know what you mean when you say the semantics are different between the two versions of the language, they really have the same overall design and I feel like I'm working in the same language when I switch between them.
Haven't used Clojurescript but I'd imagine the code-change-reload cycle is quite fast compared to Scala.js, which while absolutely excellent in many ways, suffers from the dog slow compiler that is scalac (Scala collections blowing up generated binary size is the other drawback that comes to mind).
I work on a 20K line enterprise CLJS app. Due to incremental compilation where only recent changes need to recompile during development, each code change (meaning, saving some source files) is on average 1 second of recompilation. With the Figwheel tool, there is no manual reload required, as it automatically refreshes the browser to reflect your most recent change.
That's actually fairly slow, I'd expect pretty much instantaneous (hot reload is nice though). The overhead of Bucklescript, for example, is at most in the 10s of ms for code changes (saw a 2017 Strange Loop talk where the presenter claimed 200ms to compile the entire project).
Scala.js is around 2 seconds for shallow changes (affecting only one source file), which over time is a productivity drain, those seconds add up when doing front end work.
https://clojurescript.org/about/differences
In my experience, all of the stated benefits of clojurescript become more and more tenuous as your intensity of use increases. Hello world seems fantastic, todomvc still seems pretty cool, but by the time you’re doing full size apps of meaningful complexity, you really start to see the limitations. In order to get any meaningful performance out of it, I ended up having to rewrite and experiment like crazy...the code looked like nothing I would have written in Clojure, using completely different idioms and data structures. And while the prototyping was fast, in the end it took me far longer to write and then iteratively optimize than it would have to write an equivalently fast version in scalajs or typescript. Maybe your experience is different, but my experience is my experience, and it most definitely is not baseless.
This is also why most the time you can just tack on a "c" on the extension and you have something that works on both clojure and clojurescript.
Performance is not an inherent problem of clojurescript. It was just the way you coded you prototyped your app. Your experience is valid but don't blame the problem on the tool when it was the way you solved your problem before you optimized it.
I absolutely mean no disrespect to you but I don't want your comment to dissuade others from trying out what has essentially been a utopia for me. It has allowed me to build non trivial webapps without having any familiarity with functional programming or lisp. The feedback loop is so damn tight that I was productive without knowing much of anything.
But maybe that's okay. If the everyone else is constantly updating their build tools to every flavor of the month and having to learn new versions of javascript, that gives the few of us who are mastering clojure/script a bit of an advantage.
And I actually test my clojurscript lines that I write in a JVM repl! Semantics between the two languages are virtually identical, I can test out my ideas for the JS target in a Java environment. Perhaps the OP has a different definition of "semantics".
In clj:
> (+ 1 "1")
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Number
In cljs:
> (+ 1 "1")
"11"
Now I get it...not that big of a deal, right? That's what I would say given a trivial example of something like this. Sure, this problem might not come up very often. In fact, for a team that I worked with, it only ever came up once...it's just that that one time that it came up, it corrupted 3 months worth of data. Would tests have caught this? Of course...but if you are confident in your knowledge of the clojure language, and you assume clojurescript is semantically equivalent, you would expect an exception to pop up in your repl during development, so if it works fine in clojure, why write a test for it in clojurescript?
I understand why the cljs designers would do such a thing...think of the performance implications of having to generate type checks code for every possible arithmetic operation! But it absolutely was a context switch for that team (full stack clj/cljs), and the consequences of the developers not correctly context switching was horrific. Nothing quite burns bridges with entire languages like silent errors do.
I'm fine with people trying clojurescript. FWIW, my personal experience with it was never as bad as that one team's experience. Maybe they'll never come across such a dangerous situation, hopefully they don't. But on the rare occasion that some third party web service dependency decides to serialize BigDecimals as Strings instead of Doubles, they deserve to be warned.
WARNING: cljs.core/+, all arguments must be numbers, got [number string] instead. at line 1
1) You wrote:
> It’s just too hard to replicate one dynamic language’s semantics in another dynamic language without embedding huge and slow runtimes along with it.
I don't understand this. Clojurescript's "runtime" itself most compiles away in Closure advanced optimizations stage (in fact a compiled Hello World Clojurescript app is only 1 line of JS -- no added runtime at all). I don't understand what about the Clojurescript runtime process should be "huge" and "slow." This contrasts with other languages like Elm that do indeed embed a large runtime with the program, but Clojurescript does not do this.
2) I am genuinely curious what performance problems you had. I'm working on a very large Clojurescript app that processes dozens of real-time incoming data points every second over a websocket and performs real-time analytics and graphical display. If ever there was a test for performance, this would be it. Aside from the rare and simple bottleneck that needed some extra thought (maybe 2 or 3 such moments in 3 years of development on the project), there have been nearly no obstacles relating to runtime speed for the app. The 2 or 3 bottlenecks I mention had minor solutions and would have occurred in any language, and were very easy to resolve. And Clojurescript's fast, immutable data structures have inspired major libraries and even other languages entirely. They are battle-tested and performant. So I'd like to know what specific issues you had, as that would be educational.
Clojurescript now does a good job with Closure's advanced optimizations, but it has upper limits to how well it can do. For a full sized app, you can expect clojurescript's runtime code to bloat to 100k to 150k...which isn't the end of the world, but it certainly isn't good either.
While clojurescript and javascript are both dynamically typed, their type systems are semantically different. In order to approximate the semantics of the clojure type system, clojurescript has to build its own dynamic type checking system into a system that is already dynamically type checked. FWIR, the reason that clojure.spec was built into the standard distribution of clojurescript (whereas it is an optional library in clojure) was so that the compiler could perform type erasure on code with type hints...something done by default in static languages like bucklescript, scalajs, and typescript.
So while clojurescript does a good job with dead code elimination specifically, thanks to the closure optimizer, it is still a language that is inherently hard for compilers to otherwise optimize.
> 2) I am genuinely curious what performance problems you had. I'm working on a very large Clojurescript app that processes dozens of real-time incoming data points every second over a websocket and performs real-time analytics and graphical display. If ever there was a test for performance, this would be it. Aside from the rare and simple bottleneck that needed some extra thought (maybe 2 or 3 such moments in 3 years of development on the project), there have been nearly no obstacles relating to runtime speed for the app. The 2 or 3 bottlenecks I mention had minor solutions and would have occurred in any language, and were very easy to resolve.
The internet is full of examples of clojure programmers asking how to optimize code up to the already pitiful levels of performance that you can get out of javascript. Every language has it to some degree, but for some reason, it was always a 10x-100x difference for me. Collections in particular were always really bad for me. And the suggestions I received from more experienced clojurists always ended up pushing me away from what I considered to be idiomatic in clojure. Use defrecord instead of hashmaps, use javascript arrays or vectors instead of seqs, use goog.stringbuffer instead of str, use type hints whenever possible, etc.. Fast clojurescript and "idiomatic" (whatever that is supposed to mean in a lisp) clojure were far enough apart that it might as well have been scheme vs clojure.
> And Clojurescript's fast, immutable data structures have inspired major libraries and even other languages entirely. They are battle-tested and performant.
Clojurescript's immutable data structures are indeed pretty fast for immutable data structures run on a javascript runtime. But they are hardly fast. In fact, here[0] is an example of what I was talking about before: cljs written in an idiomatically clj style that performed terribly when used in cljs. And the answer on how to speed it up was to make it more like javascript!
I'm well aware of the rounds of praise that Om got when they showed how using cljs' native immutable data structures sped up React code over that written in javascript. I'd be careful to extrapolate too far with that. That optimization happened to involve a niche benefit of immutable structures (equality checking can use O(1) reference equality instead of O(n) structural equality) addressing a niche bottleneck in React (equality checking in the virtual dom). Overall, immutable datastructures tend to be about the same speed on most operations, but drastically slower on some operations, and drastically more memory hungry to boot. On servers with knowable processing power and knowably large quantities of jvm memory, that's often a tradeoff worth making for the semantic benefits of immutability. On some random user's computer using whatever javascript VM that they likely chose without consideration for how I would use it, I always felt bad making that tradeoff.
[0] https://stackoverflow.com/questions/21721028/how-to-improve-...
Here's the question: would Rock Hickey be Rich Hickey without Clojure? Would Cogitech exist without Clojure?
I understand both sides. I know the frustration of living with someone's arbitrary decisions. I also know the frustration of getting nothing but attacks from something I have worked hard to give away.
But Hickey has a higher standard here. He's gotten a lot more from the community than he admits in his response. It reads like he wants sympathy for all he has missed ot given away because of his work on Clojure. That's not a good response.
I wish Rich had been able to find/take a different path and developed more of a community with a "social contract" rather than keeping clojure a semi private project which users should be grateful for the ability to use. It would bring more participation from a wider community which would make the language and community far stronger in the long run.
Recent interactions I've had with the ReasonML project are night and day different than clojure.
At this point it feels like there needs to be a clojure like language (fixing some problems like startup time) that embraces more of a social contract with the community.
What I've realized as I grown older is that the majority of people are not worth my time. Loads of people will actively waste your time and talk about things without knowledge. If you listen to Rich speak in any of his presentations or interviews, it's pretty obvious he knows the same thing and his inner circle are extremely intelligent. If you want to progress you must eliminate the garbage and keep the most quality people you can around you.
We now have like 5 main versions and variants of javascript that came out in the last few years that all look like complete rubbish (purely my opinion). There seems to be a new build tool coming up every 3 months. Everyone is making a library for things as basic as calling an API or padding a string. At one point not so long ago I was one of the programmers who needed said libraries to get work done.
The code for clojure is open source. If anyone absolutely must use clojure they can do a better job than Cognitect just fork it. Or keep learning the new version of javascript that inevitably comes out every year.
> And, if you are talking about Clojure, you are talking to me. The indirection doesn't mask the attack on people, their work and their choices.
> I have to say now to those for whom such expressions are cathartic - they hurt people, a lot. I don't believe the sentiments in the post are widely held - most people who are happily using Clojure aren't as vocal. But it doesn't take many arrows to bring someone down.
> Every time I have to process such a diatribe and its aftermath, and its effects on myself, my family, and my co-workers, I have to struggle back from "Why should I bother?", and every time it gets harder to justify to myself and my family that it's worth the time, energy and emotional burden. Every time a community engages with such a diatribe without calling it out, and decrying its tone, the civility of our discourse and treatment of others heads further down the drain.
These are the people who're building the technology we're using, and if something is hurting them and making them not want to go on with their work then that IS bad for technology. You might not care either way for the debate, but no-one should tolerate the tone that the original author used.
If you can't do that, you can't have debate, or science. You can only have tribalism and identity politics.
I believe the original post that Rich Hickey is responding to was more a misguided attempt at humor and being provocative than an actual serious attack.
Really? It seemed very earnest--jerkish, but earnest--to me.
Now that the party is over and sunrise begins to reveal the plastic fairy lights and overdone makeup, I begin to question my life as well as the values that I am looking for within it.
And the opening was just shock value, or an emotional outburst, not that he hates and wants to move on.
...Fuck Clojure. There I've said it and God it feels good.
More misguided than malicious, which is how I would interpret it if the intent was purely earnest.
is it? solely? so-called "debate" is a two way street, right?
sometimes "attacks" are sloppy and vicious, and it's a bit entitled to expect other people to pick apart your messaging to glean the signal in the noise.
as humans, communication is a physiological process. pretending it's cold machinery rarely ends well.
I felt that Rich's response was fair. There is so much frustration and pain in the search for perfection. He has given his heart and soul to the language so of course it was expected. I'm really glad he still cares so much for the language. It's rare to see such a raw, passionate reply like that and I know that the language is in great hands.
Of course Clojure zealots lapped it up.
What's the takeaway: avoid Closure because of one drama? Rich is right about everything? Copmuters are terrible?
I acknowledge that in my OP. Do you think it is possible that there is a site more focussed on Lisp stuff than HN that you are simply unaware of?
Btw Closure and Clojure are two different things.