In Part I, I related a resurgence in interest in multi-paradigm design about thirteen years after its first appearance.
In this 'blog I consider what such developments portend for curriculum design and, in fact, the basic content of any CS program.
So: What if I was right?
last 'blog pondered the question:
Why has there been an apparent resurgence in multi-paradigm design?
I in fact am rather indifferent, for the sake of this article,
about whether multi-paradigm design (MPD) is the right answer.
Let me posit that the recent emergence of
practical application of
MPD, the fact that it piqued the interest of two
respected industry authorities (Trygve Reenskaug and, allegedly,
Scott Meyers), and the fact that Vrije Universiteit Brussel is
considering a major endeavor in this direction suggest that the
idea has power.
I am sure it is not the only idea of such breadth and power,
and I'd enjoy hearing your comments about other viable
alternatives that can serve as a broad integrative framework
for teaching design.
(I myself can posit
design theories, or the foundations
of the Design Movement of
Peter Naur et al., as equally good foundations, though it
is unlikely that you as readers are as conversant with
those ideas as with the foundations of MPD.
I'll revisit some of the problems with the more ambitious of
these ideas, such as patterns, below.)
But -- if I was right, back in 1993, in feeling that MPD provided
an integrative framework that solved many of the design problems
faced by OO programmers (who were really turning into generic
and generative programmers and a bunch of other things) at the
time -- where does that leave academia?
It leaves it in a position where it was teaching OO in 1993 while
there was emerging published material on an alternative -- material
coming out of an industry research lab.
(Think about it -- most great programming language advances
come emerged into the industry not from academia, but from
industry research labs.)
And in retrospect -- if I was right -- it means that academia stuck
with what it had in 1993, and was late in picking up a key idea.
Sadly, these days the main goal seems to be to crank
out good Java programmers: that is where the current
educational mindshare is.
Industry is about as bad off as academia save a few bright spots as the one described by Darren.
Industry is largely fad-driven, and most single paradigms have provided a most suitable place for fads to hang their hats.
What's worse, modern academia often must pacify industry in exchange for research funding or to be able to work with companies to place graduates in jobs.
Both academia and industry like things simple.
Both yearn to measure progress.
Progress is most easily measured along a single-dimensional ruler,
so any single-dimensional paradigm is a more comfortable measure either than no paradigm at all, or than any multidimensional analysis that requires thought and synthesis.
Systems engineering, a necessarily multidimensional discipline, has been a dieing art since the 1960s -- but like MPD it, too, seems to be
Maybe there is hope after all.
The Past, the Future, and the Eternal
Education is all about linking the past with the future.
Faced with students who bring their exposure to the
ideas of yesterday and today, the educator is faced with
preparing them for the future.
True, much of that preparation relates to rounding out
students' knowledge about the past and the present.
This includes the teaching of craft and technique.
Such teaching should be at the core of a BS or diplome degree.
At some level the student transitions from competence to mastery.
Being a master of a discipline means not only how to apply
existing craft and technique, but to have the insight
to choose from available techniques and the craft to combine
those techniques tastefully.
This, in my opinion, should be the goal of a college or university education.
Just as the apprenticeships of the Middle Ages produced master
carpenters, master stonemasons, and master jewelers, so today's
educational systems should produce master programmers.
If we stereotype that Middle Age culture a bit we find that,
no significant work was done by other than a master.
Yes, there was a place for day laborers who carried
the stones and hoisted beams, but the shape of the work
always owed to masters.
Craft is about bringing students up to the standards of yesteryear,
standards that yesteryear has proven useful and valuable.
Young practitioners of the crafts in the middle ages learned them from
their parents and carried the practices into the next generation, and
in fact this practice continues in carpentry, smith work, and other crafts
in many spots in the world.
Teaching Java is much like this.
Java is rooted in the object-oriented craft and attempts -- with a degree of
success or failure that I won't take up here -- to capture the essence of
My former employer North Central College feels they have improved their curriculum lately by going to a "Java curriculum."
Even the name is interesting. It is neither an "OO curriculum" that uses Java
nor a "programming curriculum" that emphasizes OO through Java.
It was set up to build the Java craft.
Teaching craft has limited benefits.
In addition to working in academia, I have also worked in industry.
More often than not I have found that I spend as much time helping
new employees fresh out of college unlearn things their professors
taught them as their professors may have spent putting those ideas
into their heads.
Encapsulation and information hiding are rarely as pure as the
academics would have it, and, no, Ellipse is not a derived class
of Sphere (a real example from a college text written by some
of my colleagues a few years back).
Further, most of the design grounding that students need comes from
the application domain and can't be taught effectively as
part of any general curriculum: as all politics are local, most
design is, too.
Most of the work in telecom software, EDA software, TV set-top
software, and most everything else, comes from design notions tied
to the domain -- not from Java.
So academia is caught between Scylla and Charibdis.
On one hand, no single craft is powerful enough to handle real-world problems.
On the other hand, teaching design theory in the abstract distances the
student from real-world problems.
What I think we need is something in between:
to give student skills in researching possible solutions,
choosing applicable solutions, and combining those solutions.
This is a form of critical analysis, and it is
a key to mastering the art of software development.
Teaching Critical Analysis
Of course, one still must learn craft on the road to mastery.
I believe the first step is to move beyond a given technology (a "Java-based
curriculum") to a curriculum grounded in concepts or ideals: to
choose one or some small number of conceptual frameworks that
cover software development from design through source coding
and testing, and build a core curriculum around that.
While focusing on a Java curriculum probably helps the student
in the craftwork of the coding phase of development,
I envision something that will help the student progress beyond that.
We need to teach students to do good analysis,
to take analysis results through design and implementation, and onward
to testing, not forgetting project management and documentation.
The student should be able to choose the right tools at
each step: ER diagrams, class modeling, Use Cases,
Prolog, C++, JUnit, and the like.
One can build such a curriculum around a focused theme,
such as MPD,
that lends consistency to the overall program.
Some curricula have tried to do that.
I think that Joe Bergin has done that in his work
at PACE using an object worldview.
I feel that time has shown us that the object worldview
is too myopic, not only in terms of industrial focus (how
does one accommodate things like generic and generative
programming?) but also in turns of conceptualization.
I feel an object worldview -- certainly as it is
popularly cast in the literature and taught in
academia -- forces one into a limited
mindset that cuts off rich possibilities in most
Though I may disagree with Joe about objects
being the right conceptual framework,
I agree with him about having such a broad
framework to ground the curriculum.
That is better than having a technology-based framework;
you can't predict what technology will bring thirteen years hence.
And it is certainly better than a buzzword-oriented
Buzzwords come and go.
CORBA, once an industry darling,
is now dead
after only a decade of real industry presence.
Eiffel, once a darling of academia, has now faded.
Objects, in my opinion, should now be shown the door -- certainly
in the temple of thought, and perhaps even in the shops of craft.
(We too easily forget that there was a period when even
objects were out of fashion, and yielded to another flash
in the pan called components.)
But I think we can do even better than that.
Rather than choosing a single design paradigm as the educational framework,
a university educator should choose a broader framework in which
multiple design and programming styles are fair game.
Tie the courses back to this framework and focus.
Now, it's a tall order both to shape such a framework and
to craft any kind of tangible focus for it.
I believe multi-paradigm design rises to that challenge,
and that's why I'm hopeful it is enjoying some resurgence.
Perhaps there's a way
There is one guy who I know succeeded with a closely
related set of ideas, and that's my friend
Tim Budd at
Oregon State University.
Tim is a prolific author who produces really great pedagogical stuff.
He's less interested in changing the industry with a big bang
than in planting many small, simple ideas that will grow into
a mass of influence in the hands of his students many years hence.
One of Tim's dearest interests is the language
Leda -- a multi-paradigm language that he created as a teaching tool.
The language serves as exactly the kind of focal
point I mentioned above.
I most interacted with Tim during my exploratory work in MPD
because we both use the term "multi-paradigm," albeit to mean
somewhat different things.
To Tim, "paradigm" implies computational model
whereas to me it constitutes a (structural) worldview.
The two ideas are of course not unrelated and someday,
some good researcher should try to unify them.
I guess I couldn't resist the temptation to include that header in this article. What do I mean by it?
Too many CS curricula focus on a single, commercially popular paradigm. They may offer a token course or two on a competing paradigm through a course on Lisp or a couple of lectures on Prolog. Such an approach does little to arm the student with the intellectual tools of design. At best, it exposes the student to one more syntax and one more set of semantics. Those two together are a far cry from understanding the trade-offs of design whose scope is broader than any single paradigm.
Part of the problem is that paradigms are overly subject to fashion. If we are to transcend fashion and arm the student with the tools they will need several years hence, we can't focus on paradigm. I think we can focus on three other things instead: rules for choosing paradigms, rules for combining paradigms, and perhaps some forward-looking work into new paradigms.
In a response to a follow-up post on my previous 'blog I noted that I sometimes use the term meta-design for the strategies behind MPD. MPD goes to the foundations of human perception (at least as we understand them in a Western framework) as a basis for choosing paradigms. It is a remarkably simple model based on the building blocks the mind uses to generalize or categorize. These small concepts, combined with simple rules, become the tools for choosing a paradigm.
We need to be teaching students this level of conceptual thinking. They should think not only about their programming languages as tools that can express these small number of concepts, but should be taught analysis as a way to find these concepts in their business world. Heaven help a world that goes looking for objects through an activity called "object-oriented analysis." In spite of the fact that my alma mater gave marching orders to teach OOA, I never taught it with a straight face. As usually taught it is just silly. We desperately need something broader.
A Kuhnian purist would argue that paradigms are mutually exclusive, but history suggests otherwise. As the world moved from steam locomotives to diesel it needed engineers who understood both and who could effectively argue the superiority of one over the other. Such objective arguments are almost completely absent from contemporary CS education, and I think the paradigm-centric view of education is largely at fault for this.
Even if Kuhnian paradigms are mutually exclusive, few CS paradigms are true Kuhnian paradigms. Thoughtful people like Peter Wegner and Larry Constantine have both noticed that the object paradigm is just a combined rehash of established ideas. Maybe Von Neumann computation is a paradigm. And maybe there are paradigms beyond the Von Neumann model. The so-called rule-based paradigm is always reduced to Von Neumanisms when anyone describes it within the field of computation; the same is true for the functional paradigm (a la pure Lisp). And databases are not so much a computing paradigm as a data organization paradigm. So the "Kuhn purism" argument against multiple paradigms doesn't hold water.
We desperately must learn to mix paradigms. We must teach students to choose the right tools for the right job so that we can support transitions across technological discontinuities in software, just as the transportation industry needed to migrate from steam to diesel power. At a more base level, we need to master multiple paradigms to be able to integrate systems from the mass of legacy software in the world today. No large enterprise can afford to re-design from scratch any more, and we need to learn how to navigate the waters of large-scale software integration in a sane way. Today, we hobble into this territory with techniques that can hardly be called engineering let alone science. I know we can do better in practice. Educational institutions should be ashamed that they are not rising to the challenge, but rather are perpetuating the problem. There are a couple of people out there like Tim Budd who are leading the charge into sanity. If you're an educator, consider joining them.
The Next Paradigms
I would be naive to suggest that we have heard the last word on paradigms for software design. It is tempting to make such a claim given that we have repeatedly revisited the same ideas for fifty years. I can think of only one new programming language idea in 45 years and of no new ideas in 40 years. However, we must have hope, or at least curiosity, that there is unplowed turf out there.
In fact, patterns offered hope of a new paradigm of design that might have had a chance in software. Patterns are indeed a new paradigm. Grabow's biography of Christopher Alexander is in fact a Kuhnian analysis of why patterns constitute a paradigm shift from existing design techniques. Software patterns as originally envisioned by the Hillside founders can be reconciled with object-oriented design only in the sense that relativistic physics can be reconciled with Newtonian physics. Object design, like most of the concepts within multi-paradigm design, can be covered by classical classification techniques, whereas patterns require that one break out of pure classification. However, the popularization of patterns by pedagogical academics (such as Johnson at the University of Illinois) have picked up patterns only within the framework of the object paradigm, losing the paradigm shift. Academia followed Piaget's model of learning, describing the new concept of patterns in terms of the known concept of objects. It is like teaching relativistic physics in a Newtonian framework.
One must wink at Piaget across a paradigm shift, and neither contemporary academia nor contemporary industrial practice has done that. I have little hope that it is possible for academia to do this, which is why I believe it will be difficult for any significantly new idea to come into the world through academia. Academia is perhaps the most conservative institution in the world. For example, instead of taking patterns to the level of generality they deserve, academic treatment of patterns has framed them in a way that is far less general even than object-oriented design.
To me, this suggests that the true discontinuities in practice will never come from academia. Perhaps industry is the one hope for change.
Historically, most programming language innovations have come not out of academia but out of industry. However, if one accepts the premise that these "innovations" really aren't that new -- a fact I bemoaned above -- then maybe these new paradigms will indeed come from the research labs. They may even come from other fields of study such as mathematics or philosophy.
Even if these new ideas do emerge from academia, academia should not factor them into their curricula.
Curriculum items should be based on proven principles.
The pattern experience teaches us that even academia has
difficulty embracing new modes of thought.
Given this, the best thing that academia can do is to help
its clients learn to understand, master, and integrate
the proven paradigms of today.
There is nothing in multi-paradigm design that isn't proven or obvious from first principles.
That's clear today from Darren's work at Sungard.
I also feel that the same was true in 1993.
Academia could indeed have taken up the banner then.
There is no use crying over spilt milk, but we should be introspective today about the rough gems we have today that will be tomorrow's diamonds.
Again, Tim Budd has fresh thoughts in this area these days, and
we ignore him at our peril.
Your parts 1 and 2 this morning. I completely agree with part 2, although I wondered a bit about part 1 where you seem to be saying that all great langauges are converging on C++.
One problem that I see is that we in the educational profession really don't know how to teach thought, if by that you mean higher level abstract thinking. We do it ourselves. Our best students end up doing it. But a number of our university students, at least in the first two or three years, are still stuck at a level where they respond only to very concrete concepts. It's a Piagetian thing. So we end up teaching what the students are prepared to learn, which is a very concrete skill (i.e. Java programming, PHP, web design, whatever), somehow hoping that they will quickly learn to rise above this level and begin to appreciate the more subtle and nuanced abstract concepts that are behind the concrete skills. Sometimes it works. A lot of the time, it doesn't.
As I mentioned in an earlier e-mail, at the moment I'm a great fan of Python as a first programming language. Python is less paradigm biased than most programming languages. You can think and work in a functional fashion if you want (particularly list comprehensions are a wonderful feature). You can think and work in an object-oriented fashion if you want. Or you can think and work in an imparative fashion. Students, beginning students, need to be exposed to all these different ways of thinking about problem solving, so that they know that there is more than one way to think about software DESIGN (and not just coding) and so that they do not end up using one tool for all problems.
If you know my history, you will know that anytime I am interested in something new it expresses itself as a book. If you are curious to see a manuscript of my Python as a first language book drop me a note.
I wonder whether we are going to see any more of these grand shifts. They are nice, they are something to get excited about, but I think that a fundamental shift has already occurred. Most people out there are working in the context of existing systems. They don't think about methodology. If they need something, they google it, copy it, and go on. They spend more time tweaking and stringing together scripts than they do writing code. They think about "good" in relative rather than absolute terms. The catch-phrase for it is "post-modern programming." I don't think it's anything new, but it is, rather, a recognition of what people do and don't talk about much.
Wow! So "post-modern programming" is now a buzzword?
I'm certainly a died-in-the-wool post-modernist. I think post-modern has its roots in the design movement of the 1970s and in works such as "Design after Modernism: Beyond the Object," edited by John Thackara (the same one I mention early on in this posting), and a small raft of other publications in the same era. Post-modernism is characterized by an attachment for concepts over objects, which says something about the death of pure object-oriented thinking. Multi-paradigm design is a step into this space, and patterns are clearly in this space (though Alexander vehemently denies being a post-modernist. There are indeed some postmodernists who deserve to be treated with a grain of salt, particularly the extreme deconstructionists -- for a good laugh, see the classic post at http://www.info.ucl.ac.be/~pvr/decon.html).
So, where have you heard the term bantered about? You really have me curious -- in a nice sort of way.
> Wow! So "post-modern programming" is now a buzzword? > > I'm certainly a died-in-the-wool post-modernist. I think > post-modern has its roots in the design movement of the > 1970s and in works such as "Design after Modernism: Beyond > the Object," edited by John Thackara (the same one I > mention early on in this posting), and a small raft of > other publications in the same era. Post-modernism is > characterized by an attachment for concepts over objects, > which says something about the death of pure > object-oriented thinking. Multi-paradigm design is a step > into this space, and patterns are clearly in this space > (though Alexander vehemently denies being a > post-modernist. There are indeed some postmodernists who > deserve to be treated with a grain of salt, particularly > the extreme deconstructionists -- for a good laugh, see > the classic post at > http://www.info.ucl.ac.be/~pvr/decon.html). > > So, where have you heard the term bantered about? You > really have me curious -- in a nice sort of way.
It's funny in that "ha ha only serious" way. I remember reading it and thinking "what now?" as if there had to a plan (and of course there isn't), but the key takeaway for me is that we just don't pay as much attention to what people actually do as we should.
James Noble and several other authors have a very interesting paper in for OOPSLA this year which is about mining an extremely large corpus of Java programs to learn more about what really happens as opposed to what we would like people to do. The paper is specifically about whether aspects of software are scale-free in the wild, but at a more general level, I think we need more of that.. more emphasis on discovering what people really do as opposed to what we'd like them to do.
I think that Brian Foote's 'Big Ball of Mud' paper years ago was a doorway that people were scared to enter.
> I think that Brian Foote's 'Big Ball of Mud' paper years > ago was a doorway that people were scared to enter.
Embracing trash? I gotta love it. I've never understood why this attitude of crass realism is not more common among programmers ( I've noticed You make almost an exception for mainly being interested in dealing with legacy instead of promoting platonist fantasies of the good and beautifull and the modernist idea of eternal progress ). The perfect complementary literature to BBoM concerning architecture are probably the writings of Rem Koolhaas. Checkout 'Junkspace':
I must say that I do agree with many points you made in this blog entry.
Something that struck me: I'm very happy to have graduated from a university without a 'Java curriculum', but this makes being confronted with the Java-zealotry in many other research institutions somewhat depressing.
I suppose that in this case, ignorance would be bliss.
Am a practising developer of about 20 years experience. I build soft real-time, event-driven distributed software systems that are used in marine terminal operations. My software is running in major terminals up and down the West Coast and several locations on other major coastlines.
My current technique of devising such software is effective, but I do mix paradigms. Here's an article, though, that sums up what I've determined works very well (and also sites what didn't work well for me):
I completely agree that software developers should be taught critical analysis. However, we have to assume that the foundations of "critical analysis" are laid in high school. To give student skills in researching possible solutions, choosing applicable solutions, and combining those solutions is a skill that could be useful in any discipline. Being a master of a discipline then could mean to do in-depth "critical analysis" in a certain discipline with field specific problems and tools. Here again, to teach critical analysis at an an architecture or design level may be more effective with students who have a few years of work experience in the field. You say that most design is "local". Researching possible solutions and choosing applicable ones needs the ability to take the "local" factors into account. By "local", I mean the domain specific factors as well as organizational factors -- the culture and structure of the organization. To teach this in a course, would mean that the course include case studies and problems that help the student work through these "local factors" as well.
Thanks for the insights. I'd go further and say that the foundations of critical analysis have roots much earlier in life than in high school. The very structure of early pedagogy should include a heavy dose of exploration rather than teaching à la "The Nürnberg Funnel" -- just pouring knowledge into the head of the student.
My stint as a professor at North Central College was really disappointing in this regard. Early programming courses limited students to use those language features that had been presented in class (I think this was honestly because the instructors were ignorant of other features), were given strict guidelines on things that should have received less emphasis (e.g., sticking to the teacher's indentation and commenting style -- some professors literally deducted points for creative commenting style), and so forth. I finally had to create a kind of Dead Programmers' Society that met pseudo-secretly in the evenings to discuss forbidden topics like Smalltalk and Python.
Maybe now that they have a Java curriculum they need a Dead Programmers' Society for C++ as well.
But it starts earlier than in college. American education is overly concerned with facts. Here in Denmark there is a stronger tradition of teaching exploration and challenge. Sadly, that, too, is changing, giving way to the tidal wave of American educational standards, the treaty of Bologna, and other balogna and baloney. It's too bad: that free spirit has given Denmark one of the strongest economies in the world and one of the strongest software industries in the world.
Hey, Urvashi -- where are you at these days? I'm still at my old Email address and you can find my contact info on my web page on RCN.