Clojure, the Good Parts • Hacker News Board

Re: Clojure, the Good Parts

#91

Post by MikeOfAu » Thu, Apr 21, 2016, 9:08 PM UTC

tel wrote: post #83

MikeOfAu wrote: post #71

Earlier quoted context omitted.

> Absolutely avoid metadata. The worst thing ever is using it like how Reagent does in ClojureScript where it actually provides important program semantics. Eh? Reagent does not require any metadata, ever. Much less metadata what provides "important program semantics". So I'm pretty puzzled by your comment. Either you have never used Reagent, or our definitions of metadata is really different, which would be odd, giv…

You can avoid it's use through create-class, but it's freely supported and suggested to use it to access the lifecycle callbacks. Given that there is a supported and suggested pathway to achieving core functionality of the library which involves the use of metadata to define the semantics of your components I stand by my statement. I'm happy to roll back on "the worst thing ever" if a bit of exaggeration is intolerab…

> Given that there is a supported and suggested pathway to achieving core functionality of the library which involves the use of metadata to define the semantics of your components I stand by my statement

Sorry, but you are just completely wrong. Have you ever used Reagent? Reagent doesn't require the use of metadata AT ALL, EVER. Much less in some fundamental way, as you claim.

Re: Clojure, the Good Parts

#92

Post by aosullivan » Fri, Apr 22, 2016, 5:04 PM UTC

DigitalJack wrote: post #21

sdegutis wrote: post #9

Earlier quoted context omitted.

We don't use Component in production, because it's way too heavy for us. Our web store uses Datomic, PayPal and Stripe, and a few AWS services, and none of these need to be started or stopped. But we do take a tip or two from stuartsierra's "Reloadable" work flow (which he based Component on), specifically that there should be no global state, and all dependencies should be passed into functions that need them as a p…

Isn't your use of an env as a parameter just another form of global state? If not, can you elaborate?

You are right. Params can be references to state, either as an atom or ref, or to a function which accesses external state (e.g. a database). The idea that params somehow obviate the need for state overlooks that.

Re: Clojure, the Good Parts

#93

Post by raspasov » Fri, Apr 22, 2016, 5:48 PM UTC

j-pb wrote: post #78

raspasov wrote: post #68

Earlier quoted context omitted.

What's so complex about transducers? (let [my-xf (comp (filter even?) (map inc))] (sequence my-xf [1 2 3 4 5])) => (3 5)

Yeah but now try implementing a custom state-full transducer.

State-full things are always more complex, and I'd say their use is also niche (for example, state-full transducers where you can really shoot yourself in the foot since they grow infinitely in memory).

Re: Clojure, the Good Parts

#94

Post by brunchboy » Tue, Apr 26, 2016, 9:55 PM UTC

ecolak wrote: post #56

I like the write-up, but I disagree with the reasoning to avoid STM. It sounds a lot like "avoid ConcurrentHashMap in Java". It's true that web applications mostly persist their data in a database or some other persistent structure, and obviously an STM or a ConcurrentHashMap would not do you any good for that. However; if you are working with in-memory data, then STM is a very valuable tool just like ConcurrenthHash…

That was going to be my point as well. My “production” application runs light shows for electronic music events. The only state that matters is in-memory in the STM. There is no database. STM works wonderfully in the rare cases where there are multiple values which need to be changed in a coordinated way.

Re: Clojure, the Good Parts

#95

Post by robohamburger » Tue, May 03, 2016, 5:04 PM UTC

happyslobro wrote: post #87

robohamburger wrote: post #66

It would be great if the author of the post expounded on the good libraries to use. In the couple of false starts I have had with clojure I spent most of my time evaluating libraries instead of writing code. Also: Seeing what clojure considers bad parts makes me laugh since I spend most of my day writing python and javascript. More language orthogonality more problems I guess..

It's like, the more languages I come across, the more problems I see...

Yes! At this point I have come to accept that there will be many annoyances in any programming language.

Seeing how sophisticated clojure is compared to python makes me weep however.

Re: Clojure, the Good Parts

#96

Post by sjatkins » Tue, May 03, 2016, 10:59 PM UTC

robohamburger wrote: post #66

It would be great if the author of the post expounded on the good libraries to use. In the couple of false starts I have had with clojure I spent most of my time evaluating libraries instead of writing code. Also: Seeing what clojure considers bad parts makes me laugh since I spend most of my day writing python and javascript. More language orthogonality more problems I guess..

I would love to see the front-end equivalent. Recommendations for what to use and avoid in clojurescript. To OM, or Reagent or something else. Global front end satte or not and so on. I am much more befuddled there than in pure clojure.