Slashdot Mirror

Section 2.1 of Richard Gabriel's Lisp: Good News, Bad News, How to Win Big is called "Worse is Better." Those with shorter attention spans may enjoy his later presentation Models of Software Acceptance: How Winners Win, which explicitly mentions VHS vs. Beta.

P.S. Beta was much better than VHS at keeping vertical lines straight, especially over multiple generations.

Section 2.1 of Richard Gabriel's Lisp: Good News, Bad News, How to Win Big is called "Worse is Better." Those with shorter attention spans may enjoy his later presentation Models of Software Acceptance: How Winners Win, which explicitly mentions VHS vs. Beta.

P.S. Beta was much better than VHS at keeping vertical lines straight, especially over multiple generations.

http://www.dreamsongs.com/ObjectsHaveFailedNarra ti ve.html

Everybody's talking about Bruce for fifteen minutes, so his mission is accomplished. Presumably his ego is stroked, recognition and purchases of his books will go up marginally, and he's more likely to be invited next time.

Richard Gabriel did a better job of describing the futility of doing software these days:

Over the years I've despaired that the ways we've created to build software matches less and less well the ways that people work effectively. More so, I've grown saddened that we're not building the range of software that we could be, that the full expanse of what computing could do--to enhance human life, to foster our creativity and mental and physical comfort, to liberate us from isolation from knowledge, art, literature, and human contact--is left out of our vision. It seems that high-octane capitalism has acted like an acid or a high heat to curdle and coagulate our ways of building software into islands that limit us.

But like survivors, we've managed to make these islands homes. We've found the succulent but bitter fruit that can sustain us, the small encrusted or overfurred creatures we can eat to survive, the slow-moving and muddy streams from which we drink against the urge to spit it out. Being survivors, we can make do with little. But how little like life is such an existence.

Sounds like we're rehashing what Richard Gabriel stated back in the early 90's: Bad software released early seems to outlive software that is engineered completely before it is released (paraphrased). You can take a look at it here for the complete argument.

Interesting to see how Unix was once viewed in the light M$ is today.

This is not a suggestion I have heard yet (except indirectly in some people's mention of the FreeBSD maintenance system), and I expect it to be an unpopular one, but perhaps those in charge should be thinking not about "How do we decentralize or otherwise modify the process so that we can maintain the current rate of development?", but rather, "Would it be wise to reduce the current rate of development?" Such a reduction would (some may disagree) result in an overall increase in the quality of code getting into the kernel. And arguably, a modicum of new development work would suffice to keep Linux running on new, common hardware; is it really necessary to support every new ethernet or graphics chipset that comes out? This would at least allow for a favorable marketing argument about the "stability" (not necessarily synonymous with "reliability") of Linux. There is perhaps a connection with the "Worse is Better" philosophy which has worked well for Unix in the past. It would also free up developers to work on other aspects of the overall Linux system, such as applications, desktop issues, perhaps ease of installation, and so on. Maybe I'm rambling, or off base, but this seems reasonable to consider.

Sounds like Linus is in accord with Dick Gabriel's "Worse is Better" essay, or rather the "New Jersey" school of design. The "worse" package gets out quickly to a place where "natural [user/hacker] selection" can work on it.

There was a bit of a superior attitude from some of the academics, who feel that languages like Perl and Python reinvent the wheel and neglect the body of academic research by coming up with suboptimal solutions to PL problems that have long since been "solved" in the PL literature. Maybe "frustrated" is a better word than "superior." While I can totally appreciate their point of view, I found myself cringing in embarrassment once or twice when a harangue by one of the academics went a little overboard. There has already been one post on the LL1 mailing list that I feel crossed the line.

The discussion came to a bit of head during the (very interesting) "Worse Is Better" panel (based loosely on the writings of Richard Gabriel), which centered on the question of why the most popular languages aren't the "best" ones.

Like I said, though, it was mostly very congenial. Ultimately, I think each camp took something away from the encounter: both new-found implementation techniques, and a greater knowledge of and interest in the other community. There are some practical issues that the Perl/Python guys have to deal with (e.g., interfacing with legacy languages like C) that aren't really addressed by academics, and I think it was great that these issues were brought to light.

The LL1 website, if anyone is interested, is ll1.mit.edu.

Richard P. Gabriel and Ron Goldman argue that software needs to become more organic, more forgiving, less brittle, less obsessed with performance, and more people-centered. One example they give is of small agents cleaning up objects if their class definitions have changed since their creation. This is possible using the Common Lisp Object System's (CLOS's) Meta-Object Protocol (MOP), which is a run-time MOP, but not, say, with Christian Queinnec's Meroon object system for Scheme, which can be described as having a compile-time MOP. On the other hand, Meroon's object system, in my experience, has much higher performance than CLOS.

