Dear Matthew and Kingsley, (01)
JFS
>> The estimated amount of legacy software
>> in the world is a half trillion lines of code.
>>
>> Typical programmer productivity with current tools:
>>
>> ● 10 to 15 lines of fully debugged code per person per day.
>> ● Cost per line of code: $18 to $45. (02)
> MW: That does not mean that you would have to write half
> a trillion lines of code to replace them. (03)
That's true. Nobody replaces legacy software. They just run it
for many years and later systems have to interoperate with it.
For the statistics I quoted (and many others), see (04)
William M. Ulrich & Philip Newcomb, Information Systems
Transformation: Architecture-Driven Modernization Case
Studies, MK/OMG Press, 2010. (05)
But large systems continue to be used for critical applications
long past their expected retirement dates. As an example, just
consider one of many, many examples: (06)
1. The Strategic Air Command commissioned the SAGE computers
from IBM in the late 1950s to monitor all aircraft flying
in North America (US and Canada) in order to detect any
Soviet planes coming over the North Pole. (07)
2. Those computers were the largest vacuum-tube machines ever
built, and vacuum tubes are notoriously unreliable in any
system that contains thousands of them. But SAC requirements
stated that no more than 15 minutes of downtime per year
would be allowed. (08)
3. Therefore, IBM built the computers in pairs with 100%
redundancy: whenever one failed, the other would continue
operating until the first was up and running again. (09)
4. Those machines kept on running for many years when a single
chip would be far faster and more reliable. But the difficulty
of rewriting and debugging all the software was prohibitive.
So they kept on going until the mid 1980s. (010)
5. Unfortunately, by the end of their lifetime, almost nobody was
making vacuum tubes -- except for a plant in the USSR. So the
US gov't, through an IBM subsidiary, continued to buy vacuum
tubes from the USSR for the machines to monitor the USSR. (011)
6. When they finally retired the SAGE computers, it turned out that
the total downtime during all those years was less than 15 minutes. (012)
JFS
>> That was the fatal flaw in the SemWeb:
>> ignoring everything that went before -- including the fact that
>> every commercial web site was built around a relational DB.) (013)
KI
> But that's no longer the case today. For instance, you have SPARQL
> which is closely aligned to SQL. (014)
The main similarity between SPARQL and SQL is the keyword SELECT.
SPARQL only supports triples, it only supports a tiny subset of SQL,
and using a path-based method to state a query is a royal pain. (015)
They had path-based methods for DBMS in the 1970s, and programmers
voted with their feet: SQL was much easier for them to use. Most
object-oriented DBs today support both SQL and path-based methods,
and the majority of programmers prefer SQL. (016)
KI
> Please forgive the past. Initially they got many things wrong,
> across a number of technical and marketing fronts, but that's the past (017)
Forgiveness is irrelevant. The question is what do paying customers
buy and use. As Guha said, "Somehow RDF never caught on." He's now
working at Google, where they build Google apps around JSON, which
supports n-tuples, including typed n-tuples -- you can map those
equally well to a triple-store or to an RDBMS. (018)
But customers are concerned about getting locked in to a single
supplier. So Google, Microsoft, and Yahoo! founded schema.org. (019)
John (020)
_________________________________________________________________
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 (021)
|