This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws-lambda (8)
- # beginners (37)
- # cider (43)
- # cljs-dev (12)
- # clojure (121)
- # clojure-italy (19)
- # clojure-nl (1)
- # clojure-poland (1)
- # clojure-russia (14)
- # clojure-spec (6)
- # clojure-uk (98)
- # clojurescript (28)
- # core-async (1)
- # cursive (7)
- # datomic (4)
- # emacs (63)
- # events (8)
- # fulcro (19)
- # graphql (4)
- # hoplon (3)
- # mount (1)
- # nrepl (101)
- # off-topic (15)
- # om (3)
- # pedestal (2)
- # portkey (31)
- # protorepl (2)
- # re-frame (26)
- # reagent (26)
- # reitit (2)
- # shadow-cljs (58)
- # spacemacs (8)
- # specter (5)
- # sql (56)
- # test-check (11)
- # tools-deps (48)
- # vim (52)
So basically PersistentList is akin to a LinkedList while cons follows the lisp rules for a list where you have the head and rest (1(2(3(4))))… it’s sort of coming together now in my mind.
@decim right, and a PersistentList is counted in O(1) and never lazy, Cons is countable in O(n) and can hold lazy tails
PersistentList has a custom reduce and reduces faster. In theory you could create pure cons-cell lists (with cons =
clojure.lang.Cons), but their main focus is as building blocks for lazy sequences. Clojure consed-lists are not intended as general purpose data structures.
PersistentList instead has the typical usage scenarios of linked lists (head mainly operations list stacks for example).
Hi all, I was wondering if it is a "code smell" to use large numbers of vars within a let. Sometimes I feel like I have so many vars in a let that depend on each other that the code is turning into procedural code. What solutions are there to this? Is it just refactor to functions?
IMO, don’t think about it in terms of “I don’t like the way this looks, it has too many variables”. Instead, ask “does having so many variables in a let make the code harder to understand/extend/test”
@rowanharg I don’t think it can always be fixed. I have some function generating different image formats and saving them, and it has a large amount vars in the let. I could remove some by moving them to specific functions, but it’s such a procedural thing I still have a lot.
@schmee @gklijs Thanks for the replies! Yes, I have exactly the same thing where I am doing some side effects - in this case saving some intermediate calculations to disk. I guess the only way to avoid this would be to build up some data structure (probably a map) with all the results in and then perform the side effect (save) at the end?
This would be akin to pushing side effects to the outside of the "app" - like in The Clean/Hexagonal Architecture.
You have several options, you might also use destruction to make it a bit cleaner. I moved on function out, and let it return a vector of two, and in the let I use something like [a c] for the first argument.
Yeah, I thought of that, but then the function names for the compound return values felt a little contrived.
hey guys. I often need a disposable function that I'll only use once (in a bigger function), but it's too big for an anonymous function. though I don't want it to clutter the namespace, as it only makes sense in that bigger fn. can I somehow group them? is doing
(let [foo (fn .. a bad idea?
@rowanharg I think it's a powerful pattern to push side effects to the edge, for example: https://github.com/Day8/re-frame/blob/master/docs/EffectfulHandlers.md Makes things much more robust.
@danielsouzasevero it gets unreadable after putting in a reader macro, I don't want people who'll read it later (namely me) suffer
Yeah. It's "out of the way" in the body so it doesn't clutter but it can't be reference else where
@mailmeupinside @danielsouzasevero Sometimes I'll also write a let binding for a single-use anon function if it's more than a one-liner. If it's not immediately obvious at a glance what it does, naming it can make the code much more readable.
The js code it emits names a variable with what you called your var but it's not munged into the namespace. It's a global var called whatever you called it
@clojurians.net thanks for the link. The re-frame docs are awesome, that framework should have its own course at university. It would be self teaching.
So if you use letfn twice with the same name it just replaces the first. Not good :)