RemLog

Non-Recursive Post Order Depth First Traversal in C#

2010-03-16T18:39:47Z

I was looking around for a non-recursive post-order traversal algorithm and it turned out to be more complex than I thought which surprised me. I mean a recursive post order depth first traversal is so simple.

static void recursivePostOrder(Node node)
{
    foreach (var n in node.Children)
    {
        recursivePostOrder(n);
    }
    // Do action
    Console.WriteLine(node.Id);
}

And a non-recursive Pre Order Depth Traversal isn’t too difficult:

static void preOrder(Node root)
{
    Stack<Node> s = new Stack<Node>();
    s.Push(root);
    while (s.Count > 0)
    {
        var n = s.Pop();
        // Do Action
        Console.Write(n.Id);
        foreach (var child in n.Children.ToArray().Reverse())
        {
            s.Push(child);
        }
    }
}

After doing some searches and consulting some colleagues I couldn’t find a canonical non-recursive post order depth first algorithm (at least one that I could understand quickly). Several of my colleagues also initially thought it was simple and then went back to their offices to later send me alternatives. The essential challenge is to be able to know when the traversal has gone up a level and only at that point doing the “visit” action on the parent node. Here is the most concise alternative I came up with that does not use a full visited list (the full program below):

private static void nonRecursivePostOrder(Node root)
{
    var toVisit = new Stack<Node>();
    var visitedAncestors = new Stack<Node>();
    toVisit.Push(root);
    while (toVisit.Count > 0)
    {
        var node = toVisit.Peek();
        if (node.Children.Count > 0)
        {
            // PeekOrDefault is an extension helper, see full program below
            if (visitedAncestors.PeekOrDefault() != node)
            {
                visitedAncestors.Push(node);
                toVisit.PushReverse(node.Children); // PushReverse is a helper, see full program below
                continue;
            }
            visitedAncestors.Pop();
        }
        Console.Write(node.Id);
        toVisit.Pop();
    }
}

The idea is here is to, in addition to the normal DFS toVisit stack, keep a visitedAncestors stack. In the depth first traversal when we encounter a parent node (node.Children.Count > 0), if it hasn’t been visited yet (visitedAncestors.PeekOrDefault() != node), then add the children to the stack and don’t process the parent yet (leave the parent on the toVisit stack). The next time the parent node is hit, the children will have already been processed then remove it from the visitedAncestors stack (visitedAncestors.Pop()) and drop down to process the parent node.

There are multiple algorithms out there to accomplish this. Several of my colleagues sent me their versions. One version kept the state of child enumeration in the stack along with the node in the toVisit stack. Another similarly used a structure in the toVisit stack that had a visited boolean along with the node. This one also used an interesting linked list approach to the toVisit stack that allowed the children to not have to be reversed (if the childlist is forward only as it is in many trees then it has to be materialized in order to reverse it). Still another colleague offered an algorithm in which the toVisit stack contains a boolean that keeps track of direction (down/child or next/sibling) and makes the action decision accordingly. If there is interest I can likely publish these algorigthms as well. What I am not sure of is whether there is a canonical “best” (complexity, space) algorithm for a non-recursive post order traversal.

Here is a full sample program with the helper methods and sample tree data structure:

using System;
using System.Collections.Generic;
using System.Linq;

namespace ConsoleApplication2
{

    class Program
    {
        static void Main(string[] args)
        {
            //       a
            //   b    c    d
            // e  f  g    h i
            // dfs: efbgchida
            var root = makeTree();
            nonRecursivePostOrder(root);
            Console.WriteLine();
        }

        private static void nonRecursivePostOrder(Node root)
        {
            var toVisit = new Stack<Node>();
            var visitedAncestors = new Stack<Node>();
            toVisit.Push(root);
            while (toVisit.Count > 0)
            {
                var node = toVisit.Peek();
                if (node.Children.Count > 0)
                {
                    if (visitedAncestors.PeekOrDefault() != node)
                    {
                        visitedAncestors.Push(node);                        
                        toVisit.PushReverse(node.Children); 
                        continue;
                    }
                    visitedAncestors.Pop();
                }
                Console.Write(node.Id);
                toVisit.Pop();
            }
        }

        private static Node makeTree()
        {
            var e = new Node("e");
            var f = new Node("f");
            var b = new Node("b", new List<Node> { e, f });
            var g = new Node("g");
            var c = new Node("c", new List<Node> { g });
            var h = new Node("h");
            var i = new Node("i");
            var d = new Node("d", new List<Node> { h, i });
            var a = new Node("a", new List<Node> { b, c, d });
            return a;
        }
    }

