TITLE: Dispatches from the Programmer Liberation Front AUTHOR: Eugene Wallingford DATE: December 27, 2004 11:19 AM DESC: Jonathan Edwards's new blog is a revolutionary take on an evolutionary phenomenon -- a trend toward simplicity in programming. What does the trend toward more powerful tools and less powerful languages mean for software developers? For students and teachers of programming? ----- BODY: Owen Astrachan pointed me in the direction of Jonathan Edward's new blog. I first encountered Edwards's work at OOPSLA 2004, where he gave a talk in the Onward! track on his example-driven programming tool.

In his initial blog entries, Edwards introduces readers to the programming revolution in which he would like to participate, away from more powerful and more elegant languages and toward a programming for the Everyman, where we build tools and models that fit the way the real programmer's mind works. His Onward! talk demoed a initial attempt at a tool of the sort, in which the programmer gives examples of the desired computation and the examples become the program. Edwards's current position stands in stark contrast to his earlier views as a more traditional researcher in programming languages. As many of us are coming to see, though, "programming is about learning to work effectively in the face of overwhelming complexity" than it is about ever more clever programming languages and compiler tricks. When it comes to taming the complexity inherent in large software, "simplicity, flexibility, and usability are more effective than cleverness and elegance." The recent trend toward agile development methodologies and programming support tools such as JUnit and Eclipse also draw their inspiration from a desire for simpler and more flexible programs. Most programmers -- and for Edwards, this includes even the brightest -- don't work very well with abstractions. We have to spend a lot of brain power managing the models we have of our software, models that range from execution on a standard von Neumann architecture up to the most abstract designs our languages will allow. Agile methods such as XP aim to keep programmers' minds on the concrete embodiment of a program, with a focus on building supple code that adapts to changes in our understanding of the problem as we code. Edwards even uses one of Kent Beck's old metaphors that is now fundamental to the agile mindset: Listen carefully to what our code is telling us. But agile methods don't go quite as far as Edwards seems to encourage. They don't preclude the use of abstract language mechanisms such as closures or higher-order procedures, or the use of a language such as Haskell, with its "excessive mathematical abstraction". I can certainly use agile methods when programming in Lisp or Smalltalk or even Haskell, and in those languages closures and higher-order procedures and type inference would be natural linguistic constructs to use. I don't think that Edwards is saying such things are in and of themselves bad, but only that they are a symptom of a mindset prone to drowning programmers in the sort of abstractions that distract them from what they really need in order to address complexity. Abstraction is a siren to programmers, especially to us academic types, and one that is ultimately ill-suited as a universal tool for tackling complexity. Richard Gabriel told us that years ago in Patterns of Software (pdf). I am sympathetic to Edwards's goals and rationale. And, while I may well be the sort of person he could recruit into the revolution, I'm still in the midst of my own evolution from language maven to tool maven. Oliver Steele coined those terms, as near as a I can tell, in his article The IDE Divide. Like many academics, I've always been prone to learn yet another cool language rather than "go deep" with a tool like emacs or Eclipse. But then it's been a long time since slogging code was my full-time job, when using a relatively fixed base of language to construct a large body of software was my primary concern. I still love to learn a Scheme or a Haskell or a Ruby or a Groovy (or maybe Steele's own Laszlo) to see what new elegant ideas I can find there. Usually I then look to see how those ideas can inform my programming in the language where I do most of my work, these days Java, or in the courses where I do most of my work. I don't know where I'll ultimately end up on the continuum between language and tool mavens, though I think the shift I've been undergoing for the last few years has taken me to an interesting place and I don't think I'm done yet. A year spent in the trenches might have a big effect on me. As I read Edwards's stuff, and re-read Steele's, a few other thoughts struck me:

In his piece on the future of programming, Edwards says,
I retain a romantic belief in the potential of scientific revolution ... that there is a "Calculus of Programming" waiting to be discovered, which will ... revolutionize the way we program....
(The analogy is to the invention of the calculus, which revolutionized the discipline of physics.) I share this romantic view, though my thoughts have been with the idea of a pattern language of programs. This is a different sort of 'language' than Edwards means when he speaks of a calculus of programs, but both types of language would provide a new vocabulary for talking about -- and building -- software.
Later in the same piece, Edwards says,
Copy & paste is ubiquitous, despite universal condemnation. ... I propose to decriminalize copy & paste, and even to elevate it into the central mechanism of programming.
Contrary to standard pedagogy, I tell my students that it's okay to copy and paste. Indeed, I encourage it -- so long as they take the time after "making it work" to make it right. This means refactoring to eliminate duplication, among other things. Some students find this to be heresy, or nearly so, which speaks to how well some of their previous programming instructors have drilled this wonderful little practice out of them. Others take to the notion quite nicely but, under the time pressures that school creates for them and that their own programming practices exacerbate, have a hard time devoting sufficient energy to the refactoring part of the process. The result is just what makes copy and paste so dangerous: a big ball of mud with all sorts of duplicated code. Certainly, copy and paste is a central mechanism of doing the simplest thing that could possibly work. The agile methods generally suggest that we then look for ways to eliminate duplication. Perhaps Edwards would suggest that we look for ways to leave the new code as our next example.
At the end of the same piece, Edwards proposes an idea I've never seen before: the establishment of "something like a teaching hospital" in which to develop this new way of programming. What a marvelous analogy! Back when I was a freshman architecture major, I saw more advanced students go out on charrette. This exercise had the class go on site, say, a road trip to a small town, to work as a group to design a solution to a problem facing the folks there, say, a new public activity center, under the supervision of their instructors, who were themselves licensed architects. Charrette was a way for students to gain experience working on a real problem for real clients, who might then use the solution in lieu of paying a professional firm for a solution that wasn't likely to be a whole lot better. Software engineering courses often play a similar role in undergraduate computer science programs. But they usually miss out on a couple of features of a charrette, not the least of which is the context provided by going to the client site and immersing the team in the problem. A software institute that worked like a teaching hospital could provide a more authentic experience for students and researchers exploring new ways to build software. Clients would come to the institute, rather than instructors drumming up projects that are often created (or simplified) for students. Clients would pay for the software and use it, meaning that the product would actually have to work and be usable by real people. Students would work with researchers and teachers -- who should be the same people! -- in a model more like apprenticeship than anything our typical courses can offer. The Software Engineering Institute at Carnegie Mellon may have some programs that work like this, but it's an idea that is broader than the SEI's view of software engineering, one that could put our CS programs in much closer touch with the world of software than many are right now.

There seems to be a wealth of revolutionary projects swirling in the computer science world these days: test-driven development, agile software methods, Croquet and eToys .... That's not all that unusual, but perhaps unique to our time is the confluence of so many of these movements in the notion of simplicity, of pulling back from abstraction toward the more concrete expression of computational ideas. This more general trend is perhaps a clue for us all, and especially for educators. One irony of this "back to simplicity" trend is that it is predicated on increasingly complex tools such as Eclipse and Croquet, tools that manage complexity for us so that we can focus our limited powers on the things that matter most to us. -----