Although, this brilliant observation was made in 1960 before computing
really took off, it explains one aspect of computing very nicely - the
plethora of programming languages out there in the real world.
Without having to stray beyond what would be considered the mainstream
in commercial IT, we have Java, C#, C++, VB, Perl, Python, PHP,
Javascript, Delphi, Cobol, DBase, etc., etc. Not to mention the eclectic
mix of languages embedded into products such as VBA (in Microsoft Office
for example), Python (in Paintshop Pro), or Lisp (in Autocad).
Non-IT people looking at this smorgasbord of syntax quite understandably
develop retinal glaze syndrome. They hope against hope that the whole
thing will just goes away some day. The questions ripple out from the
water cooler. 'Why do you guys in development want dozens of types of
hammers when all you have are nails?'. 'Why doesn't everyone just use
Java?'. 'Why doesn't everyone just use C#?'. And so on.
IT people are also inclined to see the diversity as bad or at least
conclude that the benefits of a multilingual approach are outweighed by
the costs. A consequence of this is that mono-lingualism is rife in
commercial IT. Some of the uses I see Visual Basic being put to, or Java
being put to - all because of a corporate edict of mono-lingualism - are
downright sad. Sad because of lost opportunities - not only to deliver
better product quicker, but also to deepen the knowledge of design and
implementation techniques in the development team.
I can see both sides of the argument for and against multi-lingualism in
application development. Having said that, I believe too much has been
made of the bad and not enough made of the good aspects of it.
I would like to take a few paragraphs to argue that diversity in
programming languages is a fundamentally good thing and that effort made
to get a team to open their minds to other languages can pay rich
dividends in terms of quality and productivity.
Let's start with Wigner's observation about simplicity being a result of
counterbalancing complexity in language. I would argue that system
design and implementation is essentially a fight against real world
complexity. This fight is one we conduct with the most powerful weapon
we have - language. I'm using the term 'language' here quite loosely -
in a sort of semiotic way. I include data flows, swim lane diagrams,
mathematical equations and the words of programming languages under the
rubric of 'language'.
The first step in solving any problem is finding a way to express it.
From that humble beginning, we embark on more and more refined forms of
expression until we have reached something that can be understood by a
computer. The richer our toolbox in terms of modes of expression that
machines can be made to understand, the better. By picking simple modes
of expression out of out language toolbox, we actively tame the
complexity rather than simply sweep it under the carpet. We express
ideas in a way that other humans that share our understanding of the
language can understand. The easier it is to understand, the easier it
is to modify when our needs change.
Each programming language, be in Visual Basic, or Python or Java carries
with it a core set of language concepts - modes of expression. These
concepts are the result of looking at the world in a particular way. If
you have the core language constructs of multiple languages in your head
at one time, you literally have multiple ways of looking at the world;
multiple ways of viewing the problem at hand; and multiple tools to test
out when trying to tame the complexity of the real world.
The multi-view approach that happens naturally if you are skilled in the
arts of more than one language need not necessarily result in a
multilingual solution to any given commercial IT problem.
I find for example, that having tried my toolbox of complexity tamers -
a toolbox that includes Smalltalk, Lisp, Clipper, C, Java, Python etc. -
I can work in any one language if required by 'porting' the modes of
expression I need into the host language on a best fit basis. It works
well sometimes and not so well in other times but it is a useful
technique nonetheless.
The latest language I have added to my repertoire is the language of
drawing. I can now produce a passable rendition of an apple sitting on a
table. No big deal but I used to draw like a six year old so this is
real progress for me. Now, I will never amount to anything as an artist
(and I certainly will not be suggesting that some commercial IT systems
are best expressed in oil on canvas) but, I have found the experience
has colored - yet again - the way I approach application design and
implementation.
Drawing is all about inference. Inferring the presence of something in
three dimensional space through a combination of shadow, highlight, form
and texture on a two dimensional sheet of paper. It has taught me the
very powerful notion that sometimes it is easier to model something in
terms of its effects on everything else rather than model it directly.
It has taught me the power of zooming in on something by only expressing
what it is not. For example using background forms to 'draw' foreground
forms purely by inference.
I have already put some of these new forms of expression I have picked
up to use in my work. A few more tricks have been added to my complexity
taming toolbox - regardless of the language I am working in. Moreover, I
literally look at the world a different way. I see shadows and
reflections and nuances of color that I literally never saw before. My
perception of the world is richer for it and I am a (incrementally) a
better programmer because of it.
I recommend the experience - just as I would recommend picking up any
language. Your ability to tame complexity in your work can only benefit.
[1] http://www-gap.dcs.st-and.ac.uk/~history/Mathematicians/Wigner.html
http://seanmcgrath.blogspot.com