Where do you stand on the flexibility-performance divide?

Charles Connell's essay presents appealing ideas; it'd be nice to think software could be "more aesthetic". However, the truth is that Worse Is Better -- as Richard P. Gabriel will often argue (and other times refute).

Exactly those things which make software "ugly" -- complexity, poor modularity, leaky interfaces, and sacrificing design and comments in the name of rapid deployment -- can also help make it more successful, commercially and socially, in the long run.

Exactly those things which make software "beautiful" -- such as Connell's qualities of "appropriate form", "minimality", "component singularity", "functional locality", "simplicity", and even "readability" -- can in fact make software fail, as "great programmers" spend a bunch of time making "elegant solutions" that never catch fire, because they lack the immediacy and approachability of more haphazard solutions.

While this idea may sound like an excuse to avoid doing up-front thought, it's actually a hard-earned lesson that what aesthetically appeals to good, well-intentioned programmers may in fact involve all the "wrong" tradeoffs.

Read all the stuff on this topic at Gabriel's Worse Is Better pages, then revisit Connell's aesthetics peice, and Connell may seem downright naive to you.

Charles Connell's essay presents appealing ideas; it'd be nice to think software could be "more aesthetic". However, the truth is that Worse Is Better -- as Richard P. Gabriel will often argue (and other times refute).

Exactly those things which make software "ugly" -- complexity, poor modularity, leaky interfaces, and sacrificing design and comments in the name of rapid deployment -- can also help make it more successful, commercially and socially, in the long run.

Exactly those things which make software "beautiful" -- such as Connell's qualities of "appropriate form", "minimality", "component singularity", "functional locality", "simplicity", and even "readability" -- can in fact make software fail, as "great programmers" spend a bunch of time making "elegant solutions" that never catch fire, because they lack the immediacy and approachability of more haphazard solutions.

While this idea may sound like an excuse to avoid doing up-front thought, it's actually a hard-earned lesson that what aesthetically appeals to good, well-intentioned programmers may in fact involve all the "wrong" tradeoffs.

Read all the stuff on this topic at Gabriel's Worse Is Better pages, then revisit Connell's aesthetics peice, and Connell may seem downright naive to you.

The real issue though is that of the gross abuse of over-extended analogies and metaphors from other fields to justify one's own strong-headed opinion. Comparing software design to home building or civil engineering as exemplified by Connell is typical of this type of wrong-headed fuzzy thinking.

Software design is software design. It is its own unique endeavor that may share all sorts of attributes with other activites but ultimatlely stands on its own. Software design has evolved into what it is now because that how it fits as a societal activity as determined by its practioners and product users. This means that software doesn't drive like a car, look like a house nor oink like a pig. And as Gabriel has pointed out, in the software field sometimes "worse is better"!

The cited article doesn't say anything profound. (I got particularly worried when he said, "global variables and GOTO statements ... may be exactly what the software needs to marry form with function," and when his example of beautiful software turned out to be a fragment of Visual Basic. "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." --said, tongue at most partly in cheek, by Edsger W. Dijkstra, in "How do we tell truths that might hurt?")

Richard P. Gabriel (whose essay on "Mob Programming" was recently discussed on Slashdot) has a far more profound take on the subject. He has a summary of Christopher Alexander's work on architecture and "The Quality Without A Name," and how it relates to software; you can read the PDF version on his Web site, or Google's cached text version.

