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.
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.