This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
@cddr: Is that not generally true for all tail-recursive operations? In other words, if you’re mapping across a seq, then recuring for every item in the seq, then you don’t have enough data to pop the previous frame. You need to keep ahold of the rest of the seq to finish your operation.
The point being, you have to rearrange the algorithm so that all state is transferred in order to allow the previous frame to pop.
sooo, I just got burned by using the wrong key in a map passed to a library function
how are magic keys in maps not place-oriented programming?
e.g. (some-lib/api-fun {:url “
, if you type :uri instead of :url, you get to chase a nil error
maybe I’m overbroadly interpreting place-oriented programming, but magic keys still seem o_O
I just wrote a post called "Decomplecting Clojure" trying to understand/explain what Clojure is about. Any feedback is welcomed! http://bensu.github.io/decomplecting_clojure/
One thing you could mention in the sexp section - I think you’re right that paren phobia is generally a totally overrated problem, but I think prefix notation is something that a lot of people (including me) never really get used to.
@therealadam: The only solution I’ve seen to that sort of problem is some sort of type system. The problem is less about “this data is stored here” and more about “this data is accessed in this way”. PLOP is about twiddling bits of memory/storage directly, which doesn’t happen with regular old immutable values.
Or another way to think about “this data is accessed in this way” is “this data is shaped this way”.
@bensu: I don’t know about others, but I find comparisons particularly painful. Every single time I use < > <= >= and friends, I literally imagine the operator between the operands to see which way they need to go.
@cfleming: agreed. I usually end up framing it like so: (< val1 val2)
or (<= val1 val2)
so that I can read it as “increases from left to right"
But I guess you can as easily read it as “decreases from left to right”… so, I guess the gist is it describes the comparables in order from left to right.
@potetm: Interesting - I find that the only thing that works for me is to imagine it in infix form, I’ve tried various other heuristics but nothing else helps much. The same should be true of division and subtraction but isn’t for some reason.
Yeah it’s funny, I pretty much have to do:
(/ num
denom)
in order to see the division right.But yeah, it can be confusing. Especially with those handful of functions. Even for a veteran.
@bensu: +100 to your post. I would have saved a couple months when I started with clojure if something like that were available
@bensu: one minor thing: "taking a part a system" should be "taking a system apart"? Another (not so) minor thing: In the section about immutability you talk about the STM as the only interface to mutability. I think that's not true, for example atoms do not participate in the STM and they are closer to direct mutation. It's just that they are synchronized
@bensu: It might be a nice addition to that section if you touch on clojure supporting different models when in need of mutability. I found one answer by Arthur Ulfeldt that very succintly shows the different combinations of coordinated/uncoordinated, sync/async and thread locals with shared default value: http://stackoverflow.com/a/9136699/1389573
@nberger: thanks for the feedback. you are right, atoms are not the only interface to mutability, but they are part of ATM. I'll correct my choice of words to reflect that. I don't want to be comprehensive but to convey the big picture, which is "a sane model for state management and concurrency"
@bensu from http://clojure.org/refs I read "they ensure that all actions on Refs are atomic, consistent, and isolated. Atomic means that every change to Refs made within a transaction occurs or none do". Atoms do not have the " rollback feature". Only refs have that, participating in a STM transaction
@bensu you are right in giving a summarized view there. It's just that STM it's not the most used mutability model, it's awesome, but at the same time it's harder to understand than atoms
@nberger: after reading that again, you might be right! I always thought that atoms and agents fell under STM, but from careful reading of /refs it seems like it is not the case.
@bensu cool. To be honest, I had to check http://clojure.org and that SO answer before giving my feedback. So we are two at least :). The thing is that STM is not really very frequently used IMO
As we are here, it would be great if anyone can point to STM usages in open source projects
@nberger: I ended up removing all reference to STM, leaving the concept that Clojure has opinions on state management