Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure, the Good Parts

rasterize.io

Post reply on HN
Print view View original

81–90 of 96 posts

Re: Clojure, the Good Parts

#81

Post by escherize »

polymeris wrote: post #80
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…

> Eh? Reagent does not require any metadata, ever. I am no expert in reagent, but I think it requires it to access Reacts component lifecycle callbacks like `component-did-mount` and such.

Sorry but that's not the case.

    (r/create-class
      {:reagent-render render-fn 
       :component-did-mount (fn [] (js/alert "hi"))})
No metadata there

Re: Clojure, the Good Parts

#82

Post by [deleted] »

Scarbutt wrote: post #74
astine wrote: post #69

Earlier quoted context omitted.

Um, not really. The main feature that Clojure provides for concurrency is immutability, not just the possibility of using existing data structures in an immutable manner, but an entire suite of immutable data types and data structures. This makes concurrency, even using Java's primitives, like Thread, (which was the original way Clojure was intended to be used anyway,) with Clojure's data structures is a win over usi…

Thanks, skimming through clojure's website it mentions that Clojure simplifies multi-threaded programming in several ways. Because the core data structures are immutable, they can be shared readily between threads. which is exactly what you said, I though its concurrency features where emphasized more on its refs stuff(refs, agents) or futures, delays, promises. Also reading that clojure being hosted is a feature the…

[deleted]

Re: Clojure, the Good Parts

#83

Post by tel »

MikeOfAu wrote: post #71
tel wrote: post #10

It's sad to see that STM is not recommended. It is hugely important in Haskell. I jump to believe that this is an artifact of type-driven STM, but it may be something else instead. I've recently moved from Component to Mount. It is less powerful but just a vast syntactic overhead reduction. Absolutely avoid metadata. The worst thing ever is using it like how Reagent does in ClojureScript where it actually provides im…

> 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 intolerable, but the fact that this exists in the API is a huge wart even given the fact that it's not required.

Weavejester below suggests that use of metadata like this isn't even such a big deal for Clojure, but I cannot agree. In a language with primarily immutable data structures it's just silly to trust metadata as semantics-bearing given that it's invisible, ubiquitous, and often discarded.

I do really like it on vars, though.

Re: Clojure, the Good Parts

#84

Post by divs1210 »

raspasov wrote: post #68
j-pb wrote: post #8

I don't agree on a few points. Global atoms provide a good way to confine state into a single place. In my applications they serve as a in-memory database while everything persistent is written to disk in the form of a log (kafka, file append, you name it). Agents provide a good way to serialise events akin to a transactor. Not every problem requires the parallelism or the concurrency gained by smearing it out into a…

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

Can you help me update this[0] code to use transducers?

[0] https://github.com/divs1210/difference-engine/blob/master/sr...

Re: Clojure, the Good Parts

#85

Post by happyslobro »

Prefer Clojure Over Build Tools

Clojure scripts take several seconds to start for me, and even jars take almost a full second. Am I doing g it wrong? Do people actually find this tolerable, when they are piping several of these scripts together, with the later stages being started a new for each input?

I must be doing it wrong. Are these clojure build tools supposed to run as daemons, that take requests from... bash scripts?

Re: Clojure, the Good Parts

#86

Post by happyslobro »

happyslobro wrote: post #85

Prefer Clojure Over Build Tools Clojure scripts take several seconds to start for me, and even jars take almost a full second. Am I doing g it wrong? Do people actually find this tolerable, when they are piping several of these scripts together, with the later stages being started a new for each input? I must be doing it wrong. Are these clojure build tools supposed to run as daemons, that take requests from... bash…

Oh I know, I can write clojurescript tools, and run them through node ;)

Re: Clojure, the Good Parts

#87

Post by happyslobro »

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

Re: Clojure, the Good Parts

#89

Post by retrogradeorbit »

The Thread/setDefaultUncaughtExceptionHandler code! I read that and went, Oh! Is that how you do it! Why is this not the default? I've found the silent exception raising in futures to be one of the warts of Clojure. I had resorted to a macro that I used instead of future that caught the exception and reported it.

+1 for the pro tip!

Re: Clojure, the Good Parts

#90

Post by emidln »

jwr wrote: post #76
emidln wrote: post #52

Earlier quoted context omitted.

Difficult? I have a few lines in a namespace that grabs `git describe --tags` and a few other things and places them in a json file. This is served up internally by all http-speaking applications as `GET /_internal/build-info`. https://gist.github.com/emidln/8f5993a37ff300e36897debe9c5bf...

Do those lines also name your jars as "project-2.7.11-g03d04c5a.jar" or similar?

No, but only because load-file doesn't play well with all of my dependencies. However, that still doesn't seem like job for a plugin, given that this works out of the box with leniningen:

      :uberjar-name ~(str "foobar-%s-"
                      (-> (clojure.java.shell/sh "git" "rev-parse" "--short" "HEAD") :out .trim)
                      ".uber.jar")
Post reply on HN