5 ms·

As a person who has and currently does work professionally in clojure (at multiple all-clojure shops): The smart engineer effect is extremely overblown. You w

As a person who has and currently does work professionally in clojure (at multiple all-clojure shops): The smart engineer effect is extremely overblown. You will hire smarter-than-average engineers, but with a caveat that no one talks about: they are all self-selected for being people who enjoy tinkering on computer science problems to a fault, and not necessarily your business. So the breakdown is that you get 10 super-smart people, but 9 of them are focused on myopic bits of code plumbing or reinventing APIs or something, and in practice you only have 1 smart person focused on your business. As the other 9 continue to reinvent wheels, the nature of clojure being small relative to other open-source communities means that eventually your shiny new clojure tools get replaced by better community offerings, except you don't have the bandwidth to switch over and start using them. Overall, velocity would be improved if you had hired 1 super smart engineer and 9 mediocre ones. It's important to note here that while technically clojure can interoperate with java or javascript, in practice everyone expects you to use poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly. This effect is 10 times worse for clojurescript in the browser, although it's pretty bad for clojure targeting the JVM as well.

beders 6y ago
> poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly. Care to elaborate? For example, re-frame, reagent have been stable, reliable libraries for years. In contrast to many JS libraries. JS interop has been virtually unchanged for years. What am I not seeing here?
- Scarbutt 6y ago
  Clojurescript relies on the closure compiler which doesn't play well with the Javascript ecosystem. Too much "busy work" https://dev.solita.fi/2020/06/25/taming-cljs-advanced-compilation.html https://dev.solita.fi/2020/06/25/taming-cljs-advanced-compil...
  - fulafel 6y ago
    The gains from the advanced optimizations mode under discussion there are nice and the setup is known to be a little finicky wrt dependencies. But it's opt in and rarely necessary.
    - Scarbutt 6y ago
      Unless you want to ship a 5MB browser bundle for a 'hello world', advanced compilation is not necessary, is obligatory.
      - fulafel 6y ago
        It's like 200 kB gzipped for hello world with simple optimizations. When you use webpack, you can use that ecosystem of space optimizers too.
tombert 6y ago
> in practice everyone expects you to use poorly-maintained clojure-ish libraries to paper over the java/javascript bits I cannot speak for anyone else, but as someone who writes a lot of Clojure (not much ClojureScript), I actually tend-towards the most-maintained libraries, and that usually just means Java. Personally, I think Clojure is a "better Java than Java", and I've never had a huge problem calling into the Java versions of libraries. For example, I've had fewer headaches using the regular Java Kafka bindings or JeroMQ than by using the "Clojure-ified" versions of these libraries. I absolutely hate Java as a language, but personally as an engineer it's hard to dispute that Java libraries tend to get a lot of money spent on them, and it feels silly to completely ignore that in some pursuit of "purity". This actually seems to be more-or-less the ethos of the Clojure engineers where I work, but maybe my situation an outlier.
- ryanmjacobs 6y ago
  > For example, I've had fewer headaches using the regular Java Kafka bindings or JeroMQ than by using the "Clojure-ified" versions of these libraries. As someone who is trying to decide how to interop Clojure + ZeroMQ, do you have any pointers for working with JeroMQ within Clojure? Yesterday, I was browsing/evaluating the Clojure libraries for ZeroMQ, and all them haven't seen git pushes in the last three years and have between 10 and 120 stars on GitHub -- but JeroMQ has recent activity and >1.8k stars, so I'd like to stick with that for sake of support/documentation/etc. -- (Caveat: ... not that GitHub stars are the best metric for quality... but they're not a terrible one...)
  - tombert 6y ago
    Honestly, I just went through all the JeroMQ examples ported from the guide [0], and translated them to Clojure. I added no dependencies outside of JeroMQ, and tried to port them in an as-idiomatic-as-possible way. It actually wasn't too hard once I wrapped my head around it, and it took me about 6-8 hours in total (spread over the course of a week or so), so not a huge time sink. This also had the (unintended) benefit of me getting pretty good with ZeroMQ (and networking patterns in general), so I think that time investment paid for itself several fold. I definitely think there needs to be a better messaging with the library support in Clojure; as it stands, a Clojure newbie might (very reasonably) look up "clojure zeromq" on Google, get a crappy, unmaintained library, and dismiss the language as having "bad library support", when in reality most of the Clojure veterans that I work with do the same thing that I do: when the Clojure libraries are bad, just use the Java ones. There are exceptions to this in rare cases; I haven't done a ton of ClojureScript, but the bit I have, I genuinely really liked the Re-frame framework. I'm not a frontend guy, so I'm speaking largely out of my ass, but I found it to be a lot more pleasant then vanilla React. [0]https://github.com/zeromq/jeromq/tree/master/src/test/java/guide https://github.com/zeromq/jeromq/tree/master/src/test/java/g...
