The Artima Developer Community
Sponsored Link

Weblogs Forum
Signs of the Next Paradigm Shift: Part II

10 replies on 1 page. Most recent reply: Jan 10, 2007 10:37 PM by Marco Dorantes

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 10 replies on 1 page
James O. Coplien

Posts: 40
Nickname: cope
Registered: May, 2003

Signs of the Next Paradigm Shift: Part II (View in Weblogs)
Posted: Aug 24, 2006 4:56 AM
Reply to this message Reply
Summary
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.
Advertisement
So: What if I was right?

My 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 Alexander's design theories, or the foundations of the Design Movement of Nigel Cross, John Thackara, 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 seeing resurgence. 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, do-it-yourself-ers aside, 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.

Teaching Craft

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 object-ness. 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 programming languages.

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 pedagogical framework. 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.

Beyond Paradigm

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.

Choosing 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.

Mixing Paradigms

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.


Timothy Budd

Posts: 1
Nickname: timbudd
Registered: Aug, 2006

Re: Signs of the Next Paradigm Shift: Part II Posted: Aug 24, 2006 1:16 PM
Reply to this message Reply
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.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Signs of the Next Paradigm Shift: Part II Posted: Aug 27, 2006 8:08 AM
Reply to this message Reply
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.

James O. Coplien

Posts: 40
Nickname: cope
Registered: May, 2003

Re: Signs of the Next Paradigm Shift: Part II Posted: Aug 28, 2006 4:00 AM
Reply to this message Reply
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.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Signs of the Next Paradigm Shift: Part II Posted: Aug 28, 2006 9:53 AM
Reply to this message Reply
> 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.

Well, you're just in time, then. The first conference on Post-Modern Programming is going to be held in London in November ( http://www.bcs-spa.org/pomopro.html ). You should take a look at James Noble and Robert Biddle's first paper on the subject: http://www.mcs.vuw.ac.nz/comp/Publications/CS-TR-02-9.abs.html

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.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Signs of the Next Paradigm Shift: Part II Posted: Aug 30, 2006 3:39 PM
Reply to this message Reply
> 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':

http://www.btgjapan.org/catalysts/rem.html

Johan Fabry

Posts: 1
Nickname: jfabry
Registered: Sep, 2006

Re: Signs of the Next Paradigm Shift: Part II Posted: Sep 4, 2006 9:16 AM
Reply to this message Reply
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.

Roger Voss

Posts: 27
Nickname: rogerv
Registered: Aug, 2005

data-driven communication vs behavior-driven communication Posted: Sep 4, 2006 1:11 PM
Reply to this message Reply
James,

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):

Building Effective Enterprise Distributed Software Systems:
data-driven communication vs behavior-driven communication

http://humbleblogger.blogspot.com/2006/08/building-effective-enterprise.html

Urvashi Kaul

Posts: 2
Nickname: urvashi
Registered: Mar, 2006

Re: Signs of the Next Paradigm Shift: Part II Posted: Sep 13, 2006 2:11 PM
Reply to this message Reply
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.

James O. Coplien

Posts: 40
Nickname: cope
Registered: May, 2003

Re: Signs of the Next Paradigm Shift: Part II Posted: Oct 23, 2006 5:23 AM
Reply to this message Reply
Hi, Urvashi,

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.

Marco Dorantes

Posts: 11
Nickname: marcodoran
Registered: Feb, 2003

Re: Signs of the Next Paradigm Shift: Part II Posted: Jan 10, 2007 10:37 PM
Reply to this message Reply
Wonderful post. I am also glad to see more about multi-paradigm design.
I bought the book in 2000, and have tried to put some of your ideas into practice.
From time to time, I have posted about it:
http://blogs.msdn.com/marcod/search.aspx?q=multi-paradigm&p=1

Outstanding work, congratulations.

Flat View: This topic has 10 replies on 1 page
Topic: Signs of the Next Paradigm Shift: Part II Previous Topic   Next Topic Topic: boost::any meet ootl::any_ptr


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us