A while back I wrote an article about my pet peeves related to XML. Some time soon I hope to write something similar related to my other main weapon of choice, namely, Python. Before that though, I thought it might be interesting to think about the peeve that relates the two. A peeve that joins them at the hip actually. Namely, the English language.
The English language is many things but a precision expression tool is not one of them. This is not a fault of English per se of course. It applies to all human languages. So much of their power and versatility and beauty comes from this lack of precision. The beautiful fuzziness bites of course, when a human language such as English is used as a method of precise expression. Recently I wrote about how the fuzziness of language is such a bane in the area of regulation specification. I cannot think of a starker example of the problem of language than the "regulation" of the behaviour of lumps of silicon. An activity we refer to these days as information systems design. To get these pesky, trumped up bundles of sand and sparks to do our bidding we must find ways of expressing, in languages like English - with as little ambiguity as possible - what goes it, what comes out and what goes on in between...
It is tough to do that well. My favourite book on the topic is Data and Reality by William Kent. One of the examples that Kent uses in the book illustrates the problem nicely. Imagine widgets in the famous expository widget factory. Imagine that these widgets have color and weight. We are interested in managing these widgets with a computer system. There are widgets and each widget will have a color and a weight.
Fine. Now lets think about how we specify the representation and behavior of the system in silicon. Widget domain experts will say things like "that widget has a weight of 6 pounds" but they will not say "that widget has a color of red". That is bad English. They will most likely say "that widget is red". So, in data modelling terms, is color an example of a has_a relationship or an is_a relationship?
We started out with what sounded like a simple situation in which widgets had two attributes : weight and color. How come that 5 seconds later the attributes have sailed off into two separate modelling methods? The issue, as Kent points out over and over again in the book is that human languages such as English create a view of the world and that view of the world finds its way into the models we make and the choices we make in designing computer systems.
Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world
Esther Schindler
If the comments are ugly, the code is ugly
claird
SVG a graphics format for 21st century
pasmith
Take Chrome OS for a test spin
Sandra Henry-Stocker
Solaris Tip: Have Your Files Changed Since Installation?
jfruh
Android fragments vs. the iPhone monolith
mikelgan
What Gizmodo missed about the Pro WX Wireless USB disk drive
Where Google Chrome security fails: the password
I heard mention that the Chrome OS will have some sort of encryption available a la bitlocker. If it's possible to encrypt personal data using another password or key, then it may have potential for very secure data.... And Ubuntu has an 'encrypt home directory' option, perhaps google should follow suit.
- Dann
Join the conversation here
Quick, practical advice for IT pros. Made fresh daily.
Want to cash in on your IT savvy? Send your tip to tips@itworld.com. If we post it, we'll send you a $25 Amazon e-gift card.














Thank you very much for this
Thank you very much for this brilliant article going back to the root of programming.By the way, the example from Kent shows what we tend to use too much, i.e to bring everything back to nouns, forcing us to build upon "weaker" verbs.
The first sentence could be told as "a widget is as heavy as 6 pounds." highlighting that "weight" is actually an adjective turned a noun. For me, this should be an adjective phrase, one that's dramatically absent in languages to program, either influenced by nouns (like with OO or REST) or by verbs (like with Functional Programming).