aeoleonn 6y ago
At a contract job, I had to use ReAgent, ClojureScript's "this compiles into ReactJS" framework. Wow, what a pain-- all I could think is "Why don't we just use Reactjs?". Clojure itself is decent. But as you mention-- "n practice everyone expects you to use poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly.' That is indeed the problem I saw.
- pinchhit 6y ago
  I have noticed that our developers coming from javascript pretty much exclusively feel that way (and tend to write sharper UIs.) The ones who come from the JVM and feel more emboldened to write more frontend code thanks to reagent write UIs that don't satisfy product requirements, but are very happy with reagent. Not that devs coming from the JVM can't contribute! But there is some eyerolling from the devs coming from javascript when the primarily backend devs throw together a too-simple UI and wonder why everybody doesn't use reagent exclusively.
- jb1991 6y ago
  What did you find painful about Reagent? I used the first version of Om for many years, which by now is definitely old and outdated, but it still was much more enjoyable and productive than directly using ReactJS. Reagent is a small, simple library that makes interacting with React quite straightforward as well, so I'm curious your pain points.
  - aeoleonn 6y ago
    The lazy bastard that I am, I already knew ReactJS. ClojureScript's stack traces suck. I just didn't want to have to implement stuff in ClojureScript when I could write it in a language I was more familiar with. ReAgent/ClojureScript just seemed hacky. I don't remember specifics as it was almost 2 years ago.
- simongray 6y ago
  There are some questionable Clojure libraries, but Reagent is fantastic. Much nicer and simpler than React. For years it's been completely hegemonic in the ClojureScript space and it's definitely not going anywhere. I've done React+Redux and it was a much worse experience than Reagent, which deliberately builds on Clojure's native immutability-friendly state management solution (atoms) and is based entirely around functions.
fulafel 6y ago
Interesting, my experience in Clojure projects has been completely the opposite re your caveat: very pragmatic & get-things-done developers, and everyone-works-on-everything or nearly so style of working. The most used Clojure libs are well maintained and solid IME. Of course there are a lot of inactive ones too, it's natural especially as Clojure is not a young language anymore.
alexeiz 6y ago
> 10 super-smart people, but 9 of them are focused on myopic bits of code plumbing or reinventing APIs or something Hey, that's me! After 20 years I learnt to let go and start caring about the business a little bit more than about the code plumbing.

beders 6y ago

> poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly. Care to elaborate? For example, re-frame, reagent have been stable, reliable libraries for years. In contrast to many JS libraries. JS interop has been virtually unchanged for years. What am I not seeing here?

Scarbutt 6y ago
Clojurescript relies on the closure compiler which doesn't play well with the Javascript ecosystem. Too much "busy work" https://dev.solita.fi/2020/06/25/taming-cljs-advanced-compilation.html https://dev.solita.fi/2020/06/25/taming-cljs-advanced-compil...
- fulafel 6y ago
  The gains from the advanced optimizations mode under discussion there are nice and the setup is known to be a little finicky wrt dependencies. But it's opt in and rarely necessary.
  - Scarbutt 6y ago
    Unless you want to ship a 5MB browser bundle for a 'hello world', advanced compilation is not necessary, is obligatory.
    - fulafel 6y ago
      It's like 200 kB gzipped for hello world with simple optimizations. When you use webpack, you can use that ecosystem of space optimizers too.

tombert 6y ago

> in practice everyone expects you to use poorly-maintained clojure-ish libraries to paper over the java/javascript bits I cannot speak for anyone else, but as someone who writes a lot of Clojure (not much ClojureScript), I actually tend-towards the most-maintained libraries, and that usually just means Java. Personally, I think Clojure is a "better Java than Java", and I've never had a huge problem calling into the Java versions of libraries. For example, I've had fewer headaches using the regular Java Kafka bindings or JeroMQ than by using the "Clojure-ified" versions of these libraries. I absolutely hate Java as a language, but personally as an engineer it's hard to dispute that Java libraries tend to get a lot of money spent on them, and it feels silly to completely ignore that in some pursuit of "purity". This actually seems to be more-or-less the ethos of the Clojure engineers where I work, but maybe my situation an outlier.

