Context and Software
While proofreading and adding to a technical paper earlier today, I was struck by a general difference between human language and computer language: works based on human languages are much easier to critique and modify than machine languages. In software, writing something from scratch is usually easier and more effective than modifying some other software written by someone else for your purpose. (An exception would be frameworks, which exist only to be extended and modified. Also Vista.) Why is this the case? What makes human languages so much easier to modify than machine languages? Part of the answer I think lies in Context. (I love context. I often find myself stumbling around in the context of Context.) In human language, it’s simple and often pleasurable to let someone else wrap you in context, and once there, modification and extension of that work can be natural and straightforward. In machine language, just getting to that state of contextualization is at best painful and usually impossible. Machine languages do not lend themselves to climbing from the page or screen into your head like a good book does. And without being immersed in the context of a system, the work required to modify and extend becomes haphazard and risky. You start wanting things like contracts, components, and test suites.
Can I please just have a skulljack instead? These JUnits are getting
tedious. It seems that latter day computer languages assume that this greater contextualization of a digital system is impossible, and gains are made by reducing the risks to minimal or partial contextualization. In fact, some technologies even classify this minimizing of contextualization as a feature. Where would we be in software today if we’d taken the path of focusing on tools and techniques to let the human contextualize more or all of a program, rather than assuming they can’t and hope for the best? blonde, brunette, red-head…
September 13th, 2007 at 9:32 am
This is interesting. I think you’re right that context and immersion are the keys, but I’m not sure that it’s usually easier to write any code from scratch, even if the software is complicated. A really complicated non-framework might be easier to learn than write yourself if you can immerse yourself in it. I also like to raid complicated systems for working code–extract instead of extend.
In a lot of ways, well-written software and frameworks are like plays. The characters, the setting, and the stage directions are all spelled out for you. Big complicated software that isn’t designed to be extensible is like a Thomas Pynchon novel–confusing, sprawling, with characters and places coming and going without warning.
To comment on the last sentence in your post, I know you resist the Ruby hype, but duck typing is more like the human contextualized path (and Ruby’s way more readable than Java).
September 15th, 2007 at 10:14 am
hmm, while interesting, im not sure i get what your aiming for…
at first i ended up thinking about function overloading, like what you find in c++ and other languages.
but then i wondered if not what your thinking about is the ability to look up any function at any point in the code and see what it does.
October 16th, 2007 at 1:03 pm
The work happening over at Intentional Software (http://www.intentionalsoftware.com) and their extention of the Domain Specific Languages idea seems to be one way to better incorporate context into programming.