When I was walking to shul this Shabbos, I came accross two Verizon workers at the corner of Murray and Phillips pulling a cable out of a manhole cover. I asked, “what are you pulling?” They cheerfully replied, “fiber optics … it’s coming to this area real soon now.” Awesome.
Nice Verizon workers … who knew? FIOS in my house … awesome.
Paul Krugman’s recent discussion of the debate between “freshwater” and Keynesian economists reminds me of the debate between functional and object-oriented programming language researchers. In Krugman’s review of Justin Fox’s excellent The Myth of the Rational Market
One of the great things about Fox’s writing is that he brings to it a real understanding of the sociology of the academic world. Above all, he gets the way in which one’s career, reputation, even sense of self-worth can end up being defined by a particular intellectual approach, so that supporters of the approach start to resemble fervent political activists — or members of a cult.
This is certainly true in the programming language community! A faculty-members who’s career has focused on metatheory of functional programs needs to believe that functional programming is the one right and true path. Object afficianados suffer from the same affliction, but it is somewhat less common among them because they can fall back on industry applicability to justify their work.
In my opinion, these debates are immensely silly for two reasons. Intellectual frameworks, like software process, is immensely important and can dramatically alter the results of your endeavor. Secondly, we should not focus on debating, but instead on resolving debates with sound evidence. With respect to programming languages this means collecting empirical data on how programming language choice affects student learning, programmer thinking and productivity, software reliability and maintainability, etc. Designing experiments to evaluate programming languages is very hard, but most programming language research is also hard … and less important.
Most software projects are built in layers. The idea is to hide implementation details from one area of functionality to another. This allows software engineers working on one piece of functionality to change the implementation details without affection other pieces of functionality.
Every project has both claimed to be built and layers and violated the layers constantly. Build a language to constrain them.
