in reply to Complex Data Structures

Another thing I've noticed is that it's often fun to use complex structures, but possible (and even simpler) to use several simpler ones. Anyone else noticed this? How much time / effort have you expended creating a huge structure, only to realize that it makes much more sense to break it up?

Let's consider a hypothetical scenerio: I'm going to impliment a Geneology application in java. I'm going to have things like "Person" and "Place", and relationships like "child of" and "married to" and "born in". I decide to impliment this application, using new classes called "Person" and "Place". To handle the parent/child relationship, I'm going to have a getParentId() and getListOfChildIds() methods in my Person class, and you can use those Ids to look up the Object in a global hash table of all people -- which must constantly be kept up to date. This is kind of a pain in the ass, but I'm going to do it this way, because I don't want to have a lot of refrences. It's easier if all of my objects just store Ids, which I use as keys in simple global lookup tables.

Almost any java programer should realize this is ridiculous.

Perl is the same way. Regardless of wether or not you are useing true "blessed" objects, or just using hashes or arrays to represent your entities, using hashesrefrences to connect those entities together and show relationships makes a lot of sense. Is it easy to read code like thi? ...
$yak = $${$foo{'bar'}}{'baz'}[0]; but it's not much worse then this:
Integer yak = (foo->get("bar")->get("baz"))[0];

Which is why you don't write code like that if you want people to read it. Instead, you write code that derefrences things in to temporary variables with names that indcate what they are, and how they are used. And if that's stil not readable enough, you start to bless your hashes/arrays of nested refrences, and write some methods that treat them like objests so your code is even more readable.

Updated: stupid typo.