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.

No comments: