The Sapir-Whorf hypothesis. Does program language “centricity” limit you?
I recently came over from the Java world to work at Microsoft as a program manager on the XML team at Microsoft. From my experience with BEA (and prior) I was a “java centric” developer. I had academic exposure to C++ and some practical exposure to VB, ASP, and a few other languages, but my focus was Java. For me that meant, when I thought in code, I thought in Java. When I looked at code in another language I would interpret it into Java. “Ah, this is the same as a package in Java, or, I’ve never seen anything like that in Java! Crazy …”. With this view of the world, the strategy I took to grow myself as a better developer was to read and learn more and more stuff about the details of Java. Frankly, I figured if it wasn’t covered by Java it probably wasn’t that important to learn.
A confluence of events recently has me thinking about this “language centric” approach to personal growth as a software developer. It started initially by the need to move over to C# as the logical transition for me from Java as my primary working language. Like many in the Java world, I looked at C# as a Java knock off that would be simple to pick up. What I found however, to my surprise, was that there are subtle but significant differences that affected the way I “think” about writing code. Little things like not forcing the file name to correspond with the class (and allowing multiple classes per file and for multiple “packages/namespaces” to be defined in a single file), operator overloading, explicitly defining “virtual” methods, implicit boxing, … (See Dare Obsanjo’s article on the comparison between Java and C#) accumulate such that I began to realize that C# is not just Java warmed over but represents a similar but different “world view” of software development.
Working at Microsoft I have the incredible opportunity to work with people such as Erik Meijer (C Omega, Haskell DB, much more), Anders Hejlsberg (C#, .NET, Delphi, Turbo Pascal, much more), and Ralf Lammel who challenge me to think outside the Java/imperative programming box. All three of these guys take an expansive view on programming language concepts and are constantly incorporating the lessons learned from a variety of language families and dialects into their own thinking – and consequently into the technologies they are creating.
A professor of mine at DePaul, Dr. John Rodgers, introduced the Sapir-Whorf hypothesis to me recently. This hypothesis says that there is a relationship between the language a person speaks and how that person understands the world and behaves in it [1]. The linguistic hypothesis applies directly to programming languages. The idea is “when designing an algorithm to solve a particular algorithm, programmers are heavily influenced by the language constructs available.”[2] A part of this could be just the friction necessary to implement certain programming concepts in different languages however there is more to it. I remember in my early days of developing I worked at a bank with a brilliant developer named Mike Hackett who had read the original Smalltalk 80 book and decided that we could build an object oriented Customer Relationship Management System using COBOL and DB2. Needless to say there was a LOT of friction to build that system. I don’t think it is unreasonable to say COBOL developers did not naturally think in object oriented ways because COBOL did not have the expressiveness to lead developers to think that way. This is similar to the issue pointed out by Benjamin Whorf of Eskimos thinking about camels or the Sahara desert. They may have 20 words for snow which allow more elaborate patterns of communication about snow related strategies (algorithms) but be very primitive in other areas such as things that have to do with heat or animals in another ecosystem. COBOL has a rich data section and is expressive in the area of records (snow) but did not have language constructs to facilitate object orientation (camels). (Ralf pointed out to me that COBOL has had an object oriented version since 1994, but, ahem, this was before that ...).
I am realizing, at least for me, that working with C#, VB.Net, research languages like SpecSharp and C Omega, functional languages such as ML and Haskell (yes, I know Erik and Ralf, Haskell is waaaay superior to ML ;)), and dynamic languages such as Perl and Ruby contain critical lessons for my growth as a software developer. The applicability of the Sapir-Whorf hypothesis for me is that these languages give orthogonal views on solving programming problems and thus provide mental options, a more flexible algorithmic toolbox, even if continuing to work in the same language. For example, my friend Mike Hackett was inspired by SmallTalk but the language we had available was COBOL/DB2 and we were able to architect an extremely successful system because of that inspiration.
Given that I work for Microsoft you might interpret that I am arguing the benefits of Microsoft’s multi-language .NET CLR approach which supports multiple languages over a common virtual machine. I am not making that argument, although it might be true, and I do believe that multi-language support is a good thing. However, the CLR itself embodies a paradigm that influences and constrains the languages that are built on top of it. The risks of language centricity apply to .NET centricity as well (although at a higher level of abstraction). A positive byproduct that I see from the CLR’s multi-language support is pressure on the CLR to expand its constraints, to challenge its preconceptions of the world as new languages get ported to the CLR platform (for an example see IronPython). Also, I see these concepts being weighed in the language design of .NET languages like C# and VB.NET. For example C# 2.0 has been influenced by functional programming languages and I anticipate C# 3.0 will be as well. Over time I believe it is likely the multi-language aspect of .NET will give it an advantage over Java as multiple programming model/language “world views” influence the CLR (many languages are ported are being ported to CLR), and consequently influence the different CLR languages that have these new inspired underlying features available.
My personal take away out of this is that language centricity was not the only or best strategy for growing as a software developer. Exploring and understanding other programming languages particularly from the non-imperative programming paradigms provide new opportunities is highly leveraged, new insights give you new ways to address computational problems.
Are you limiting yourself by focusing exclusively on one language?
Other reading:
[1] Sapir-Whorf hypothesis, https://en.wikipedia.org/wiki/Sapir-Whorf_hypothesis
[1.1] On the Sapir-Whorf hypothesis and its relation to programming languages, https://www.cerezo.name/archives/000005.html
[2] Sapir-Whorf and programming languages, David Cerezo’s Weblog, https://en.wikipedia.org/wiki/Sapir-Whorf_and_programming_languages
[3] Edward Sapir, https://www.yale.edu/linguist/Sapir.html
[4] Benjamin Whorf, https://mtsu32.mtsu.edu:11072/Whorf/mindblw.htm
[5] The Language List, https://people.ku.edu/~nkinners/LangList/Extras/langlist.htm Collected information on about 2500 Computer Languages, Past and Present
[6] History of Programming Languages, O’Reilly Poster, https://www.oreilly.com/news/graphics/prog_lang_poster.pdf
[7] Computer Languages History: https://www.levenez.com/lang/
Comments
- Anonymous
April 29, 2005
Now that the Whidbey and Yukon projects have passed some milestones, the team weblogs are starting to show some activity again. Arpan Desai posts his thoughts on the rather interesting marketing campaign of an XQuery tools vendor who wants you all to demand XQuery support in .NET 2.0. That's not going to happen -- the feature list is frozen, schedules are set, and lots of other plans depend on .NET 2.0 coming out on time and with rock-solid quality. Dave Remy has an interesting post that rel - Anonymous
August 07, 2008
This is a cross post from my blog ( http://blog.remlog.net ) here: http://blog.remlog.net/?p=5 A friend