Re: Ada Successor Language

[Shark8 <onewingedshark@gmail.com>]

On Wednesday, June 13, 2018 at 3:15:21 PM UTC-6, Paul Rubin wrote:
> Shark8 writes:
> > Unix and C [and arguably C++] is the worst thing ... 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].
> 
> I don't think those lost opportunities have much to do with Unix or C.

Oh, but it does!

> Fancy CI that I've seen has usually been in conjunction with Ruby or
> Python projects, etc.

Relatively new; when they should have been industry standard two decades ago? Sounds like lost opportunity that we-as-an-industry are just now rediscovering. (Also, TTBOMK all of these solutions are text-based.)

> The FS is similarly a perfectly good DB depending
> on what you want for it to do, syntax can be recovered from free text by
> parsing, etc.

The FS is NOT a good substitute for a DB, furthermore it introduces perfectly avoidable environmental dependence which would not otherwise exist (e.g. case sensitivity, the path, the path separator, timestamp resolution, etc.)

> This mostly comes down to human factors rather than
> artifacts of buffer overflows or anything like that.  Ada to zeroth
> order is C++ without the buffer overflows.  That's a good thing but it
> doesn't affect the other stuff you mentioned.

Except you're ignoring things like the Rational 1000 which was mentioned earlier in this thread -- which is thirty years old now, IIRC -- the entire environment was geared for SW development; instead of getting environments like this we-as-an-industry wasted time and energy on C-isms and Unix-isms.

The whole text-based craze which causes you to parse everything again and again and again is straight from Unix. But more than this, it's false sense "mostly works" and lack of foresight is littered throughout.

Let's take the whole "one program that does one thing well" concept, ok that's all well and good. So you build a system piping inputs and outputs...it seems fine, at first glance, until you look at the fact that the medium of transport [pipes] is text. -- Now what you have is a system that serailizes and deserializes constantly, but not with any actual standard way, and usually with each component using an ad hoc method to read and write. -- So what you've done by standardizing on text is forced continual parsing and re-parsing for every element in the pipeline. 

This is the whole reason that JSON is popular; because it "solves" the problem of text-stream consistency... sadly, the industry fails to realized that these serialize/deserialize problems were already solved via ASN.1.

I highly recommend you watch this video:  http://www.youtube.com/watch?v=8pTEmbeENF4