Fork me on GitHub

Sometimes I feel like there's so much Clojure bashing. Comments like this: > Not sure if it is still the case, but Circle used Clojure/Om [1]... when I heard them say they did that so many years ago, I knew right away it would end up being something nobody wanted to work on. > Sure enough, just checked, Om was abandoned [2] and the person blogging about how great everything was is long gone [3]. This is the absolute definition of tech debt. > Or things like this: > > > My immediate reaction is to think less of them, I immediately go: Oh, they must be a bad developer, don't really know what to use, or how to use things, don't understand fundamentals, and kept thinking some framework/language was going to magically make them good, went chasing for that, found Clojure, failed even harder, and now blame it for their failures. I know its a knee-jerk reaction, but I can't help it 😛 Now if I try to be more fair, I don't really know why these people think that, or were not successful with Clojure, maybe it wasn't them, though I fail to see what else it could be given I am quite successful with Clojure, and given they tend to provide Clojure as their reason for failure and not other circumstances, leaving Clojure or them being the only constant. But I also never failed because of any particular language or framework, I'm not more successful with Clojure than I was with PHP, Perl, ActionScript, C#, C++, or Java. The only difference is I am happier, have more fun, and tend to get things done faster in Clojure, probably as a result of enjoying myself more. Clojure also has given me more opportunities to learn new things. Every time I failed, it was about other things, didn't understand the problem well enough, some things were too hard for me in the scale, performance, data-structure, algo, or just complexity of the requirement, scope creep, lack of time or funding, legacy constraints, too much data, too much ambiguity, constantly changing requirements, attrition, constant churn, accrued tech dept, etc. It was never the language. I think what gets me is that those people specifically seem to blame Clojure for their shortcomings, like they're on a mission, it's that behavior that triggers a red flag and makes me think maybe they're not very good developers. Anyways, kind of curious about other people's thoughts on my random rambling 😛 P.S.: I do acknowledge the business challenge of finding qualified Clojure devs that know how to code in Clojure when the initial employee who did leaves, that's the only argument I can't deny, it is hard to go against the market momentum for technologies and talent.

🙌 2
Drew Verlee03:05:01

For the type of work i want to do, Clojure is a great tool. I think anyone that can't leverage the Clojure, java and javascript ecosystem to solve there problem is probably searching for a scapegoat to some extent. i'm looking at this blog post. I feel like his target audience is himself. It goes in so many directions i'm at a loss as to what to take away from this.

😆 2
Bart Kleijngeld06:05:44

Regarding that Boring Technology blog post, to me it doesn't come across as bashing Clojure specifically, but the argument is made to use battletested and mature tools in favor of new shiny/niche stuff. And it sounds like a reasonable argumen to me, even though I don't like it ;). With languages like Clojure and, say, Elm you are more at risk that active development of libraries diminishes for instance. In some cases even the language itself. If you stick with good ol' boring Java (please let me use Clojure...), you do get a lot of safety that way. That being said, you make a great point that I think is often missed: joy of use. Not only because of increased production value (which I agree is a consequence), but also because we simply deserve it. Also, I think the expressiveness of Clojure can make one faster regardless of how much fun you deem it to be. Thanks for sharing, interesting read.


I think "innovation tokens" proposal misses the mark. It sounds pragmatic but really isn't. The bigger questions are: What is the right tool for the job? Do you have the expertise to execute with that tool? I feel like if someone can't answer the first question and underestimates the second question, they're in trouble regardless of what they do.


Also Clojure uses a programming model that has been there for half a century and two of the most mature and widely adopted platforms. Basically zero "innovation tokens".

Daniel Jomphe11:05:35

Yes, I've been keeping my tightest watch on Clojure since 2008/9, and I see it's so mature in so many aspects that I certainly feel at ease saying it fits the bill of Choose Boring Technology. Yes, its tooling continues to evolve (a whole lot!) and that makes it much less boring, but hey, other old technologies continue to improve likewise: • 1958 LISP... • 1985 C++ • 1988 Perl • 1991 Python • 1994 PHP • 1995 Ruby • 1995 Java • 1995 JavaScript • 2000 C# • 2007 Clojure clojure, a spawn of LISP 1958..., born on Java JVM 1995...15 years! • 2022 They're all boring. :) Clojure is ready to be that boring technology which we secretly love. 🙂 This rant done, I must say, @U0K064KQV, that I enjoyed a lot your perspective. You never failed because of a particular language or framework, you're learning more and happier with Clojure, and recruitment of senior Clojure devs is harder. BTW I'm so thankful I could finally transform a job into a clojure job!!

