[0xDEAFBEAD]

>For example, over its lifetime the Clojure community has shifted from accepting argument lists and named parameters in their functions to accepting a single hashmap. This is because the single hashmap is easier to grow over time.

This seems a little nuts, to be honest. It feels like you're just pushing failures from easy-to-diagnose issues with the function signature, to hard-to-diagnose issues with the function body. Basically the function body now has to support any combination of hash parameters that the function has ever taken over its entire history -- Is this information documented? Do you have test coverage for every possible parameter combo?

[upghost]

It is nuts, especially in ClojureScript.

"Am I missing a key, is the value in the hashmap nil, or was there an upstream error or error in this function that is presenting as nil?"

[potetm]

I'm sympathetic to this idea, but in practice it's very manageable. Function signatures destructure exactly the data that they need, so it's easy to tell what's required and what's optional.

Of course, normal rules apply like, "Don't pollute your program with a proliferation of booleans."

[MarkMarine]

no, you pull out the things you need from the map in the function body and move forward. I recommend either reading up on how this works in Clojure or just trying it, it's pretty simple.

https://clojure.org/guides/destructuring#_associative_destru...

Some extra reading if you're curious: https://softwareengineering.stackexchange.com/questions/2723...

[jiehong]

I think it was meant from old style functions to new style, but not changing a given function’s signature this way.