Re: Ada Successor Language

["Randy Brukardt" <randy@rrsoftware.com>]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:1b03e4ff-daf1-4c13-84ef-13aec1ba96e9@googlegroups.com...
>IMO, the rise to prominence of Unix and C [and arguably C++] is the worst 
>thing that happened
>in the field of CS. The amount of money, time, energy, and effort sucked up 
>by these is so
>staggering to contemplate that it would be difficult to overestimate the 
>costs, both real [e.g.
>all the buffer overflow vulnerabilities] and opportunities lost [e.g. the 
>low-level of today's
>"advanced" continuous integration, or the cost of using the FS as a DB, or 
>the costs of
>moronically considering unstructured text as THE appropriate/native format 
>for storing
>programs].

While I agree with your basic premise, I'm dubious that there is a better 
format than unstructured text for programs. There were many such 
alternatives explored in the 1980's, and they all had the property of making 
editing more complex. (I tried one for a while when a vendor wanted us to 
consider bundling it; it was a very nice job for the time, but the attempt 
to keep code parsable at all times made it much harder to do program 
editing - one needed multiple steps to do what was easy to do in one step 
and a bit of text editing. For instance, consider cutting out an elsif 
branch and turning it into a stand-alone if statement -- a restucturing I 
tend to do fairly frequently.)

More generally, non-plain-text editors put barriers into program 
construction, and those barriers make one stop and worry about how to make 
the editor happy rather than continuing to worry about the actual problem 
you are solving. While some level of friction can be tolerated if it leads 
to big savings later (that's why we can tolerate Ada's strong typing!), 
syntax errors just aren't a significant enough problem (they get detected 
soon enough in any scheme) to give much benefit.

This area is a problem I've been thinking about for literally decades, and 
I'm pretty convinced that most of the "solutions" are worse than the problem 
they'd be fixing. For a new scheme to be better, it would have to have 
little friction.

I also worry about the fragility of databases. If some "unstructured text" 
gets corrupted, you might lose a subprogram or two. (That used to happen a 
lot in the old days, and it still does once in a while.) And you can usually 
get that from a backup. But a corrupted database is pretty much useless - if 
the recovery tools fail, the only choice is to reconstruct from scratch. (I 
just had to reinstall one of the subsystems on our Windows Server because of 
a problem like this - had to uninstall the entire subsystem, delete all of 
the files, and then reinstall. Luckily I mainly cared about getting rid of 
the error messages, not so much the loss of data.)

With databases, everything is harder than it is with simple files: backups, 
searching, etc. all need specialized tools. So the benefits would have to be 
massive in order to make up for the variety of tiny pains that would ensue.

                                               Randy.