ryanmjacobs 6y ago
> For example, I've had fewer headaches using the regular Java Kafka bindings or JeroMQ than by using the "Clojure-ified" versions of these libraries. As someone who is trying to decide how to interop Clojure + ZeroMQ, do you have any pointers for working with JeroMQ within Clojure? Yesterday, I was browsing/evaluating the Clojure libraries for ZeroMQ, and all them haven't seen git pushes in the last three years and have between 10 and 120 stars on GitHub -- but JeroMQ has recent activity and >1.8k stars, so I'd like to stick with that for sake of support/documentation/etc. -- (Caveat: ... not that GitHub stars are the best metric for quality... but they're not a terrible one...)
- tombert 6y ago
  Honestly, I just went through all the JeroMQ examples ported from the guide [0], and translated them to Clojure. I added no dependencies outside of JeroMQ, and tried to port them in an as-idiomatic-as-possible way. It actually wasn't too hard once I wrapped my head around it, and it took me about 6-8 hours in total (spread over the course of a week or so), so not a huge time sink. This also had the (unintended) benefit of me getting pretty good with ZeroMQ (and networking patterns in general), so I think that time investment paid for itself several fold. I definitely think there needs to be a better messaging with the library support in Clojure; as it stands, a Clojure newbie might (very reasonably) look up "clojure zeromq" on Google, get a crappy, unmaintained library, and dismiss the language as having "bad library support", when in reality most of the Clojure veterans that I work with do the same thing that I do: when the Clojure libraries are bad, just use the Java ones. There are exceptions to this in rare cases; I haven't done a ton of ClojureScript, but the bit I have, I genuinely really liked the Re-frame framework. I'm not a frontend guy, so I'm speaking largely out of my ass, but I found it to be a lot more pleasant then vanilla React. [0]https://github.com/zeromq/jeromq/tree/master/src/test/java/guide https://github.com/zeromq/jeromq/tree/master/src/test/java/g...

aeoleonn 6y ago

At a contract job, I had to use ReAgent, ClojureScript's "this compiles into ReactJS" framework. Wow, what a pain-- all I could think is "Why don't we just use Reactjs?". Clojure itself is decent. But as you mention-- "n practice everyone expects you to use poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly.' That is indeed the problem I saw.

pinchhit 6y ago
I have noticed that our developers coming from javascript pretty much exclusively feel that way (and tend to write sharper UIs.) The ones who come from the JVM and feel more emboldened to write more frontend code thanks to reagent write UIs that don't satisfy product requirements, but are very happy with reagent. Not that devs coming from the JVM can't contribute! But there is some eyerolling from the devs coming from javascript when the primarily backend devs throw together a too-simple UI and wonder why everybody doesn't use reagent exclusively.
jb1991 6y ago
What did you find painful about Reagent? I used the first version of Om for many years, which by now is definitely old and outdated, but it still was much more enjoyable and productive than directly using ReactJS. Reagent is a small, simple library that makes interacting with React quite straightforward as well, so I'm curious your pain points.
- aeoleonn 6y ago
  The lazy bastard that I am, I already knew ReactJS. ClojureScript's stack traces suck. I just didn't want to have to implement stuff in ClojureScript when I could write it in a language I was more familiar with. ReAgent/ClojureScript just seemed hacky. I don't remember specifics as it was almost 2 years ago.
simongray 6y ago
There are some questionable Clojure libraries, but Reagent is fantastic. Much nicer and simpler than React. For years it's been completely hegemonic in the ClojureScript space and it's definitely not going anywhere. I've done React+Redux and it was a much worse experience than Reagent, which deliberately builds on Clojure's native immutability-friendly state management solution (atoms) and is based entirely around functions.

fulafel 6y ago

Interesting, my experience in Clojure projects has been completely the opposite re your caveat: very pragmatic & get-things-done developers, and everyone-works-on-everything or nearly so style of working. The most used Clojure libs are well maintained and solid IME. Of course there are a lot of inactive ones too, it's natural especially as Clojure is not a young language anymore.

alexeiz 6y ago

> 10 super-smart people, but 9 of them are focused on myopic bits of code plumbing or reinventing APIs or something Hey, that's me! After 20 years I learnt to let go and start caring about the business a little bit more than about the code plumbing.