Most everyone knows that a nested class can access private memebers of its enclosing class. But did you know that the reverse is true? The enclosing class can access private members of the nested class. No, really.

For those doubting Thomas' out there, I'll provide you with a reference.

Does anyone know the motivation behind why the enclosing class would be able to access private members of the nested class?

I have recently switched over to a new hosting provider. If you have any problems, please let me know!

Update April 21 8:00AM: The intermittent comment problem has been rectified. Thank you for being patient through this server upgrade.

My parents were always apt to say "you learn something new each day". For the most part they've been right from the little things (turn the door knob before trying to go through the door) to the big things (when a sign says "Do not feed the bears," man, you better not feed the bears).

Today's new thing was stumbling on the paper Archetypes, Color, and the Domain-Neutral Component. As I've often said: when you sit down to solve a differential equation you don't just try to figure it out, you use the set of known patterns to guide you to a solution. I believe that the same is true with software architecture and development.

Here are some complimentary links on color modeling and the DNC:

• Using the Domain Neutral Component
• Whole-Part Relationships in Color Modeling
• Color Modeling and the Law of Demeter
• The page that started it all: The Coad Letter: Modeling and Design Edition, Issue 44, Strategies -- Boundary; Colors; Time Line; Status

I had the privilege of seeing a lecture by Dr. Robert Laughlin (1998 Nobel Prize winner in Physics) at the Adler Planetarium. "[Dr. Laughlin argued] that the true frontier of physics may not lie in studying tiny individual particles, but rather by studying the properties that emerge when large collections of particles are taken together as a whole." This notion of "emergence" flies in the face of centuries of reductionism. (This is also an interesting reductionism link.)

Dr. Laughlin demonstrated that some (all?) sufficiently complex systems show emergent or collective behaviours -- behaviors that are greater than the sum of their parts. What's facinating about these behaviors is that they do not follow reduction-based models. Take for example a rigid aluminimum bar. What causes its rigidity? If you reduce the problem down to a nano scale, say, a single layer of aluminimum atoms, you find that the system is no longer rigid; it actually demonstrates fluid behaviors. As you increase the number of atoms the system begins to display more and more of the rigid behaviors. There is no single point at which, like a light switch, rigidity can be on or off.

Another interesting example is classical (Newtonian) mechanics. As you attempt to reduce the problem of mechanics down father and father you enter the realm of quantum mechanics where probabilities rule. There is no point at which the transition from one model to the other takes place. Classical mechanics emerges from quantum mechanics when a large set of particles is observed. If there is a 100M ton freight train coming straight at you, you don't use the probabilites of quantum mechanics to compute whether or not the train is going to hit you -- you're going to get hit!

When listening to this lecture my mind began to spin and the wheels began to turn. Coming from a physics background I am naturally a reductionist -- I tend to believe that every problem can be reduced down to first principles. This belief has bled over into my software engineering work. I began to wonder: what if the significantly complex interactions of software in modern systems begin to display emergent behavior? How could we possibly begin to systematically analyze and understand the nature of this behavior?

It seems that in general modern software engineering has a reductionist approach. Most agile methodologies, for example, advocate unit testing. Unit tests are nothing more than a firm belief in and practice of reductionism. Even without emergent behaviors most software engineers know that the transition from unit testing to integration and system testing is non-trivial. Simply understanding the interaction of various software components and understanding the failure modes that are introduced is a hard and not well understood problem.

So then what if non-reducible behaviors do occur? Are there going to be cases where we throw our propositional logic and lambda calculus out the window in favor of representations that model the emergent behavior? Interesting times are ahead!