However, I am of the opinion that his article is nothing but a pipe dream. Analogies between software "engineering" and civil engineering are enlightening, but mainly only enlighten us as to how different building a brick wall is with writing a firewall. Software firewalls are more complicated than brick walls, not only when considered as single entity (a "wall), but when viewed at the component level.

Brick wall: composed of multiple, functionally identical bricks. Bricks are interchangable. Must be properly designed by a qualified engineer, but can be documented in often one or two relatively simple blueprints. Can be assembled according to blueprint by adequately trained bricklayers. Such training can be accomplished in a matter of weeks to obtain basic competence. Relevant properties of the bricks, mortar, and wall (dimensions, location, strength, etc) can be easily measured. Failed brick walls leave physical evidence which can be examined and analyzed to determine cause of failure. Walls are built in the physical world, which is like an OS with a non-changing spec: gravity, mass, intertia, momentum, etc, are all constants. The tools used to build the walls are also fairly simple, easy to operate, and well-understood.

software firewall: Made of numerous unique bricks (software components or lines of code). Not only is each brick different, we have to make our own bricks, and each brick has it's own unique failure mode. Each individual "brick" must be tested. Bricks are not interchangable. Built in a "virtual world" defined by an operating system or a hardware system, which themselves change frequently and exhibit unpredictable or anamolous behavior on occasion. Documents which describe the wall are complex, and the wall cannot typically be built from these documents by someone who doesn't also possess intimate knowledge concerning walls, bricks, and the "world".

To me, the biggest problem is that of the "world". For brick walls, we have a consistent, predictable system on which we build brick walls. A brick wall built 100 years ago works on the same physical principles as a brick wall built today, or 1000 years ago, because the world of physics itself has not changed over that time. The software world, however, didn't even exist 100 years ago and is basically impervious to our attempts to guess what it will be like 20 years from now. Whatever we "know" about the "world" now is likely going to be obsolete and worthless in the medium, if not near, future. We cannot develop "best practices" because only experience teaches which practices are best, and since everything in computing changes so fast, there's no opportunity to gain that kind of experience.

Dan has it right ... to make software work like brick walls, the things in his article need to happen. I just am doubtful that those things could actually happen.

Husker++. I really like the "world as an invarient OS". One additional thought came to mind as I read that.

When "bricks" were made by hand, whether they were the individual blocks in the pyramids 4500 years ago, or those that went into the Great Wall of China. Construction took a very long time.

Modern bricks are machine made. Construction is much quicker.

The software industry is still very young. We still haven't worked out how to make our bricks by machine.

The electronics industry is just a few years older, but is considerably further along the evolutionary path. From hand blow valves; through individually soldered transistors; discrete ICs; large scale, then very large scale integration.

1. Assembler / C ~= transitors
2. C++ / Java / Smalltalk ~= discrete ICs
3. (Elements of) Perl SQL (others?) ~= LSI
4. ??? => VLSI

Still a ways to go yet.

Unfortunately, we are still making the tools we use to build our programs, by hand. We need to get over the hump to the point where we can use tools to build our tools.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

We need to get over the hump to the point where we can use tools to build our tools.

One of the main problems here is that software evolves so fast, that tools based on languages in use today, are nearly worthless very quickly. If there were a very good tool for creating complex software, but it was based on Cobol, very few programmers would use it.
Even so, if someone could create such a software "brick maker" it might extend the life of the language used to build it.

-Theo-
(so many nodes and so little time ... )

I do agree with you but, somethings has not changed with computers, so some knowledge about computers is not obsoleted. One of these things that are not obsolete like imperative programming, in a von Neumann machine. And I do suspect that this is not going to change in the fifty years to come. Or to say it in another way, the details of computing do change alot but the broader picture does not change.

You make some excellent points. It is hard to write code that won't "break" if the underlying OS changes significantly.

Let's suppose that we start to make some software "bricks". That is to say we lay down some basic rules which, by fiat, will remain fixed. Future computing systems can have extra functions, but they must support our fixed standards. For example let's say that ASCII defines how our text files are encoded. (OK, OK I realize this is behind the times for good reason). Using a set of standards like this ( "bricks" ) we could begin to engineer some long lived software.

It really isn't too different from some of the things we have today. Email message from 10 or 15 years ago are readable, and sendable by today's email clients, even if the email clients are vastly different (improved? hmmm, maybe not). There are some "bricks" out there already, and I think we'll see more of them in the future, especially if we consciously try to create them.

-------------------------------------
Nothing is too wonderful to be true
-- Michael Faraday

You make some excellent extensions to Husker's excellent points. Here are a couple more things that occurred to me as I read your post:

Sure, bricks have been around a long time, they have always worked and still work basically the same way, and they offer a lot in terms of stability and value/cost ratio. But they have their limitations: a wall made of just bricks and mortar can only go so high before it needs to be designed with unacceptable thickness (value goes down while cost goes up). That's why a lot of builders use steel and concrete now; as technology develops better ways of building things, we can build bigger and better things. If we limit ourselves to just bricks, lots of things we take for granted today become impossible -- we'd be stuck with a "lowest-common-denominator" sort of existence (and more fatalities in earthquakes).

Here the analogy to software holds up rather well. Sure, we can stick to ASCII-based stuff, or whatever sort of limitation seems like a "simple, stable, always there and always usable" approach. But that puts limits on inventing and using new things, doing more with less, and doing stuff that was impossible last year/last month/last week.

This would suggest that the notion of "designing software for the next 200 years" is something that has a true and proper relevance for certain domains of software development, but not all domains. Someone will always want to read old email, old newsgroup postings, old web pages and document files -- if the means for doing this isn't stable for the next 100 years, there must at least be a reliable migration path for this data to keep it accessible, regardless of how software/OS/hardware species mutate over time. Durability has to apply to data more than it applies to the software that handles it.

One other point, from a linguistic perspective: while there are obvious and fundamental differences between human languages and computer languages, these two sets share an intrinsic, unavoidable property: their forms change over time, and the changes are determined in part by the environments in which they are used. This fact has a massive impact on programming languages, and to assert that we can write software now that will make sense in 100 years (or even half that) is like asserting that people who read Neal Stephenson or Tom Clancy could just as easily read Chaucer. NOT.

So we are forced to plod along, adapting from year to year, to the current circumstances; while the big companies think soley in terms of making short term profits.

The reality is the future is totally uncertain, because of the coming turmoil due to world overpopulation, and the effects of global warming.

Well, we could be hit by a very large asteroid, or have a supernova in a nearby star, (both more certain in their negative effects than the two cited pseudo-disasters) but that isn't an argument not to design our software and data storage methods thinking long term.

... while the big companies think solely in terms of making short term profits.

Many companies make long term investments, as do individuals. Companies are not the only actors in our stage either; NGO, non-profits and the gov't all spend considerable sums on things they need. Big (and little) companies thinking about this quarter's profit will gladly code to open specs that are engineered (as best as is feasible) to last as long as it is specified in the contract.

I find the article's argument compelling. I think it is wise to begin to engineer important computer software infrastructure using principles that will:
* Make it last
* Make it open for everyone to use
* Make it open for everyone to improve

Consider some of the systems used on the Internet. RFCs provide a mechanism for intelligent distributed design of software. The standards like TCP/IP DNS HTTP provide underlying sw infrastructure that has lasted at 20 to 30 years already. It would be wise to continue this trend and create similar specifications for voting systems, public accounting systems, and public records systems.

<sarcasm>
Or maybe we should just crawl in our holes because the weather might be bad tomorrow.
</sarcasm>

-------------------------------------
Nothing is too wonderful to be true
-- Michael Faraday

<from the hole>

"The best laid plans of mice and men often go astray".

</from the hole>

Plan for unexpected things to happen, especially in a "fast-paced rat-race civilization".

---

I'm not really a human, but I play one on earth. flash japh

I am surprised nobody has yet mentioned Paul Graham's execellent article, The Hundred-Year Language. It seems relevent to the discussion at hand, and he even says nice things about Perl. It's worth a read.

You weren't the only one to make that connection :-)

---

...every application I have ever worked on is a glorified munger...

Reason 521: Why the vision of 'software bricks' will never come to pass

Software is an imaginary tool for solving imaginary problems.

If someone were to demand of you, "Give me a tool suitable for smashing a car window, holding some paper down on a table, and stopping a door open" you could hand them a "brick" and be done with it. Moreover, a different person completely unfamiliar to you, from a totally different culture and society could do exactly the same thing. It would be reasonable to expect both outcomes to be interchangeable.

In contrast, if someone were to demand "Write an application that tells time, beeps an alarm and keeps my TODO list, there are as many solutions as there are hands to get the job done. Moreover there is no reason to expect the solutions to be interchangeable, or interoperable in any way; absent a lot of kibbitzing and hand-holding and iron-clad edicts of standardization from which even the slightest deviation is unequivocally banished.

However, standardization and intellectual elasticity(imagination) are mutually incompatible.

Why does Perl enjoy such avid admiration (or hatred) from those who know its expressiveness (or complain that it is unreadable gibberish)? It's because those perceptions are based on imaginary constraints and purely intellectual constructs.

You cannot ask two people to write a book review on a book, and then expect the paragraphs and sentences of the reviews to be 'mix-n-match' interchangeable ... at least not without seriously constraining their imagination and creativity ... but then such constraints mean you won't really be getting a book review at all, just painting by numbers. So too it is with the realm of all 'information technology'.

It's not necessarily a bad thing, its just the way it is.

You cannot ask two people to write a book review on a book, and then expect the paragraphs and sentences of the reviews to be 'mix-n-match' interchangeable...

But that they, or someone else in 200 years time, will be able to read each others reviews, or the subject book isn't such a Great Expectation.

We, or rather "certain we's" can still (or perhaps again, given the Rosetta Stone) read the hyroglyphs on 4500 year old foundations stones. Even though the "brick" it's written on isn't suitable for use in most modern buildings.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

It is interesting. I think it's also asinine and arrogant.

The main analogy is shallow and breaks down immediately. The architecture of 200 years ago isn't kept around because it's so good but because it's historical and would be expensive to replace. The great cathedrals are really quite useless for anything but praying. And the architecture of today is so artificially constrained by the kinds of ideas that he's recommending that nothing new or interesting is being done, or is even legal to try. A few great bridges, corporate towers, and public works aside, we're in the dark ages of architecture.

We're also not talking about buildings, we're talking about the evolution of what can be built. Bricks can make a long lived building (out of earthquake zones) and a decent boat if you know how but they make lousy airplanes and worse spaceships and even more terrible surgical instruments.

The managed ecosystem argument also falls flat. For about two hundred years, oddly enough, humans have been purposely introducing species and interfering with natural wild-fire cycles in an attempt to improve ecological situations. Almost all, damaging failures. The best thing to do with an ecosystem if you want it to thrive is to leave it alone.

Trying to engineer standards for 200 years from now by introducing an open source bureaucracy at least has one of the great Perl qualities: Hubris. In this case I'd say it's a guaranteed recipe for a fall. We don't need more boxes to shoe-horn ideas into, we need to keep openness and freedom to throw ideas into the fray.

If architects made buildings the way computer programmers wrote programs, the first woodpecker to come along would mean the end of civilization.

One of the problems, I think, is marketing and timing constraints. Our company is building a machine very similar to a smartcard 'cash-on-a-chip' funding station. There are certain things that can go wrong with the mechanical side of things that we know could happen, but simply don't have time to compensate for before we have to get it to our client.

Contrast this with our transaction terminal that accepts these cards -- it has been in development for over four years, and since I took over its development from a contractor three years ago, the terminals have gradually gone from requiring a restart every two weeks, to running autonomously for several months without requiring maintenance on our part. (Right now I can see five devices that have been running since March 24th -- 114 days with no restart.)

$"=$,,$_=q>|\p4<6 8p<M/_|<('=>
.q>.<4-KI<l|2$<6%s!<qn#F<>;$,
.=pack'N*',"@{[unpack'C*',$_]
}"for split/</;$_=$,,y[A-Z a-z]
         {}cd;print lc
[download]

(Right now I can see five devices that have been running since March 24th -- 114 days with no restart.)

Only (365.4*200)-114 days to go. :-)

Vernor Vinge (an AI guy who writes intelligent scifi) has a book dealing with millenia-old software (_A Fire Upon the Deep_). Among other puzzles is that no one remembers what epoch 1970 was the start of :-).

Part of the problem is that the world changes so quickly within technology. Who, in 1992, would have foreseen the explosion of web commerce in less than a decade? Not many, I'd wager. The programming paradigms of the 60s were outdated 25 years later, and technology had proceded at a pace where a lot of programming problems had been solved by quicker, cheaper, more powerful hardware.

I'm not saying what he says doesn't have some merit; I always write code so that I don't have to spend a lot of time supporting it and so it will last a while. (At least, that's the goal.) Back in '98, while on a contract, I wrote some stopgap software that was supposed to last three months; it is just now being shut down, I heard. However, the reason it lasted so long had little to do with my software and mostly to do with management moving at the speed of continental glaciation. Even management can make a change within 200 years (thought admittedly it's not a certainty.)