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
jfruh
Apple syncing patent can't come soon enough
pasmith
New Twitter features borrow from 3rd party clients
Esther Schindler
Open Source Changes the Software Acquisition Process
mikelgan
How to set up continuous podcast play on the new iTunes
David Strom
Five important Windows 7 mobility features
sjvn
Guard your Wi-Fi for your own sake
Sandra Henry-Stocker
Grepping on Whole Words
Sidekick: The Good News & the Bad News
Either way you look at it Microsoft Data Center management did not follow standards or best practices in this failure. In which case it makes me wonder more about the outsourcing of corporate data much less personal data.
- mburton325
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).