Futurist Programming

WardCunningham suggested Paul Haeberli and Bruce Karsh's "Background on Futurist Programming" and "Manifesto of Futurist Programming" in the discussion on TheDumbingDownOfProgramming.

Background: http://www.sgi.com/grafica/future/index.html Manifesto: http://www.sgi.com/grafica/future/futman.html References: http://www.sgi.com/grafica/future/futnotes.html

[It seems to be a joke; not to be taken too seriously.]

I wish I had read your recommendation earlier -- I took it seriously.

Ward, I hate to criticize something you've written, because it so frequently results in my being wrong; however, the article you mentioned seemed mostly rhetoric, with the only action suggested being things that, more frequently than not, seem to cause problems. They also seem fairly non-XP, though they are trying to go in roughly the same direction.

However, they categorically reject everything that software has done since the 70s, because "it hasn't improved." While I agree that the state of software has significant problems, I don't think that throwing everything out and starting over in one step is the appropriate solution; we aren't *that* far off. I remember code maintenance on projects written like they suggest doing; if software moves back there, with no fixes for that problem, I'll find a different line of work. -- EdGrimm

They certainly take a position contrary to that which I promote today. Still, I couldn't help but wonder if I could meet their expectations. There was a time that I could. -- WardCunningham

The http://www.sgi.com/grafica/ site has a lot worth recommending even if this work isn't among them.

The futurists aspire to:

"...

To destroy the cult of the past, the obsession with all things old, academic pedantry, and formalism
To cast our scorn profoundly on every last form of imitation
To exalt every form of originality, even if foolhardy, even if extremely violent

..." - seen in the manifesto (URL above.)

Sounds like Novelty Vampirism to me. (See NoveltyVampires.)

Given that "computer hardware has realized performance increases of a factor of more than 200 in the last 20 years", I fail to see how "computer science graduates [making] programs that are fat [and] slow" would be such a big problem.

Business people have a backlog of functionality they want implemented, and getting an implementation that makes less-than-optimal use of computer time is probably a good thing: human time is now much more valuable than computer time. And having the necessary business functionality, even if it's kinda' slow, is better than having nothing.

[retracted]

I found the Manifesto interesting and entertaining, but largely meaningless. Though the paragraph starting "Go ask the high priests of the True Cult" has some promise.

Some of their thoughts even have merit:

"What is the shortest program that will accomplish your task?"

And I agree with most of "Top Futurist Programming priorities" in http://www.sgi.com/grafica/future/futnotes.html

-- JeffGrigg

Isn't it amusing to see the phrase "To cast our scorn profoundly on every last form of imitation" in a document that is imitating someone else's manifesto?

Which, among other things, led me to think that it was obviously tongue-in-cheek. You all don't think so?

I thought it was either a joke or the work of lunatics. Which makes it, in effect, a joke either way.

I read the paper on the SynthesisOs; it's excellent. I've moved some discussion to that page.

I have also known people doing good work in assembler. Perhaps not as high-level as Smalltalk, but certainly as high as C. A good macro assembler for a good CPU (i.e., not 80x86) is pleasant to use. The Taos VP code is essentially a portable, high-level assembler.

So I praise some of the same things these guys are praising. Not because they're original, but because they're good. They'd still be good even if they were the mainstream. I'd by-pass these NoveltyVampires and look at some of the things they are pointing to. -- DaveHarris

I (Alistair) liked:

Structured programming = slow. 
Modular = bloated. 
Extensible = late. 
Reusable = buggy. 
Object-Oriented = slow and bloated and late and buggy. 
Top-Down Design = hard to use. 
Standard Compliant = slow and late and hard to use = obsolete. 
Automatic = Manual. 
Configurable = Unfinished. 
Fully Configurable = Completely Unfinished. 
Type Safe = Imponderable.

I (EldridgeMount?) can't help but notice that two, rather distinct, practices are being lumped together (and collectively "scorned" :) ) in the Manifesto: Object-Oriented techniques and designing for tomorrow.

If I wanted to write an air-traffic control system that ran absolutely as fast as possible, I'd craft the whole damn thing in assembly. But what's the end goal? To create a safe, working system, not to conserve CPU cycles. Once a piece of software reaches a certain level of complexity, it becomes absurd to even consider writing it in assembly, simply because the bookkeeping (keeping track of registers, memory locations, etc.) grows exponentially. There's simply too much unmasked complexity for the human mind to keep track of.

High level languages such as C take the first step by abstracting away the details of memory management and encapsulating common tasks (conditionals, loops, subroutine calls) into a set of language constructs that are more easily parsed by the eye. OO goes a step further, allowing the programmer to create a hierarchy of increasing abstraction and decreasing detail.

Hierarchical design exists in all engineering disciplines, as well as in nature. The human body is much simpler to understand in terms of organs than it is in terms of its tissues, or cells, or molecules, or subatomic particles.... etc. etc. etc.

Some dispute that OO is mostly about "trees". Further, the value of trees is not without practical limits: LimitsOfHierarchies.

Most OO languages are not limited to "trees". Most production OO languages support one or more of the following:
- MultipleInheritance (CommonLispObjectSystem, CeePlusPlus, EiffelLanguage)
- DynamicTyping/DuckTyping (wherein the concept of "inheritance" is only of importantance in defining a class, and has little import on how a class may be used; SmalltalkLanguage is an example).
- At a minimum, multiple implementation of interfaces (JavaLanguage)
Nobody here claimed they are, that I can tell. I would also note that multiple inheritance is controversial in some OO circles.

OO, however, like any technology, can be grossly misused. No programming language or methodology can prevent people from using it to generate bloated, spaghettied crap full of lurking bugs. In particular, the rate of crap generation goes up remarkably when programmers start programming for every possible future application (e.g. window squeegees that scale for windows of all shapes & sizes).

Always code for the task at hand. Rely on your ability to make modifications to support changing requirements and added features; but make use of flexible, yes, modular architectures so that when change comes (as it inevitably will), the cost of that change will be minimized. OO provides the constructs for doing this easily, at the cost of *gasp* a few extra cycles for dispatching virtual function calls, and *yikes* a few extra bytes of memory to provide intelligent, object-based memory management.

Well-crafted, modular architectures are inherently reusable and extensible; and believe it or not, reusable code is a wonderful thing, *WHEN* it's written lean. If I want a tire for my car, I go and buy one. I don't learn how to vulcanize rubber in my garage. Please excuse the thinly-veiled metaphor. :)

The place where I agree with them the most is their criticism of how computer science is taught. My first reaction was, "Huh? The CS department didn't teach me how to develop big, bloated systems. I never wrote anything in school that was more than a few thousand lines!"

And then it occurred to me that teaching me nothing about how to develop large systems is equivalent to teaching me how to develop them badly. I never had a chance to see a well-designed large system of code from the inside; even a badly-grown large system would have at least let me see what not to do.

On a related note, I agree with JakobNielsen (http://www.useit.com/) that universities should teach students how to make usable systems. One approach would be to, early on, have students put together front ends to a given back end - often UI is ignored because all the time is spent writing the back end. With the plethora of EZ-GUI tools out there (from HyperCard, which I like, to VisualBasic), you wouldn't have to teach them much code in order to start them thinking about whole systems and the users' experience of them. -- GeorgePaci