👍 4

I have a friend that calls Clojure a "hipster language". To him, Python was always the no-brainer correct choice. Except for sometimes a little bit of C.

😁 1

Me, when Clojure is the target of the "innovation tokens" critique: "hey, that's way off base, I'm not sure that's the right way to think about it :man-gesturing-no:" Me, when Kubernetes is the target of the "innovation tokens" critique: "wow yes I totally agree 💯"

😂 3
Asko Nōmm18:05:34

Imo, people are people, and people reject/are afraid/do not like things they do not understand. In similar vain I see a lot of people try to use Clojure like they have used C# or JavaScript and then get upset that it’s not as optimal for them in comparison, when the whole point of Clojure is to have your REPL open and evaluate expressions.

Asko Nōmm18:05:30

But they’ll say things like, oh start-up is slow, so many parentheses (presumably they do not use a Clojure friendly editor?)

Stef Coetzee05:05:06

Slide 55 might even be seen as a justification for using Clojure(Script): “We should generally pick the smallest set of tech that covers our problem domain, and lets us get the job done.”


I think part of this is that the workflow and expectations around the tech are different. Look at all the arguments around what constitutes a REPL. A lot of people outside the ecosystem just thing we're being overblown about the value of them and for some it probably has little to no value because it doesn't fit their mindset. I mean I was perfectly happy working with clojure when I started, because I figured out early how to write small expressions and building my code in a bottom up style was a really nice fit for how I thought about stuff. However, over the years my workflow has dramatically improved by understanding what the norms are around some tools and how to fit them to my workflow. Heck there's still stuff I'm leaving on the table these days as I don't really know how to use REBL and it's equivalents well... In my mind the admonishment to use boring tech is very much a statement to be smart about what you pick, it's always nice to play with the new shiny, but if you're building something serious, focus on making sure that you understand what you're building in very well, because if anything breaks, you probably will need to fix it. From my perspective clojure does this really well, because I can keep going down if stuff doesn't work. Tools like alter-var-root, with-redefs, etc are amazingly powerful for giving you fine grained control as to what's actually running while not ending up in fun yak-shaving land of "a library is broken, time to check it out, figure out how to build it so I can fix the bug" instead of just, "override this please".

Drew Verlee03:05:12

Whats a general word to describe "second, minute, hour, day, month, year" ... "time-unit"?

Cora (she/her)03:05:05

ChronoUnit sounds like a group of time traveling crime fighters and so of course I absolutely love it

😆 12
☺️ 1

java.time calls these TemporalUnits, of which ChronoUnit contains a bunch of implementations


a unit of time/calendar is a TemporalUnit a unit + a scalar is a TemporalAmount


Good point @U050ECB92! Pedantry is important with terminology.


i just gave an internal talk on java.time


the pedantry was fresh


You must be a glutton for punishment 🙂


I find myself round-tripping from java.util.Date -> java.time.* to perform date math -> java.util.Date for interop with other stuff and it's always so painful to figure out exactly which paths I need for those -> steps 😞


I rather like java.time 🙂 . There's some class-y crap in it, but on the whole, great


The sign that java.time is a pretty decent api is that we don't need wrappers to use it and have it be idiomatic enough


Yeah, I initially was using as a wrapper around it -- because it simplifies the back and forth conversions -- but I'm slowly moving away from that and using raw interop in all new code.


I use tick, since I prefer having the same API in both frontend and backend.


Cljc Java time gives you that too^


ok, but even so, I still prefer tick. Written by the same guy BTW.


If we were doing cljs and trying to share code between the front end and back end, I suspect we'd prefer and/or tick 🙂

Cora (she/her)03:05:05

unit of time, yeah