Optimizing Metaprogramming

    At a discussion of free software’s future at the recent libreplanet 2010 conference, Nick Montfort shares an important observation about the need to address the oligopoly of the advanced programmer, providing alternatives and additional points of entry into advanced programming by the broader technologically engaged world. This is a poignant reminder that the halcyon days of free software were dialectically powered by two ethical recriminations against the commercial software enterprise. One was the outrage of advocates like Stallman asserting that software, despite the significant cost of developing it, should *always* and unconditionally remain free — that is, not merely “free as in freedom”, as he would often assert, but also cost-free. The other was a vexing sense, true in many cases but not universally so, that the profits realized by such corporations would be utilized for building not better software, but rather monopolies.

    While the momentum of free software — no longer a fringe element, but rather a staple of Internet and applications development — has grown significantly, it seems to have shed its archaic character as a form of political resistance, a fact reflected by the softening of its appellation when the offhandedly referenced “free software movement” neutralized into “user-contributed community”. But why did this depolicitization take place, even as the quality and amount of worldwide free software production increased? In my thinking, it derives from two reasons. One is psychological, the other institutional.

    At the individual level, the greater impulse fueling the software engineering mindset is to create, not to critique. It may not be far-fetched to think of programmers as engineering artists, problem-solvers who want to touch the world with a solution whose impact is ratified through its embrace within the larger world. The economic structure of commercial software is, in this perspective, almost irrelevant to the creative drive and ineluctable satisfaction that software design provides. This is a psychological rationale for the dissolution of a movement amidst the rise of its product. But this cannot suffice to explain how the change in ethical polemics surrounding free software in the decade following 1980 contrasts with that in the decade following 2000. Beyond this reason for continuing an upward slant of software production, there is an institutional one – namely, the adoption of free software *by* the commercial software industry, not for profit share but for market share. What used to be proprietary, like CompuServe’s patent of the GIF algorithm, became “owned but shared” in a manner that was to the end user indistinguishable from Stallman’s ethically pure free software. Microsoft’s infamous development of Internet Explorer against Netscape is one case study of this kind. Sun Microsystems’ development and release of Java is another. Earlier on, XEROX PARC’s creation of Smalltalk heralded not merely a program, but a whole object-oriented discipline. We know, too, that OpenOffice, while entirely free and open-source, was not brought to the world by a small group of programmers without portfolio, but rather by Sun Microsystems, after an acquisition and several other way-points. There are significant examples of software developed through similar etiologies in every user’s computer. Stallman’s argument made sense in 1990 when it seemed that free software would be fighting against paid software, defined as emblems of a world that was singularly fee-charging and imperial. But what of that fight when the user-contributed software community has not only grown wholly outside those (important, though antiquated) ideological vituperations but has, as with FaceBook, YouTube, Twitter, the blogosphere, and other constituents of social media, given birth to the next version of the Internet? I thus agree with Nick that better programmability, not freer use, is the best and most inclusive future.

    There are few places to go more crucial to the future of a medium than through evolutionarily close dialogue between modes of construction and the end content itself. We passionately want that; what do users want? Programming can be simplified, yet is not an Everyman pursuit any more than writing literature can naturally be. The best work in either field is always realized by a creative elite, not by the regular person (though we do romanticize this somewhat). In the late 1980’s , when HyperCard emerged, it represented the first serious attempt in history to provide a simple but powerful system for building interactive software to the masses. It was not alone, as mentioned, SmallTalk, and independently, LOGO, Pascal, and MacLISP became available alongside BASIC – all programming environments that bestowed extraordinary power on users with modest programming ability. In the simple-system route, many languages, to include Perl, Python, and PHP, have emerged, each seemingly simpler to use than its predecessor. The principal strategy for such ease of programming mirrored what was found to be true in the cognitive behavior of advanced learners. It involved what Douglas Hofstadter in del, Escher, Bach called chunking – encapsulating large amounts of small processing ability in higher-level abstractions that could be represented as singular, rather than compound, entities. Despite realizing very sophisticated modular functionality of this sort, none of these systems managed to remain with the “typical” non-programmer, as Bill Atkinson had first desired in developing of HyperCard.

    In the 1980’s, when I was a graduate student at the Harvard Graduate School of Education a few of us were researching ways through which this potential “free programming movement”, as it were, could be extended to teachers – the ideal non-programmers – so that they could design learning interventions for their own students. Judah Schwartz, the fearless leader of this initiative, designed a course called Educational Software Design Lab in which principles of Piagetian constructivism and its empirical sibling, constructionism, would incrementally inform the design of interactive software. When some years later I co-taught the course, it comprised not only teachers but museum educators, historians, statisticians, an Army captain studying at the Kennedy School of Government, and an archaeologist. In less than five years, these fields had simultaneously come to embrace the idea that a content matter expert could create software whose use would support existing pedagogy. During this time, Seymour Papert’s Epistemology and Learning group at the MIT Media Lab was taking this idea to a logical extreme; inspired by Paolo Friere’s thinking, Papert wished for educational software to “destroy” the school, as he occasionally emphasized. The idea of free programming was becoming an object of curious promise to non-programmers and a polemical lever for Papert, Stallman, and others who were counter-institutionally motivated.

    As with the polemics of the free software movement, whose output was co-opted dually by the commercial enterprise at one ideological extreme and bottom up social experiments at the other, educational software, starting with HyperCard (which cost $50 at first but which later came bundled with all new Apple computers), was essentially never a phenomenon that inspired the creation of a critical mass, a programmer in every home. What made sense to build in the 1980’s and 90’s was already commercially available in the subsequent decade. To write a novel, it no longer became necessary to create a program to provide the functions of a text editor. Perhaps more importantly, the creation of a medium requires a very different kind of craftsmanship than that of its content. But the line between both has been rendered less intractable as software has become more intuitive, intelligent, and inferentially informed. One remembers this same period – the late 1980’s – when during his years away from Apple, Steve Jobs founded NeXT, whose NeXTSTEP operating system featured an array of innovations like object oriented page rendering from web pages, or display postscript, to patents, from the electrical connector all desktop computers use today

    NeXT cable plug

    NeXT cable plug

    (US patent D312,240), the canonical design for desktop printers (US patent D319,461)

    NeXT printer

    NeXT printer

    all by Hartmut Esslinger, insufficiently celebrated design transformer of computer culture from the realm of industrial klunk  to that of the elegant and understated.

    In this connection, however, NeXT’s chief innovation was the storage of software code that was precompiled – Hofstadter’s chunks – and which could be manipulated on a graphical interface by iconic means. Chaining and connecting the objects was the functional equivalent of programming; at the technical level it was linking the compiled objects together to form a new autonomous program.

    NeXTSTEP workspace manager

    NeXTSTEP workspace manager

    The aims of education and simplifying programming have always been close; Alan Kay’s recent NSF grant for the Viewpoints Research Institute, for example, has both aims at the core of the mission. As with Jobs’s implementation of link-based programming in NeXTSTEP, Kay’s EToys and Squeakland/Squeak environments integrate the creation (painting) an object on screen with the menu-based scripting commands that make it functional.

    EToys object-functional interface

    EToys object-functional interface

    It is difficult somehow to imagine a more seamless or uncomplicated path to the creation of programmed entities. Yet as I have mentioned, and as history shows, this has not proved to be the hoped-for method of popular embrace; to lay users it may seem too abstruse and thus not sufficiently simple; to programmers it may appear too rudimentary and thus not sufficiently powerful. Needless to say, Kay’s work is built on the same object-oriented architecture that powered Smalltalk, another environment that also passed on, perhaps for these reasons, perhaps for others. Software design, like other design, has in every other context proved to be most usable when it employs familiar metaphors and tropes. Can it be that this kind of acontextual design interface has failed because it is too free? Perhaps a theater of constraints provides the better road to optimal design, less as a polemical movement than as an inclusive philosophy.