This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (14)
- # aws (1)
- # babashka (22)
- # beginners (105)
- # biff (12)
- # calva (1)
- # cider (7)
- # cljsrn (1)
- # clojure (33)
- # clojure-europe (22)
- # clojure-germany (1)
- # clojure-uk (3)
- # clojurescript (28)
- # component (15)
- # copenhagen-clojurians (1)
- # core-typed (29)
- # cursive (8)
- # data-science (2)
- # datomic (2)
- # emacs (16)
- # gratitude (3)
- # humbleui (3)
- # introduce-yourself (4)
- # lsp (1)
- # other-languages (3)
- # rdf (3)
- # sci (6)
- # shadow-cljs (9)
- # spacemacs (12)
- # tools-build (1)
- # tools-deps (5)
- # vim (3)
- # vscode (1)
Am not really sure where is the most appropriate place to post this, but: I remember seeing somewhere a list of Clojure companies that hire without prior Clojure experience. Does anyone know where I could find that?
Love to see my company in there!
Do Clojure engineers tend to over-engineer/over-abstract? Obviously it depends but in my anecdotal experience, the Clojure devs I’ve worked with have all been like this (including myself!). All these devs moved to Clojure themselves (including myself!) and hadn’t had any guidance from seasoned Clojure devs and might explain why. It appears that well known Clojure devs understand that the idea of abstracting as-needed, for example: https://clojureverse.org/t/dependency-injection-in-clojure/1723. Im trying to explore the challengers in scaling the workforce in companies that use Clojure. And I think that over abstraction is a big issue that I’ve personally experienced. So much software is abstracted in-house in a framework-like fashion making it painful to onboard new devs as well as keeping the current ones productive. So in short, I would love to hear some opinions and thoughts on this from other Clojure Devs. Can I expect Clojure devs I hire to want to over engineer? How can I avoid this? What have I not considered? Maybe I’m wrong?
Eric Normand's newsletter has been tackling this theme in recent issues -- well worth signing up and reading everything he has to say about domain modeling and abstractions I think: https://ericnormand.me/ (I don't know if back-issues are available online anywhere tho')
Thanks! I'll check it out
Personally I see it more like a level of experience of Developer. Nothing to do with language itself. It is normal on the beginning of your experience (also in the middle?) you want to make code which is reusable even if you don’t need it etc.
But the issue which I see Software Developer code in Clojure with the approach of OOP. This is the issue which make code more complex, than could be. The specific example is over usage of
defmethod. It makes harder to track flow of the code and in most cases there are simpler solutions. But I understand this, because on the beginning I though it is the right solution too. Because of OOP mindset which is hard to change just like that.
I could also maybe say Clojure let you make really complex code if you are not experienced Software Developer / experienced in functional mindset just because you can write it 🙂 But really not sure how to compare it to OOP “how easy is to write complex code” 😉
All in all personally I find myself in Clojure. This is to world of simplicity for me.
So it seems I can't pass in multiple collections (in my case, 3 collections) into reduce? Is there a reason reduce doesn't accept multiple collections as map does?
You could probably (map vector a b c) before passing in?
iirc that would lead to me reducing each original collection as a whole sequentially, which wouldn't allow me to perform ops that use elements of each collection in the same reducer, right?
Ah true, probably use transducer then
Ahh, I see my error here, thanks for the tip.
@U88KT3PMY Would love to see what you come up with
Or ended up using
(defn reducer [f i & c] (reduce #(apply f %1 %2) i (apply map vector c)))
Don't feel good about this solution, but it seems every solution to creating a multi collection reduce so far has resulted in redundant structuring and destructuring
I like that approach actually
Personally, unless you're doing this operation in multiple places, I would defer abstracting for Clarity:
(->> [[1 2 3] [3 2 1] [5 5 5]] (apply map vector) (reduce #(apply + %1 %2) 0))
You'll probably never change that function so just implementing the approach as is more readable IMO than creating a
Also https://clojure.org/reference/reducers are a thing in Clojure probably don't name it reducer
Thats an improvement