This perceived simplicity of only having a single non-scalar datatype comes at the cost of increased complexity when you have to stuff a square peg into a round

This perceived simplicity of only having a single non-scalar datatype comes at the cost of increased complexity when you have to stuff a square peg into a round hole, i.e., when you approximate other data structures with tables. My favorite example are arrays in Lua: They are hashtables, but not quite (in the implementation, every hashtable has a separate array region). They look like hashtables, but not quite (there's syntactic sugar to help dealing with them). You can use hashtable-functions on them, but they don't quite work (which is why there are special functions for when you want to treat a hashtable as an array). Hashtables are great for unordered maps and sets, but they're a crappy replacement for ordered sequences. > Python is the classic example here, where you have tuples using parens, arrays using square brackets, and dictionaries using curly brackets. At some level that is clever, but at another level it is a cause of confusion. If that confuses you, then the source of the confusion is you not having a clear understanding of the intended semantics of your code or datastructure. Mixing all of that into a single type won't help here.