Morning

https://clojurians.slack.com/archives/CBJ5CGE0G/p1599246728158100 Have you used ring?

@dominicm What distinguishes maps from other "pure data" values passed in a positional fashion that they would lead you to global state? That doesn't seem to be inherent to maps to me.

@borkdude I guess the ability to name them.

so naming instead of positional indexing leads to global state, in what world?

Ah, if I'm completing the sentence "leads to global state", it's "passing a map to every function in your program leads to global state". Global state isn't only bad because it's touched by simultaneous unrelated processes (like threads) it's also bad because a programmer cannot keep all of the values I their head.

You don't have to convince me that global state is not ideal in a lot of cases. I just don't see why passing maps {:foo 1 :bar 2} leads to global state where-as passing [1 2] doesn't.

If you mean that persistent maps lead to Datomic, the one true global state, then yes, you're right

Maybe I'm not expressing this well. Imagine you have a map, {:config-file "foo.edn`"}.` You call (`read-config)` on it, that merges the config into it. Then you call another function. You never call + directly, but instead you call add-user-times which takes that map, gets the user times from known keys, adds them together and puts them in a new key. This is global state.

IMHO global state is not so bad, shared mutable state is the bad part. Programs that have a the need to read from a central context map (like a web middleware) can be OK. Yada relies heavily on this approach. What's wrong with it?