These are important issues and examples are ready at hand. (01)
Simple examples: the source Latex of my doctoral work (1992) evaporated from my
own magnetic tapes and those at the school fated toward a similar end. I, of
course, relied upon the postscript version to maintain continuity, leaving me
with a readable format problem. I was recently offered documents and code I and
others had written in the 1980s to be offered to the Computer History Museum …
to be told the materials were secured (sic) on magnetic disks. (02)
The problem is systemic. (03)
The majority of application code written in the past 40 years simply cannot be
rescued and moved to modern multicore architectures - where it will get no
faster going forward and probably will run slower than before. This is in large
part because the programs cannot be automatically translated to these
architectures. So what will we do? We'll propagate obsolete and inefficient
technology simply because their is a market for it. (04)
The good news is that most of the useful algorithms have found their way into
print. (05)
So at some point it will pay to go back and do it over - if for competitive
reasons alone - but, again, the cost to "do it right" will be deferred in favor
of the cost to do it quickly and cheaply, deferring and increasing critical
costs to the poorly considered future. (06)
The bad news is that software engineering has yet to become a mature
engineering profession. One that includes the practical long term engineering
skills of an "antique draftsman." (07)
Regards,
Steven (08)
--
Steven Ericsson-Zenith
Institute for Advanced Science & Engineering
http://iase.info (09)
On Feb 15, 2013, at 3:55 PM, "Barkmeyer, Edward J" <edward.barkmeyer@xxxxxxxx>
wrote: (010)
> Paul Tyson wrote:
>
>> I don't know the history of computer graphics
>> applications, but something similar must have happened--the early
>> developers looked at draftsmen putting lines and curves on mylar and
>> decided to write a program to put lines and curves on a CRT. It's taken
>several
>> generations of graphics software (each having to "interoperate" with the
>> previous generation) to really begin to augment the engineer's primary goal
>> of communicating design intent--and some people still don't believe that's
>> possible without honoring the conventions of antique draftsmanship.
>
> Well, part of the problem was to get an effective computational
>representation of solid geometry, and the tools that did that began to emerge
>after academic feasibility demonstrations in the mid 1980s. And part of that
>feasibility was having fast enough processors, accurate arithmetic, and fine
>enough graphical resolution and fast enough graphics refresh. That is, a mere
>4 or 5 technologies were needed to enable that.
>
> BTW, putting accurate lines and curves on a CRT from a digital source, rather
>than an analog recording, was no small feat in 1970, when the early graphical
>CRTs first appeared (at significant cost). As late as 1990 the cost of top of
>the line graphics terminals was in the 30K$ range, and had been since the
>first ones 20 years earlier, which is a big difference in constant dollars,
>and had a big impact on the size of the potential market. The Tektronix folk
>made the price/performance breakthrough about 1974, and dominated the market
>for 10 years until cheap raster technology emerged that could approximate the
>accuracy of their technology.
>
> And for the record, the antique draftsmanship conventions have a different
>motivation -- long-term archival of the engineering models. What CAD form
>from 1985 can still be processed? Do you think all those 1985 aircraft have
>been junked? Do refineries built in the 1980s still function? If we now
>commit to saving the latest and greatest Pro-Engineer solid models in native
>form, what tools will be able to read the recording media and decode the model
>and display the holographic images in 2025, let alone 2050? If you are
>authorizing the construction of a nuclear plant, what archival form of the
>engineering models are you going to require? Maybe those antique draftsmen
>still have a value.
>
> I agree with Paul's sentiment, but the business of engineering models is
>important, it is very high tech, and it is fraught with all kinds of very real
>business constraints.
>
> -Ed
>
> --
> Edward J. Barkmeyer Email: edbark@xxxxxxxx
> National Institute of Standards & Technology
> Systems Integration Division
> 100 Bureau Drive, Stop 8263 Work: +1 301-975-3528
> Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800
>
> "The opinions expressed above do not reflect consensus of NIST,
> and have not been reviewed by any Government authority."
>
>
>
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/
> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> (011)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (012)
|