Wednesday, August 20, 2008

hostile metrics...

While countering a blog post (#25) about men's involuntary glances at women, I raised an equally involuntary tendency of women to "test" men.   

The primary goal of such tests seems to be to present a problem that appears to have a simple logical answer, but in fact has no correct logical answer (i.e. a trap). A simple example would be the notorious question "Does this make me look fat?"

I started thinking about evolutionary advantages and motivations for such behavior...

Assume that reproductive resources are scarce and they have high cost and intrinsic value for both sexes.  Anytime there are scare resources worth having, there are at least a few general success-strategies: fight, lie or wait.  

Let's focus on "lying" as a strategy.  Imagine a selection environment rich with liars who are trying to misrepresent their true value. Women who can't detect the liars from the nonliars are selected against evolutionarily speaking.   So the goal is to find a metric that can distinguish liars from non-liars.  But how could we do this?

We can't test with simple logic, because they'll lie ("Are you a liar?" "No. Of course not.").   But what about attacking the premise of a lie instead?   The general premise of a lie in this context would be to please the prospective mate. 

So here's an interesting idea... frame the concept of a "test" so that any logical answer or pleasing answer by definition fails. Now, apply the "test" to prospective mates and watch the reaction according to the following:

1) If the male responds with logic, there is always a negative answer that will assert he is wrong, i.e. this allows the test to be chained -- continue testing until he doesn't.  

2) If the male ignores the test, he's not interested or not attentive enough.  This lowers confidence -- test again.

3) However, if the male doesn't ignore the test, but responds without logic (non-sequitor, humorous response) in an unexpected but interesting way, this is interesting. He's potentially demonstrated that he is attentive, but is not saying things simply to please his mate.   This raises confidence -- test again.

What's interesting about this idea is that it doesn't define an end.  This is a continual testing process that merely raises or lowers confidence.  It can adapt over time.  Of course, I don't know that women really use this process, but it is an interesting hypothesis.

Tuesday, August 12, 2008


The Second Law of Thermodynamics says that entropy always increases. Ordered systems are typically lower entropy (like a clean desk) and classically, they are said to have more available energy... so the 2nd law has always been a little sad.

However, what if there is a loophole? What if we:
1) look at increasingly complex systems of order. initially, these appear random to us, but understanding order in chaotic systems gives us more leverage to
2) do more with less. so we need less energy, thus creating more "headroom" -- does this (relatively speaking) reduce our apparent entropy?

Of course, it still seems like there is a trend of diminishing returns, (this just lengthens the tail in some sense) but now instead of implying a simple "heat death" of the universe, the 2nd law implies the rise of greater and more subtle organization as well.


Monday, August 4, 2008

the return of intrinsic computer languages!

I recently found out about Processing. It's amazing. It's simple. It's portable.

It is the first intrinsic computer language in almost two decades. Languages for some reason have become cumbersome extrinsic behemoths... what do I mean by intrinsic and extrinsic?

Let's say you want to print to the console:
print "hello world";
This is a function that is intrinsic to almost every language in history. It's intrinsic because you didn't have to specify any concept of bindings to an IO channel, unicode character string loading into memory, etc. etc... you just do it.

In contrast, here's an extrinsic example of how to print text to an OpenGL surface. Notice how much boilerplate you have to weed through to finally implement basically two steps.

Now let's look at a similar example done in Processing. Wow. It's so much easier. The code focuses exactly on what you wanted to do... all the other setup and infrastructure has become intrinsic.

Back in the old days, most computer languages were intrinsic. You simply couldn't afford to write millions of lines of code to get something done. Fortran, BASIC, Pascal, Smalltalk... somewhere along the way this viewpoint shifted.

C, C++, and now Java have led an ever increasing charge towards extrinsic declarations. It happened for the best of intentions: we wanted flexibility. C wanted to keep the kernel of intrinsic functions small so that it was portable and powerful. For a time this approach was also simple.

There is nothing simple today.

In the current age we are deluged with extrinsic code. We are drowning in the most convoluted syntax man has ever created. Hibernate, Flex... the list of modern application environments and their dozens of sub-languages requiring explicit coordination has grown out of control.

And none of it is what we really wanted to do in the first place.

It's time to return to intrinsic languages. I'm not advocating a return to simpler non-portable environments that C and it's ilk freed us from. I'm saying the infrastructure has to get smarter -- it has to let us be portable, flexible, free from deployment tyranny, but it also has to be more intrinsic, transparent when we need it to be, opaque when we don't, subtle -- NOT obfuscated!

Processing is the most refreshing step in that direction since LOGO.