Excerpts: "there are programs we can look at and about which we say, 'no way I'm maintaining that kluge' ... and there are other programs about which we can say, 'wow, who wrote this!'" He suggests how you can recognize software with The Quality: "every part of the code is transparently clear -- there are no sections that are obscure to gain effciency; everything about it seems familiar; I can imagine changing it, adding some functionality; I am not afraid of it, I will remember it." There are even suggestions, not how to make more beautiful software, but how to learn to do so.

Gabriel helped start the "patterns movement" in the object-oriented community. Aside from the Design Patterns book, patterns (and especially generative pattern languages) have yet to make a significant inpact on software development. Maybe someday, maybe not.

The cited article doesn't say anything profound. (I got particularly worried when he said, "global variables and GOTO statements ... may be exactly what the software needs to marry form with function," and when his example of beautiful software turned out to be a fragment of Visual Basic. "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." --said, tongue at most partly in cheek, by Edsger W. Dijkstra, in "How do we tell truths that might hurt?")

Richard P. Gabriel (whose essay on "Mob Programming" was recently discussed on Slashdot) has a far more profound take on the subject. He has a summary of Christopher Alexander's work on architecture and "The Quality Without A Name," and how it relates to software; you can read the PDF version on his Web site, or Google's cached text version.

Excerpts: "there are programs we can look at and about which we say, 'no way I'm maintaining that kluge' ... and there are other programs about which we can say, 'wow, who wrote this!'" He suggests how you can recognize software with The Quality: "every part of the code is transparently clear -- there are no sections that are obscure to gain effciency; everything about it seems familiar; I can imagine changing it, adding some functionality; I am not afraid of it, I will remember it." There are even suggestions, not how to make more beautiful software, but how to learn to do so.

Gabriel helped start the "patterns movement" in the object-oriented community. Aside from the Design Patterns book, patterns (and especially generative pattern languages) have yet to make a significant inpact on software development. Maybe someday, maybe not.

More disappointing is witnessing this same effect at work in the patterns community. Christopher Alexander's ideas of patterns has as its smallest part the pattern form--the concept of patterns really has to do with pattern languages and QWAN (the Quality Without a Name). It is not about con-struction tricks. It is about building artifacts not only suitable for human habitation, but artifacts that increase their human inhabitants' feeling of life and wholeness. Alexander is all about beauty and quality, not about how to stick things together cleverly.

Yet, the most popular form of software patterns is exemplified by those found in "Design Patterns," by Gamma, Helm, Johnson, and Vlissides, which contains little more than techniques for coding in C++ constructs found in other programming languages--for example, 16 of the 23 patterns represent constructs found in the Common Lisp language. There is no pattern language involved, and there is nothing about QWAN. Interest in patterns is coagulating around the so-called Gang of Four style, and it looks like things could get worse. In fact, I would say that patterns are alive and well as a form of documentation and a quest for clever solutions to common programming problems, and pattern languages, QWAN, and the quest for a better future are now on their way to the sewage treatment plant--the same place they went to in the world of architecture. Down with quality, up with clever hacks. Why worry about what makes a user interface beautiful and usable when you can wonder how to do mapcar in C++.

More disappointing is witnessing this same effect at work in the patterns community. Christopher Alexander's ideas of patterns has as its smallest part the pattern form--the concept of patterns really has to do with pattern languages and QWAN (the Quality Without a Name). It is not about con-struction tricks. It is about building artifacts not only suitable for human habitation, but artifacts that increase their human inhabitants' feeling of life and wholeness. Alexander is all about beauty and quality, not about how to stick things together cleverly.

Yet, the most popular form of software patterns is exemplified by those found in "Design Patterns," by Gamma, Helm, Johnson, and Vlissides, which contains little more than techniques for coding in C++ constructs found in other programming languages--for example, 16 of the 23 patterns represent constructs found in the Common Lisp language. There is no pattern language involved, and there is nothing about QWAN. Interest in patterns is coagulating around the so-called Gang of Four style, and it looks like things could get worse. In fact, I would say that patterns are alive and well as a form of documentation and a quest for clever solutions to common programming problems, and pattern languages, QWAN, and the quest for a better future are now on their way to the sewage treatment plant--the same place they went to in the world of architecture. Down with quality, up with clever hacks. Why worry about what makes a user interface beautiful and usable when you can wonder how to do mapcar in C++.

