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.

In reply to Re^3: (OT): 200-year software by graff
in thread (OT): 200-year software by dragonchild

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.