This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (6)
- # beginners (54)
- # calva (9)
- # cider (2)
- # clj-kondo (26)
- # cljsrn (2)
- # clojure (49)
- # clojure-brasil (1)
- # clojure-dev (3)
- # clojure-europe (11)
- # clojure-italy (28)
- # clojure-nl (5)
- # clojure-serbia (1)
- # clojure-spec (4)
- # clojure-uk (182)
- # clojuredesign-podcast (2)
- # clojurescript (59)
- # clojurex (9)
- # cursive (26)
- # data-science (11)
- # datomic (40)
- # duct (1)
- # emacs (3)
- # events (4)
- # figwheel-main (2)
- # fulcro (7)
- # instaparse (1)
- # kaocha (2)
- # leiningen (25)
- # off-topic (3)
- # re-frame (36)
- # reagent (15)
- # shadow-cljs (87)
- # spacemacs (12)
- # sql (20)
- # tools-deps (8)
- # vim (1)
- # yada (40)
I had a slack update a few weeks ago I think. I use the Slack Snap on Ubuntu. Looks the same (except it shows my long list of Slack communities)
I saw him post about his like of Clojure on Twitter. Very interesting watching the replies. Always a mixed bag when opinions come into play
>Over the last 5 decades, I’ve used a LOT of different languages. ☝️ That's quite a statement
clojure requires less typing and my fingers get tired easily these days, so it's a no brainier
I was having this discussion with someone, and it was very hard for me to articulate the benefits of clojure. "Immutability" isn't really an upside, it's an implementation
I addressed that with a "but it's not really the same", but I didn't feel very convincing
I also think clojure has a fun argument on there, but I'm not sure how to prove it in speech
I suspect the argument should be that with Clojure you tend to write less code... and that results in fewer defects. which can only be good thing.
(and also note that Clojure is not just a write-only language, you can read it as well, otherwise we would be all doing APL)
The big difference is JShell is bolt on not built in. Clojure’s REPL has exactly the same semantics as the core language, because it is the core language. Consequently clojure starts from a point of building programs as a dialog with the computer. Still I agree with your point that there’s no real objective difference. I mean programming on punch cards still has a feedback loop right? And it is a little unsatisfying to concede that it’s really the same — just errr better. Hence I think arguments for clojure don’t really come from any one killer feature, they come from the unique combination of properties it has; all of which support each other.
> Hence I think arguments for clojure don’t really come from any one killer feature, they come from the unique combination of properties it has; all of which support each other. That's a pretty good way to characterize my sensation of "flapping".
I was also told that doing java "properly" it's really easy to protect your mutable state. That one was a little easier to rationalize in my mind. There's so much undoing of Java you have to do around the incidental complexity that it kills your ability to provide business value.
I tend to judge languages on their community also, many are completely insufferable but Clojure people tend to be quite nice
The clojure community is literally the nicest group ever. Sometimes I worry that I'm not doing a good enough job of being part of it - a good feeling to have, we have such high standards.
I think the main selling point is: If you want a dynamic lisp like language, where functional programming is idiomatic, with the state of the art immutable datastructures built in, and you want access to the jvm/js ecosystems it’s pretty much the only serious game in town.
if you don’t know why you want those things, fair enough… either find out or move on 🙂
The difficulty for me was selling this person on the "brainfuck-like" lisp, who needs functional programming I got "protected", etc. So the leading premises there were hard to explain!
I saw a comment to that effect on reddit, sometimes you're just not in the right place in your career to be hating OO yet. You haven't felt the burn.
And that’s fine. I don’t need to convince people of the benefits. I’m very happy with it. Is it perfect, no. Are there other options sure. Are there any that have the same combination of benefits? No. Are there any languages I think are as good that I have 11 years experience doing? No. 🙂
@rickmoynihan - You're not wrong there... I know a couple of dyed in the sackcloth java developers who are aware that I am not the only person in the World with a paying Clojure job and that Clojure at 10+ years in and adoption by massive organisations as well as small and medium-sized ones as well. Despite that, they regularly tell me that Clojure is unsuitable for "the Enterprise", that Clojure is not stable enough, that Clojure is a fad that will pass, and a load of other tosh...
Yeah, I got linked the Vertx/Nodejs customer list and told "but look! people build big things with java!". Not sure I wanna take a bet on this Clojure thing? Who even uses it? Oh, walmart? yeah but only for a team of 8...
@ben.hammond - for me too, even though I am not a full-on power user of the paradigm
@maleghast I was in the middle of untangling a huge git merge conflict, squidmungus it was and all I saw was, “Java = no fun”, so apologies 🙂
My only anecdotal experience to add is, Clojure is very fun to write, you write less code repl driven development is very fresh. I still find Clojure stack traces and now spec errors to be pretty 😵 however.
Rich does make the opposite assertion in one of his talks, that simplicity will keep you more agile, and you'll run circles around others.
I have the same opinion of Ben in this regard. >harder to refactor and maintain once in production >you have to get super disciplined with your generative testing
if you reduce the quantity of devs required there are big time savings to be found 'The Mythical Man-Month' turned back-to-front
Don’t get me wrong. Simplicity is something absolutely worth having, and it is the only answer to the complexity crisis. I mean there really is no other game in town! However building simple things is really, really, hard and expensive… and it front loads that cost. Whilst bodging things together the easy way can be quicker. I’d absolutely rather take the time and aspire for the simple way; but in the real world you need to make trade offs.
and customers are often not interested in paying for you to > go back and redo it simpler
I don’t think clojure necessarily always makes me quicker at knocking out features. It does however somewhat force you into pursuing the simple path which leads you to much better solutions, and higher quality overall.
and even then, you are trying to predict how the customer will want to change the software in the future
Yes I think Clojure absolutely helps in finding simpler solutions. At least if we take Hickey’s definition of simple, it’s almost (though not necessarily strictly) tautologically true that you can’t build simple things on comple(x|cted) things. For example if you have a language based on mutability, you will naturally tend towards a complected solution, because you have complex (easy) foundations. The properties of a language very much effect the shape of the solution. So really clojure’s big selling point is having simple foundations, which is a pre-requisite for simple solutions.
Obviously this argument isn’t true under a rigorous reduction. Nobody wants to program in the lambda calculus. It’s too primitive. But clojure is really just a lot of well thought out conveniences ontop of that.
in other news a very worthwhile friday or weekend watch here https://www.youtube.com/watch?v=Kp50G2j9h48
I know Alan Kay tries to claim OO is just misunderstood, and he should’ve called it message passing; but I think he’s really just whitewashing history when he says that. Messages as a primitive are asynchronous not synchronous. Erlang has this view of the world, but smalltalk really doesn’t.
I agree, but as a description of how I like to build components/services it still works
Actually you reminded me of this debate from a few years back (unrelated) but still interesting if you missed it: https://news.ycombinator.com/item?id=11945722
I like things functional on the inside and side effecting on the outside and like to make my state by reducing over a seq of events or messages
are you part of m-club @U052852ES? if you aren't i'll have to give you an incomprehensible explanation
I am 'fraid I have never really understood M's, but also never made an effort to understand them either.
in which case, i have a long list of most excellent tutorials for you to read, guaranteed to work :rolling_on_the_floor_laughing:
wrt side effects, I know I'm managing them manually like some c programmer with memory, but that is working for me atm
we've got roughly two ways of managing side-effects atm... one is in-memory reduce-based, the other is transactional kafka-streams apps event-topic=>effects-topic
I cant help feeling that there should be a good technical lego metaphor for the M work
block that can be plugged together, but that contain moving parts that will engage each otther
@otfrom I had an idea about doing automatic grouping of events in a sequence in order to form transactions. Ever tried something like that?
@otfrom Finding a things that will write to a database, and putting them all together in a sql transaction
I like to persist the events/messages as is. With a lot of the stuff the state can be held in memory and the events aren't that big
@dominicm That’s quite a common pattern isn’t it? I mean databases and file systems and operating systems do this stuff all the time… Also one of our services has a write scheduler that rebatches events into larger/smaller transactions before committing them.
I've never actually seen it 😁 never really needed it, never thought of doing it to exploit a simpler programming model.
We had to do it to retain responsiveness and throughput… some operations are tied directly to user interactions (and need quick feedback) others are much bigger and would end up blocking the user interactions; but because of our data model these ones don’t need to be transactional. So we throw them internally onto a priority queue with a comparator that sorts them to optimise the writes into the priority we want - and we split the larger operations up into smaller chunks that ensure we can always serve the ones that need fast response times… We could also batch the smaller ones together if they queued up… that would be trivial to do, though I can’t recall if we do that yet.
I remember an old heuristic of "never write a function longer than a single screen" because that's as much as you can reasonably hold in your awareness without really straining
When I was a student I had a summer job doing IT support for a software house who ran systems for detecting bank/credit fraud. One day I walked into the corridor to find one of the developers trying to debug a procedure. He’d printed it out on what was probably 100 ft of fanfold dot matrix printer paper. The procedure started at one end of the corridor and ended at the other, and he and a few other developers were running back and forth with a marker pen trying to debug it. Good job it wasn’t an important system for just about every UK financial institution. :rolling_on_the_floor_laughing:
When I worked in IT for an insurance company, we debugged stuff by printing out the core dumps -- usually a 6-9" stack of laser-printed green/white striped paper -- and decoding the assembler and data in our heads as we flipped back and forth through the pages.
One guy on the team had an almost "idiot savant" ability to drill down to your bug based on a core dump in just a few minutes -- an incredible skill.
Glad those days are behind us tho' (we were a COBOL shop so we'd translate from hex to assembler and then "decompile" back to COBOL in our heads 🤯 )