More disappointing is witnessing this same effect at work in the patterns community. Christopher Alexander's ideas of patterns has as its smallest part the pattern form--the concept of patterns really has to do with pattern languages and QWAN (the Quality Without a Name). It is not about con-struction tricks. It is about building artifacts not only suitable for human habitation, but artifacts that increase their human inhabitants' feeling of life and wholeness. Alexander is all about beauty and quality, not about how to stick things together cleverly.

Yet, the most popular form of software patterns is exemplified by those found in "Design Patterns," by Gamma, Helm, Johnson, and Vlissides, which contains little more than techniques for coding in C++ constructs found in other programming languages--for example, 16 of the 23 patterns represent constructs found in the Common Lisp language. There is no pattern language involved, and there is nothing about QWAN. Interest in patterns is coagulating around the so-called Gang of Four style, and it looks like things could get worse. In fact, I would say that patterns are alive and well as a form of documentation and a quest for clever solutions to common programming problems, and pattern languages, QWAN, and the quest for a better future are now on their way to the sewage treatment plant--the same place they went to in the world of architecture. Down with quality, up with clever hacks. Why worry about what makes a user interface beautiful and usable when you can wonder how to do mapcar in C++.

This is part history of AI hacking culture, part history of the AI bubble and how Lucid soared and crashed, and part Gabriel's take on patterns (he thinks they're mostly being used as crib notes to teach beginners how to get around limitations in lowest-common-denominator OO langauges).

For more info visit his web site, and particularly the part on Worse is Better

This is part history of AI hacking culture, part history of the AI bubble and how Lucid soared and crashed, and part Gabriel's take on patterns (he thinks they're mostly being used as crib notes to teach beginners how to get around limitations in lowest-common-denominator OO langauges).

For more info visit his web site, and particularly the part on Worse is Better

i'm thinking of an OS where there is no compiler, something more like forth going on. something where, if you wanted, you could click right down to the basics.

They were CISC, and RISC outran them.

They were caught in the AI Winter downdraft.

LispOS was harder to port than Un*x.

Mass parenthephobia.

They were The Right Thing (see section 2.1) and were killed off by the New Jerseyites.

Choose any or all of the above.

SOFTWARE FOR FIRST NEW MILLENNIUM MISSION CLOSEST YET TO "HAL 9000"

The Intelligent Execution Systems Project Home Page

Back to the Future: Is Worse (Still) Better?

That last paper is Richard Gabriel's follow-up to his original Is Worse Better?/i> paper. A cool quote from the "Back to the Future" paper:

Last year, this Common Lisp code was selected by a NASA panel for NASA's software of the year award. Despite this and despite the fact that the software works well in space, one of the high officials at NASA blocked the award and declared that it would not be given unless the system were re-coded in C, in which language it would be obviously better because ... um, becase ... ?

• My main point is that you can't rely on other people to know what needs checking: empirically, they don't.
• A language which does bounds checks doesn't have to check every access: it's often possible to prove things about the code and move checks out of loops, and so on. It's also possible for the compiler to warn you when it can't do this, so you can make declarations which enable it to prove more things. This is not new technology! It is, I suspect, hard to do this in a language which offers bounds checking as a bolt-on extra, like C++ (by overloading [] for instance): you need the compiler to really know about it.
• Serious implementations of languages that offer bounds checking should offer ways of saying that it's just safe to assume everything is OK in a bit of code, and so compile code which has no checks. You need this in a per-block basis, not per file, so you can bum only the places where you know the time is being spent.
• Bounds checks are not that expensive in any case -- the compiler should be able to get the index and the bound into a register at the start of any loop, and do a register comparison, which is seriously cheap compared to touching memory (which you're about to do when you access the array...). Again, having the compiler know about the checking is a win here.
• Not that much code is speed-critical in ways that bounds-checking will hurt -- for instance I doubt that many instances of BIND would be constrained by bounds-checking overhead! Some code obviously is, and I'm not suggesting that there should not be ways of making this stuff not need to check. Importantly, a performance profiler can find these parts of the code for you pretty reliably.

Of course, I don't see much chance of this happening because worse is better, but I can dream.