Clojurians Log v2
clojure
Many thanks
Has anyone checked out Hy? It has syntax very close to Clojure's, and even has threading macros. After I discovered it, I swore I would never write vanilla Python again.
Yeah right. Conceptually, considering Hy is just "homoiconic python", we could also expect some smooth Hy-Clojure interop using libpython-clj!
You might also be interested in http://coconut-lang.org/
Whoa, this is so nice. Thanks for sharing!!
Hi everyone! Where is the best place to ask a datascript / clojure question? Thanks!
the #datascript channel is helpful!
Haha wow I’m sorry I didn’t see that channel!
no worries! there's a ton of channels and not all of them are active
Thanks. I posted the following there in case you are able to see something simple I am doing wrong ;) https://clojurians.slack.com/archives/C07V8N22C/p1613789275001600
Hy is awesome! It's just transpiled to Python anyway and can use all the same libraries, so it's perfect for REPL use in jupyter notebooks or other typical python-y stuff. Though with how good libpython-clj is getting, it's also kinda hard not just doing python interop in clojure
Hi, I am planning to introduce https://github.com/kkinnear/zprint formatter in my team. Folks use a mix of Cursive, Emacs, and Spacemacs editors. Wondering if anyone had positive/negative experiences to share? I intend to use the default zprint style and pretend that zprint offers no customization of style. Cursive IDE integration seems non-existent, so will need to rely of git pre-commit hooks and CI checks for consistent formatting. My main reason for choosing this over cljfmt is, clfmt seems to by default respect any "valid" formatting, even if it is inconsistently applied, so it becomes difficult to ensure a consistent style of formatting.
note that zprint, just like cljfmt, does not control every nuance where there may be more than one style between programmers. I got a confirmation of this in https://github.com/kkinnear/zprint/issues/170 (I have it pending to reply over there btw - my bad). The author is willing to improve this part though upon feedback. tldr: zprint is more powerful than cljfmt, but it's not a canonical formatter either so it might be more practical to use cljfmt which is has broader adoption (at least for this use case)
> My main reason for choosing this over cljfmt is, clfmt seems to by default respect any "valid" formatting, even if it is inconsistently applied, so it becomes difficult to ensure a consistent style of formatting. While personally I'll always encourage people to do experiments, explorations, etc, I'll just note from experience that currently this is still impractical. As of today there's no "one and only" formatter that you can just use and forget about forever: it will either introduce an odd style that goes against community customs, or it won't be actually as 'canonicalizing' as desired. There's no inherent reason for that - I'm simply commenting on the current landscape of technical solutions.
Our projects are private to the team working on them, so limited to around 10 - 15 folks. In that sense, I am okay with mandating "a style", even if it is one that doesn't have wider adoption. The specifics of the style itself is not relevant to me, so if a team member is able to convince the entire team to adopt a variation of said style, I am fine with that.
Eg, even though folks in the team have aligned not to do https://github.com/bbatsov/clojure-style-guide/issues/10 for official projects, it is a difficult to apply this uniformly across all official projects (and not for personal projects), across all IDEs. cljfmt considers both versions (aligned and non-aligned) as valid. With zprint I would be able to set either one as the style and it will consistently error out on the CI if the code doesn't match the style.
@amithgeorge we are currently testing such a setup. we found the default zprint style to be too intrusive and are using the :indent-only style. it's working well for us.
I'm using manifold and have a collection of values (of unknown length) that I want to do some async operation on and return a deferred of the entire result
is there something better than (apply d/zip (map async-op coll)) ?
that's what I do
I for some reason feel bad about allocating lazy seqs all over :thinking_face:
the threads are probably way more overhead than the corresponding seq?
yeah it's not rational lol
mixing the laziness with side effects also gets cumbersome and error prone, a common error i've seen in code:
(apply d/zip (map (comp deref async-op) coll))(d/map async-op coll)