TITLE: Hype, or Disseminating Results? AUTHOR: Eugene Wallingford DATE: September 20, 2007 6:55 AM DESC: ----- BODY: The software world always seems to have a bandwagon du jour, which people are either riding or rebelling against. When extreme programming became the rage a while back, all I seemed to hear from some folks was that "agile" was a buzzword, a fad, all hype and no horse. Object-oriented programming went through its bandwagon phase, and Java had its turn. Lately it seems Ruby is the target of knowing whispers, that its popularity is only the result of good marketing, and it's not really all that different. But what's the alternative? Let's see what Turing Award winner Niklaus Wirth has to say:
Why, then, did Pascal capture all the attention, and Modula and Oberon got so little? Again I quote Franz: "This was, of course, partially of Wirth's own making". He continues: "He refrained from ... names such as Pascal-2, Pascal+, Pascal 2000, but instead opted for Modula and Oberon". Again Franz is right. To my defense I can plead that Pascal-2 and Pascal+ had already been taken by others for their own extensions of Pascal, and that I felt that these names would have been misleading for languages that were, although similar, syntactically distinct from Pascal. I emphasized progress rather than continuity, evidently a poor marketing strategy. But of course the naming is by far not the whole story. For one thing, we were not sufficiently active -- today we would say aggressive -- in making our developments widely known.Good names and aggressive dissemination of ideas. (Today, many would call that "marketing".) Wirth views Pascal, Modula, and Oberon as an ongoing development of 25 years that resulted in a mature, elegant, and powerful language, a language who couldn't even imagine back in 1969. Yet for many software folks, Modula was a blip on the scene, or maybe just a footnote, and Oberon was, well, most people just say "Huh?" And that's a shame, because even if we choose not to program in Oberon, we lose something by not understanding what it accomplished as a language capable of supporting teams and structured design across the full array of system programming. I never faulted Kent Beck for aggressively spreading XP and the ideas it embodied. Whatever hype machine grew up around XP was mostly a natural result of people becoming excited by something that could so improve their professional practice. Yes, I know that some people unscrupulously played off the hype, but the alternative to risking hype is anonymity. That's no way to change the world. I also applaud Kent for growing as he watched the results of XP out in the wild and for folding that growth back into his vision of XP. I wonder, though, if the original version of XP will be Pascal to XP2e's Modula. By the way, the Wirth quote above comes from his 2002 paper Pascal and Its Successors. I enjoy hearing scientists and engineers tell the stories of their developments, and Wirth does a nice job conveying the context in which he developed Pascal, which had a great many effects in industry but more so in the academic world, and its progeny. As I read, I reacted to several of his remarks:
Its foundations reached far deeper than simply "programming without go to statements" as some people believed. It is more closely related to the top-down approach to problem solving.Yes, and in this sense we can more clearly see the different mindset between the Structured Programming crowd and the bottom-up Lisp and Smalltalk crowd.
Data typing introduces redundancy, and this redundancy can be used to detect inconsistencies, that is, errors. If the type of all objects can be determined by merely reading the program text, that is, without executing the program, then the type is called static, and checking can be performed by the compiler. Surely errors detected by the compiler are harmless and cheap compared to those detected during program execution in the field, by the customer.Well, yeah, but what if I write tests that let me detect the errors in house -- and tell more about my program and intentions than manifest types can?
The goal of making the language powerful enough to describe entire systems was achieved by introducing certain low-level features.... Such facilities ... are inherently contrary to the notion of abstraction by high-level language, and should be avoided. They were called loopholes, because they allow to break the rules imposed by the abstraction. But sometimes these rules appear as too rigid, and use of a loophole becomes unavoidable. The dilemma was resolved through the module facility which would allow to confine the use of such "naughty" tricks to specific, low-level server modules. It turned out that this was a naive view of the nature of programmers. The lesson: If you introduce a feature that can be abused, then it will be abused, and frequently so!This is, I think, a fundamental paradox. Some rules, especially in small, elegant languages, don't just appear too rigid; they are. So we add accommodations to give the programmer a way to breach the limitation. But then programmers use these features in ways that circumvent the elegant theory. So we take them out. But then...
The absence of loopholes is the acid test for the quality of a language. After all, a language constitutes an abstraction, a formal system, determined by a set of consistent rules and axioms. Loopholes serve to break these rules and can be understood only in terms of another, underlying system, an implementation.Programming languages are not (just) formal systems. They are tools used by people. An occasional leak in the abstraction is a small price to pay for making programmers' lives better. As Spolsky says, "So the abstractions save us time working, but they don't save us time learning." A strong culture is a better way to ensure that programmers don't abuse a feature to their detriment than a crippled language.