    static class StackHelper
    {

        public static Node PeekOrDefault(this Stack<Node> s)
        {
            return s.Count == 0 ? null : s.Peek();
        }

        public static void PushReverse(this Stack<Node> s, List<Node> list)
        {
            foreach (var l in list.ToArray().Reverse())
            {
                s.Push(l);
            }
        }
    }

    class Node
    {
        public string Id;
        public List<Node> Children;
        public Node(string id)
        {
            Id = id;
            Children = new List<Node>();
        }

        public Node(string id, List<Node> children)
        {
            Id = id;
            Children = children;
        }

        public override bool Equals(object obj)
        {
            var node = obj as Node;
            if (node != null)
            {
                return node.Id == this.Id;
            }
            return false;
        }

        public override int GetHashCode()
        {
            return Id.GetHashCode();
        }
    }
}

Meeting Mike Vincent

2008-09-16T20:15:26Z

(This a cross-post from remlog.net: http://blog.remlog.net/?p=33)

Yesterday, I had the pleasure of meeting Mike Vincent, who is on the Board of Directors of INETA (International .NET Association) which works to coordinate a huge community of .NET user groups. INETA, is a non-profit almost entirely driven by volunteers who have an interest in sharing .NET knowledge and helping .NET user groups to be successful.

Mike was in town for an INETA board meeting, the Visual Studio Extensibility (VSX) Conference and to meet with various MS product teams to see how we could work together to improve the .NET User group experience.

Mike was meeting with Harry Pierson (IronPython PM) and Bill Chiles (Dynamic Language Runtime Lead) to discuss INETA and dynamic languages so I was lucky enough to tag along and ask some questions.

One question we asked was how important Mike saw Visual Studio Integration for the Iron languages. We get feedback at times that it is more important to have a lightweight, quick to bring up, quick to close down, editor for script editing than full VS integration. Others tell us, make sure that we integrate well with VS now since this is their primary code editing tool. Mike's response was that VS integration is "a big deal" for adoption by the mainstream .NET developer and consequently a must have.

Mike mentioned a cool concept that INETA is embarking on around speakers. INETA is known for its speaker's bureau (and virtual user groups) which has been national in scope. They are now introducing regional speakers bureaus that will enable folks to speak regionally at smaller venues which can lead to the larger national opportunities. Harry and I have talked about similar ideas for folks at Microsoft to start speaking at smaller venues that could lead to bigger opportunities such as Tech Ed and PDC. Mike also mentioned that INETA is also heavily encouraging virtual presentations, recording live presentations, and having them available via the INETA website. I wonder if there is some way Microsoft could leverage that as well, pointing customers to these presentations as they become available ... hmm, a todo for me.

I asked Mike how he viewed dynamic languages in .NET. The value he sees is that advantage of providing more tools for the .NET developer's toolbelt. "Dynamic languages allow you to do some things much more easily than a static language". The low ceremony aspects of IronPython and IronRuby in particular help.

Mike has special interest in a project to allow NUnit tests to be written in IronPython. Using the low ceremony language like IronPython can make this feel very much like a DSL for testing. We didn't get a chance to talk about it much but I look forward to learning more about it. Harry has some ideas for how the IronPython team might be able to help.

I asked Mike what the major issues with .NET and in his constituent user communities. The most significant one that came to mind for him was the problem with shops remaining on older releases (many in the user groups are still using .NET 1.1). Developers get frustrated since so many of the user groups and Microsoft talks are focused on new features (LINQ, et al) which are not yet available to them. He recognizes the tension between customers who feel there are too many releases and pressure from other customers (and the competitive landscape) to keep innovating. Perhaps, we strategized, Microsoft should do more to innovate around helping customers move successfully from one .NET release to the next.

It was great to meet Mike and hear about more about INETA. It appears INETA has great momentum, with greater than 250 active user groups and over 100,000 active developers in North America, and a reach of approximately 1.2 million developers world-wide. I look forward to working with Mike and INETA to improve the .NET user group experience as well as .NET developers in general.

Rem

Lunch with a Dynamics Languages Braintrust

2008-09-15T23:39:01Z

One of the biggest privileges I have is the quality of people I get to hang out with here at Microsoft. Within the Visual Studio Languages GO team and the DLR team there is a loyal group of us (actually I am a noobie) who walk down from Redmond campus to the same Chinese place multiple times during the work week. Each time there is a subset of us that make it but almost always there is enough for a quorum and we head on down. There is not a single one of these lunches that goes by that I don't get new insights, a few new facts, a good laugh, and a few blog ideas. Not just technical stuff. A big subject of today's lunch was Dino's trip to Burning Man (wow, I want to go), but we also covered things like the economics of persistent data stores in the cloud, changes in the way Microsoft views Open Source, and Tina Fey's portrayal of Sarah Palin. It reminds me that much of our most important activities and learning are NOT in meeting rooms but are at lunches and in hallways.

I took some pictures around the table at lunch today. Ok, they don't look like a brain trust with their mouths full but believe me these guys are the sh*t.

Curt (IronCurt, Dev on IronPython and IronRuby), John (IronRuby PM), and Tomas (Lead Dev on IronRuby).

Jim (Tester IronRuby), Dino (Lead Dev on IronPython), and Harry (PM for IronPython)

Jimmy (PM on all sorts of IronRuby and IronPython stuff), Bill (PM for DLR), and me.

I can think of many times in my career when I would not attend these types of lunches. Too much work to do. Funny thing, I think I got more accomplished at lunch today than two of my scheduled meetings.

rem

Sapir-Whorf Revisited

2008-08-07T21:37:54Z

This is a cross post from my blog (http://blog.remlog.net) here: http://blog.remlog.net/?p=5

A friend from Microsoft reminded me of a post I did on my MSDN blog when I was previously at Microsoft on the Sapir-Whorf hypothesis (roughly, the hypothesis that your language shapes your view of reality) and its application to programming languages. The blog was: The Sapir-Whorf hypothesis. Does program language “centricity” limit you? At that time (April 2005) I was just making the transition from Java to C#, learning some ML in the CS master's program at Depaul, and, getting influenced by a few quite a bit by a few Ph.D. friends down the hall at Microsoft (in particular Erik Meier and Ralf Lammel). I had nearly forgotten the post but looking back on it I guess I was fated to end up in a group focused on implementing programming languages such as Ruby and Python (and perhaps other emerging languages over time).

By the way, it appears that Sapir-Whorf has more acceptance in programming languages and methodologies than it does in psycho-linguists circles (here, and here) at least at the extreme end of the language determinism spectrum.

On another note Sapir-Whorf is being invoked regularly in relation to Behavior Driven Development (BDD) as implemented in RSpec the popular ruby testing framework. BDD is heralded as an evolution of Test Driven Development (TDD to get to the promised land of TDD where tests become executable specifications. Developers move from using the verbiage of "test" and "assert" to words like "describe" and "should" using the business domain language as much as possible. There are many articles and blogs (just web search 'rspec sapir-worf') linking RSpec to the Sapir-Whorf hypothesis (many of them pretty in a pretty cavalier manner) . The general idea appears to be that because BDD changes the words for writing "tests" (whoops, I used the wrong word there), I mean "specifications", which in turn influences the developer's to think differently about tests. I generally agree with the conclusion, we are using a variation of RSpec to test IronRuby completion and we think of it very much like a language specification, however I am not so sure that Sapir-Whorf is the right theory to support this change in perception. I am no expert whatsoever but it seems that the language determinism point of Sapir-Whorf is about an entire language shaping an individual's view of reality based on the inventory of words available to express a concept. It seems like BDD's effectiveness is orthogonal to Sapir-Whorf since the developer is already likely to know and understand the concept of "test" and "assert". RSpec is really influencing a mindset by introducing and enforcing words that will invoke a "set of assumptions, methods, or notations" that create a "powerful incentive" to "adopt or accept" a set of "behaviours, choices, or tools" (paraphrase of the wikipedia entry for mindset). I like the response that John Roth gave here along these lines. This is all just quibbling though. RSpec is a most excellent step forward.

rem

Back To Microsoft

2008-08-07T21:28:00Z

I am back at Microsoft! In October of 2007 I left my developer role on the XML Team and headed out to a local Redmond consulting firm and then to an Internet startup uboost based in Honolulu. I recently came back to be Lead Program Manager on the Visual Studio Languages Growth Opportunity (GO) team. If you are interested I wrote a blog on my experience on my blog at http://blog.remlog.net here.

I am having a great time getting getting geeked out on languages and working with a tremendous team. More blogs on my personal blog and crossposted here where it makes sense.

Dave

Changing status, moving forward

2006-06-16T20:36:00Z

A quick note about what I am up to these days. Lots of folks have been asking me if I am going to ever blog again - for good reason considering the timing of my blogs so far, but, yes, I plan to get started again. My friend and guy in the office next door at Microsoft, Ralf Lammel, has started his new blog (http://blogs.msdn.com/ralflammel/) so perhaps that will inspire me. I love to read Ralf's papers and email (and I am sure blogs) since he writes in his own interesting, quirky style. Ralf came over from Germany and speaks German natively but I'm not sure that completely explains his style :) I think it is more that he has a sense of play and humor even about complex computer science subjects and it shows through in his writing. I have had the luxury to publish several papers with him and I always get a good laugh and a lot of enjoyment working with him.

My role at Microsof has changed a bit in the last few months. For awhile there I was the program manager for XLinq (XML Language Integrated Query) technology which is the XML specific implementation for LINQ (http://msdn.microsoft.com/data/ref/linq/) then, for a briefly (a few months) I took on the Group Program Manager role for the XML team. This put me into a middle management role that I really did not like, so, when we (Microsoft) decided to consolidate our XML team into a larger data programmability team I jumped at the opportunity to move back over into a development role. I am now working hands on a very cool XML developer tool (can't say specifically what quite yet) that uses WPF (also known as Avalon) and XLinq extensively. I look forward to doing some future blogs in these areas. So far I reeeaaally enjoy working with these technologies. I have already had the chance to work with XLinq quite a bit and so I knew what a pleasure it is to write XML code in that technology (who would of thought - a "pleasure" to write XML code?). WPF is quite a bit different but I am super impressed. From my perspective it has a consistency of architecture and composability that makes it super powerful yet very approachable. The big challenge with WPF is there are not yet mature tools for it and the community around it is just forming. So when you run into an issue it is often not as simple as just doing a web search to find the answer. Also there is not a huge amount of documentation out there yet (although Chris Sells book is really good). If the app that I am working on is any indication the next generation of "fat client" apps written with WPF will be amazing.

The other big thing that is going on with me is that I am doing Ironman Coeur D'Alene on June 25. Which is about 8 days from now. I have done the "iron training" and should feel confident but I have to admit I am freaking out a bit. If you want to follow my progress (for some strange reason) it should be available on Ironman Live (my number is: 1455). I will definitely be slow. I am guessing 14 hours or so but I really have no idea. I just hope to finish ...

A week later my wife and I are heading over to Tuscany, Italy for a two week bike trip from Fiorenza (a.k.a., Florence) to Rome. I hope I can ride by then!

Anyway, more blogs soon although I suspect I will have a hard time keeping up with Ralf.

thanks! rem

XNames and Expanded Names

2005-09-23T05:51:00Z

At my XLinq PDC2005 talk and in the XLinq Overview Document one of the differences I mentioned between XLinq and DOM is the treatment of XML Names in XLinq. XLinq's abstraction for XML Names is a class called XName which is the only way an XML Name shows up anywhere in the API. You seldom have to construct an XName since there is an implicit conversion from string. For example to construct an XElement with a local name Foo that has a namespace of http://myCompany.com you could do the following:

XElement foo = new XElement("{http://myCompany.com}Foo", ... any value or children of Foo ...);

So what is that string there with the curly braces in the constructor you ask? XLinq calls it the Expanded Name. This idea is very much inspired by James Clark's paper on XML Namespaces in which he talks about Universal Names defined as a local name and a qualifying URI. In his article he shows that XML Names are fundamentally these Universal Names (or what XLinq calls Expanded Names) and prefixes/default namespaces are simply shorthand for representing this full name (in a way that would work with XML 1.0 since XML was initially defined without XML Namespaces). He gives example in his paper of how default namespaces and prefixes map into Universal Names.

This is essentially what XLinq does in its API. When the XML is loaded into memory the default namespaces and prefixes are resolved to their corresponding Expanded Names and that is they way you deal with them in the API, via XNames. Namespace declarations (xmlns attributes) are retained as attributes in the in-memory tree and on output are used to associate prefixes with namespaces all over again. In other words from XLinq's perspective default namespace declarations and prefix declarations are purely serialization options. If you want to associate a prefix with a namespace in your output, say when creating a document from scratch, then you add an xmlns attribute right where you want the prefix defined. There are helper methods in XLinq planned (CreateNamespacePrefix, CreateDefaultNamespaceDecl - or something) but I put some notes at the end of the XLinq overview doc on how to do that manually if needed. The only trick is knowing the namespace of the xmlns attribute (http://www.w3.org/2000/xmlns). For example to declare the prefix ns and associate it with http://myCompany.com you could add the following attribute where you want it defined.

new XAttribute("{http://www.w3.org/2000/xmlns/}ns", http://myCompany.com),

Anyway, I think James Clarks article on XML Namespaces is one of the better explanations on the subject and understanding that XML Names are really namespace+local name simplifies working with names in XLinq. I find that the XML code that I write, which pretty much always has namespaces involved, is quite a bit clearer and cleaner than the equivalent DOM code.

This is an area we are looking for feedback. Lemme know what you think.

cya,
rem

Anders unveils LINQ! (and XLinq)

2005-09-13T22:29:00Z

In Jim Allchin's keynote At PDC2005 today Anders Hejlsberg showed the LINQ project for the first time. LINQ stands for Language Integrated Query. The big idea behind LINQ is to provide a consistent query experience across different "LINQ enabled" data access technologies AND to allow querying these different data access technologies in a single query. Out of the box there are three LINQ enabled data access technologies that are being shown at PDC. The first is any in-memory .NET collection that you foreach over (any .NET collection that implements IEnumerable<T>). The second is DLinq which provides LINQ over a strongly typed relational database layer. The third, which I have been working on for the last 6 months or so (along with Anders and others on the WebData XML team), is XLinq, a new in-memory XML programming API that is Language Integerated Query enabled. It is great to get the chance to get this technology to the next stage of development and get all of you involved. The LINQ Preview bits (incuding XLinq and DLinq) are being made available to PDC attendees. More information on the LINQ project (including the preview bits) are also available online at http://msdn.microsoft.com/netframework/future/linq.

More specifically about XLinq, XLinq is a new in-memory XML programming API that is LINQ enabled. Essentially it is a redesigned XML DOM API that was built from the ground up with lessons from the last 10 years of DOM as well as with Language Integrated Query in mind. There are some significant innovations from DOM that are outlined in the XLinq overview document but one very important aspect was taking advantage of modern language features such as generics, nullable types, and especially IEnumerable<T>. XLinq takes advantage of the 30 some odd Standard Query Operators (like where, select, orderby, groupby, etc.) from LINQ and then layers in a set of XML specific query operators that help when you are querying an XML tree - operators like Descendants, Ancestors, Parent, etc. With the standard query operators combined with the XML specific query operators you get fully featured XML Query functionality that is Language Integrated (assuming the the language implements the LINQ pattern, which C#, VB, and C++ are planned). In the samples that install with the LINQ bits there are hundreds of queries that you can check out including many from the XQuery Use Cases. There is an Xlinq overview doc that is posted on the LINQ Project site. Here is a direct link: http://download.microsoft.com/download/c/f/b/cfbbc093-f3b3-4fdb-a170-604db2e29e99/XLinq%20Overview.doc.

Anders has a detailed presentation tomorrow on LINQ and I am presenting more on XLinq on Friday. I'll post more details over the days and weeks ahead. I look forward to your feedback!

rem

PDC prez: The .NET Language Integrated Query Framework with XML Data

2005-09-02T00:02:00Z

I will be doing a presentation at PDC this year on Using the .NET Language Integrated Query Framework with XML Data. The presentation is on Friday (8/16) at 10:30. Hope to see you there!

Here is the abstract:

One of the key challenges to working with XML data has been the impedance mismatch between XML and programming languages. This session introduces future advances Microsoft is making for the "Orcas" release of Visual Studio in programming languages and frameworks to help integrate XML and queries with C# and Visual Basic. The advances include a framework for navigating, querying, and transforming XML that is both easier to use and more efficient than current XML programming techniques. This framework marries the capabilities of XPath, XQuery, and the DOM with the language integrated query framework planned for C# and Visual Basic. It is suggested that you attend "The .NET Language Integrated Query Framework: An Overview" before attending this session.

Luca is doing a talk on Using the .NET Language Integrated Framework with Relational Data and blogs about it here: http://blogs.msdn.com/lucabol/archive/2005/07/14/438824.aspx

The Sapir-Whorf hypothesis. Does program language “centricity” limit you?

2005-04-07T01:33:00Z

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, http://en.wikipedia.org/wiki/Sapir-Whorf_hypothesis

[1.1] On the Sapir-Whorf hypothesis and its relation to programming languages, http://www.cerezo.name/archives/000005.html

[2] Sapir-Whorf and programming languages, David Cerezo’s Weblog, http://en.wikipedia.org/wiki/Sapir-Whorf_and_programming_languages

[3] Edward Sapir, http://www.yale.edu/linguist/Sapir.html

[4] Benjamin Whorf, http://mtsu32.mtsu.edu:11072/Whorf/mindblw.htm

[5] The Language List, http://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, http://www.oreilly.com/news/graphics/prog_lang_poster.pdf

[7] Computer Languages History: http://www.levenez.com/lang/