Having used Clojure for a while now, I will say having 90% of things be a primitive, map, or vector goes a long way in and of itself. A lot of types concocted in a more conventional language just don't need to exist, IMO, and they create so much baggage around themselves.
Hmm, how well does this scale though? you are passing around these giant maps of vectors of tuples and then you pass it to someone unfamiliar with the code, how the hell do they know what's in there? Is the order price the first element of the tuple or the second? What happens when I refactor things and now all the tuple elements shift over one? Surely you'll end up writing just as much in documentation as you would have to specify the types?
Currently working my way through some complex Python code written in that style and it's completely impossible to understand it. In fact, the only way I can actually do it is transforming all these ad hoc data structures into proper types so I can make sense of it.
If your data is not position-dependent a tuple doesn’t sound like the correct choice. In the price example you provided, a map would be much better.
As for how you know what’s in there - you should only know whether what’s relevant to your function is in there and not care about the rest of the world. For the former, tools like clojure.spec are helpful but ultimately good design helps the most (something that typed languages can often obscure).
> If your data is not position-dependent a tuple doesn’t sound like the correct choice.
That's kind of the problem though. Software is written by humans, and humans are fallible. We don't always make the correct choices. Also, there are economic pressures, deficiencies in specification, and changes in business requirements.
Personally, I believe businesses should accept the aforementioned reality and optimise for cost of change.
I have the exact opposite experience. I can't think of anything I got more sick of than every freaking method in every rails project having `params = {}` where you have no idea what keys are required or expected or ignored. Easily 90% of these should have been named structures instead of these arbitrary data grab bags.
Agree that "map oriented" code bases are pretty bad. Always an unmaintainable mess, usually developed by single dev, painful to refactor. Seen this with Groovy back when some people thought this language had any merit.
If you had a generic params map, you would likely destructure it and the keys would be obvious. Destructuring in Clojure also gives you a way to specify defaults for each key right there.
