Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-05-01

Channels

#clojure
<
2022-05-01
>
emccue05:05:16

Is there a way to turn on "auto escape html" or something with hiccup?

borkdude11:05:52

@emccue use hiccup2.core if I understand your question correctly

emccue14:05:12

Ah okay - I see 2.0.0-alpha2 now. Wonder what the hold up on that is

borkdude14:05:05

Maybe you could ping weavejester about that, don't know

emccue14:05:29

🀷 works well enough. He should take his time, I'll take the alpha version

Carlo12:05:28

how can I remove all the taps without restarting the repl?

p-himik12:05:22

Not a public API, but (swap! @#'clojure.core/tapset empty).

🙌 2
Asko Nōmm14:05:04

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?

Asko Nōmm14:05:26

That’s it! Awesome, thank you!

Noah Bogart23:05:38

Love to see my company in there!

caleb.macdonaldblack22:05:26

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?

seancorfield22:05:30

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')

caleb.macdonaldblack22:05:53

Thanks! I'll check it out

kwladyka12:05:43

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.

kwladyka13:05:08

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” 😉

kwladyka13:05:11

All in all personally I find myself in Clojure. This is to world of simplicity for me.

Hammershafter22:05:29

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?

caleb.macdonaldblack22:05:39

You could probably (map vector a b c) before passing in?

Hammershafter22:05:13

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?

caleb.macdonaldblack22:05:20

Ah true, probably use transducer then

Hammershafter22:05:28

Ahh, I see my error here, thanks for the tip.

caleb.macdonaldblack22:05:34

@U88KT3PMY Would love to see what you come up with

Hammershafter22:05:45

(defn reducer [f i & c]
  (reduce #(apply f %1 %2) i (apply map vector c)))

Hammershafter22:05:58

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

caleb.macdonaldblack22:05:58

I like that approach actually

caleb.macdonaldblack22:05:11

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))

✅ 1
caleb.macdonaldblack22:05:29

You'll probably never change that function so just implementing the approach as is more readable IMO than creating a reducer function. Also https://clojure.org/reference/reducers are a thing in Clojure probably don't name it reducer

Hammershafter22:05:17

Thats an improvement

Ben Sless03:05:33

You can zip them efficiently with sequence