The importance of 'transparency' in data structures

The other day's entry on why Perl is not my favorite language produced an interesting comment exchange between me and a friend that touched on how transparently Perl can embed data structures in other data structures. (In specific, that one can't transparently put aggregates, lists and hashes, straight into and out of other aggregates.)

Why does this matter? Because every time you have a lack of transparency with data structures, you have to be aware of the actual types that you are working with. Being aware of the actual types complicates changing the program later, and complicates some design patterns always.

For example, the Python design pattern to introduce a lookup cache is pretty simple and quite general:

fooCache = {}
def cachedFoo(key):
  if key not in fooCache:
    fooCache[key] = getFoo(key)
  return fooCache[key]

This works for almost anything. (Honesty compels me to admit that it doesn't work for iterators; for why, see GeneratorGotchas. There are also some key types that won't be accepted, because if you work at it you can create something that isn't acceptable as a hash key.)

The equivalent pattern in Perl has to either use explicit references or know that getFoo() returns a scalar.

This also complicates changing what getFoo() returns, even if it's supposed to be used as a relatively opaque token. If the new type isn't storage-compatible with the old one, you wind up having problems. (Python is not immune from this havoc, since getFoo() could change to returning a non-hashable or non-reusable object.)

(Part of this is my computer science background being neurotic, because it is dissatisfied by irregular things and exceptions.)