From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:b00c:: with SMTP id d12-v6mr382800itf.14.1528946824778; Wed, 13 Jun 2018 20:27:04 -0700 (PDT) X-Received: by 2002:a9d:190a:: with SMTP id j10-v6mr54287ota.0.1528946824668; Wed, 13 Jun 2018 20:27:04 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!u78-v6no348178itb.0!news-out.google.com!z3-v6ni226iti.0!nntp.google.com!u78-v6no348174itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 13 Jun 2018 20:27:04 -0700 (PDT) In-Reply-To: <87po0upevs.fsf@nightsong.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=76.113.16.86; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 76.113.16.86 References: <5e86db65-84b9-4b5b-9aea-427a658b5ae7@googlegroups.com> <878t7u1cfm.fsf@nightsong.com> <8a65f8ff-4a75-43f2-884c-6872780f7ea8@googlegroups.com> <771e8e35-b71a-499d-a0fe-bb0df1de22ab@googlegroups.com> <92741619.550509671.540055.laguest-archeia.com@nntp.aioe.org> <81e22064-bb0e-4e0b-982a-c17a2cad5977@googlegroups.com> <1b03e4ff-daf1-4c13-84ef-13aec1ba96e9@googlegroups.com> <87po0upevs.fsf@nightsong.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada Successor Language From: Shark8 Injection-Date: Thu, 14 Jun 2018 03:27:04 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53091 Date: 2018-06-13T20:27:04-07:00 List-Id: 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]. >=20 > 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 ag= o? Sounds like lost opportunity that we-as-an-industry are just now redisco= vering. (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 perfect= ly 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 ea= rlier in this thread -- which is thirty years old now, IIRC -- the entire e= nvironment was geared for SW development; instead of getting environments l= ike 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 a= gain 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 tha= t'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 serailize= s and deserializes constantly, but not with any actual standard way, and us= ually with each component using an ad hoc method to read and write. -- So w= hat you've done by standardizing on text is forced continual parsing and re= -parsing for every element in the pipeline.=20 This is the whole reason that JSON is popular; because it "solves" the prob= lem of text-stream consistency... sadly, the industry fails to realized tha= t these serialize/deserialize problems were already solved via ASN.1. I highly recommend you watch this video: http://www.youtube.com/watch?v=3D= 8pTEmbeENF4