This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (8)
- # babashka (6)
- # beginners (55)
- # biff (8)
- # calva (11)
- # cider (4)
- # clj-kondo (6)
- # cljdoc (23)
- # cljs-dev (22)
- # clojure (89)
- # clojure-brasil (3)
- # clojure-europe (47)
- # clojure-indonesia (1)
- # clojure-nl (1)
- # clojure-spec (3)
- # clojure-uk (5)
- # clojurescript (67)
- # community-development (2)
- # conjure (29)
- # cursive (2)
- # datalog (29)
- # datomic (41)
- # defnpodcast (4)
- # emacs (15)
- # google-cloud (5)
- # holy-lambda (6)
- # hyperfiddle (3)
- # introduce-yourself (8)
- # jobs (1)
- # malli (19)
- # meander (41)
- # nrepl (1)
- # off-topic (30)
- # pathom (22)
- # polylith (30)
- # releases (1)
- # remote-jobs (4)
- # sci (4)
- # shadow-cljs (1)
- # spacemacs (7)
- # specter (3)
- # tools-build (16)
- # tools-deps (2)
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 ... 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  and the person blogging about how great everything was is long gone . This is the absolute definition of tech debt. > Or things like this: > https://boringtechnology.club/#8 > https://boringtechnology.club/#11 > 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.
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".
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.
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 💯"
But they’ll say things like, oh start-up is slow, so many parentheses (presumably they do not use a Clojure friendly editor?)
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.” https://boringtechnology.club/#55
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.
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".
Whats a general word to describe "second, minute, hour, day, month, year" ... "time-unit"?
Java calls it ChronoUnit https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/temporal/ChronoUnit.html
ChronoUnit sounds like a group of time traveling crime fighters and so of course I absolutely love it
java.time calls these TemporalUnits, of which ChronoUnit contains a bunch of implementations
I find myself round-tripping from
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 😞
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
clojure.java-time 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.
If we were doing cljs and trying to share code between the front end and back end, I suspect we'd prefer cljc.java-time and/or tick 🙂