Lambda the Ultimate

Bjarne Stroustrup (creator of C++) gave an interview to Linux Journal last month. This must be the third time I've read that he considers C++ a multi-paradigm language. Multiparadigm programming is one of my hobby horses so I appreciate his efforts. Of course, his definition is a little limited, but at least his heart is in the right place.

I think of C++ as a multi-paradigm programming language. That is, C++ is a language that supports several effective programming techniques, where the best solution to a real-world programming problem often involves a combination of these techniques. Thus, I encourage people to learn data abstraction (roughly, programming using abstract classes), object-oriented programming (roughly, programming using class hierarchies) and generic programming (roughly, programming using templates). Furthermore, I encourage people to look for combinations of these techniques rather than becoming fanatical about one of these paradigms because it happens to be a great solution to a few problems.

Multi-paradigm programming is er.. a paradigm. It is not enough the the language supports different styles, it has to provide a coherent model for combining them, using each where most appropriate. Having ten ways for doing every task is, contrary to what some people think, not a very good way for enhancing programmer productivity.

Another thing. Data abstraction, OOP and generics are not the only paradigms worth putting in the mix. Even if we remain in the imperative world, we should at least support the language extension paradigm (macros) and data driven programming (i.e., make it easy to move as many decisions as needed to outside tables and config files).

Agreed, having ten ways to do something is not necessarily good and can even harm. As a tentative rule of thumb, a good multiparadigm (MP) language should offer one obvious best way, maybe two. Additional solutions would appear contorted and unnatural.

Multi-paradigm programming is er.. a paradigm.

Cute. What I would say is that MP is a capability, not an imposition. In fact it's the opposite -- escape from single-paradigm imprisonment. Any language that (lyingly) billed itself as MP, but then forced me to write in a 'peculiarly MP' way, would not win my favor. Conversely I might happily write a pure OO app in a MP language, knowing all the while that a sudden need for functional touches would not disrupt. If none came, then I would just finish in 100% OO style. So be it. The motto of the right tool for the job is apropos. Pick the one that works for the task, or any combination thereof.

I agree that a good MP language must 'provide a coherent model for combining them,' and this is why I so respect the Mozart/Oz research, which took the trouble to compare real-world languages and resolve the principal orthogonal axes. C++ was not designed that way.

Still, DP-COOL shows how far OO languages can be taken in orthogonal directions. FC++ blows me away. That C++ can support such a tectonic paradigm shift is perhaps a tribute to the language. Yet I believe that Stroustrup has something far weaker in mind when he says 'multiparadigm.' His statement regarding generic programming refers not to FC++ and kin, but rather to STL and kin. The C++ standards committees were not dreaming of FC++ when they designed C++ templates (happy side effect though it was).

My own notion of paradigms is the Big Four: imperative, object-oriented, functional, and logic programming. This division is depicted graphically on the Multiparadigm.org logo. (I would use the term declarative to subsume both functional and logic idioms.) So I would have to think more about your proposals for new first-class paradigms, but remain open-minded.

In any event the driving philosophy behind DP-COOL is to accept what industry has accepted (Java and C++), then investigate how to empower them with new idioms. So they do not have the luxury of designing new, clean MP languages as such. My hat is off to them for trying.

The heat and pressure of stubbornly confining oneself to a single modality can create gems. STL is an example. Its creator offers amusing vignettes about programming paradigms. While I advocate multiparadigm languages, the world probably needs more Stepanovs, who definitely don't. For all that, however, his methods are DP-COOL in spirit - stretching languages beyond their design. Now to the amusement. Here are the major language paradigms of the world as viewed by Alex Stepanov.

Money-Oriented Programming

Java is clearly an example of a money oriented programming (MOP). As the chief proponent of Java at SGI told me: "Alex, you have to go where the money is." But I do not particularly want to go where the money is - it usually does not smell nice there.

OO Gook

I spent several months programming in Java....for the first time in my life programming in a new language did not bring me new insights. It keeps all the stuff that I never use in C++ - inheritance, virtuals - OO gook - and removes the stuff that I find useful.

Bigoted Genericity

STL, at least for me, represents the only way programming is possible. It is, indeed, quite different from C++ programming as it was presented and still is presented in most textbooks. But, you see, I was not trying to program in C++, I was trying to find the right way to deal with software.

Since we are proliferating paradigms, it seems only fitting to include Stepanov's reaction to Occam's Razor:

As the editor of his Opera Omnia Gideon Gal used to say: "But the fellow was really mad!"

I only recently discovered that much of the Turing Award series is available as the book ACM Turing Award Lectures: The First Twenty Years. Highly recommended.

If anyone knows where to find an articulate flame against the ACM and their pay-and-dont-share policy for reading the best works of computer science, please send me a link. I would like to know that I'm not alone in my frustration.

The Brew Project is working on an eponymous language (a successor to generics-capable Java 1.5 and Pizza), as described in a paper from the sister MPOOL'01 conference. Maybe Brew merits its own LtU homepage blurb (Ehud?). What I find interesting is their use of OO design patterns as language weakness detectors.

Most mainstream object-oriented languages...make it easy to encapsulate implementation details, to abstract over implementation types, and to refine existing data structures [but fail to] provide good support for abstracting over control....By contrast, statically typed functional languages, such as ML and Haskell, make it easy to abstract over control [but fail to] provide adequate support for encapsulation and abstraction over implementation types and make it difficult to refine existing data structures. Adding a new variant to an existing data type requires all functions operating on this data type to be modified.

We are currently developing Brew as a successor language to Java. In previous research, we have analyzed object-oriented design patterns for gaining insight into what language features would be needed in better object-oriented languages. Since the solutions of design patterns are influenced by the chosen implementation language, an analysis of the solutions indicates possible improvements to the language. We are designing Brew based on Java syntax but with an object model derived from this analysis of design patterns. In addition to the support for functional programming, Brew will provide a separation of subtyping from code reuse and a representation of classes as first-class objects.