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:5353:: with SMTP id n80-v6mr1076008itb.6.1529092690786; Fri, 15 Jun 2018 12:58:10 -0700 (PDT) X-Received: by 2002:a9d:70c2:: with SMTP id w2-v6mr106819otj.2.1529092690684; Fri, 15 Jun 2018 12:58:10 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!2.eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!85.12.16.68.MISMATCH!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.am4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!d7-v6no2235075itj.0!news-out.google.com!z3-v6ni2717iti.0!nntp.google.com!u78-v6no2215655itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 15 Jun 2018 12:58:10 -0700 (PDT) In-Reply-To: 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada Successor Language From: Shark8 Injection-Date: Fri, 15 Jun 2018 19:58:10 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4740 X-Received-Body-CRC: 3225772830 Xref: reader02.eternal-september.org comp.lang.ada:53129 Date: 2018-06-15T12:58:10-07:00 List-Id: On Friday, June 15, 2018 at 11:55:18 AM UTC-6, jm.ta...@gmail.com wrote: > > >=20 > > I don't know the exact price, but all users I met said that > > 1) it was very expensive > > 2) the price was quickly covered by the gains in productivity >=20 > How much is "very expensive"? > Are similar products for other languages as expensive? AFAIK, there's no other "similar product" to that degree. What is really in= teresting though is the statement "the price was quickly covered by the gai= ns in productivity" -- this means the utility in ONLY productivity was enou= gh to quickly pay for itself. The reason is that the entire thing was an Integrated Development Environme= nt in the true sense of the phrase, not the "hyped up editor" (a slight exa= ggeration) that modern IDEs get. / One of the issues is that the tools in s= uch environments *AREN'T* integrated. So you get idiotic text-based source = control where int main() { while (true){}; } and int main() { while (true){}; } are actually *different* -- this means that stupid things like 'style', "ta= bs vs. spaces" and other formatting elements are flagged as 'changes' compl= etely apart from any semantic alteration. (This means that, within such sou= rce-control, there can be many "false positives" when you're looking at a c= hange-log... and even if you have the proper revision loaded, finding the a= ctual alteration that was supposed to be logged might be difficult because = so many non-semantic changes interfere with getting a picture of the actual= semantic changes. [ex: looking at a diff when someone's editor helpfully c= hanged tabs/spaces and they committed some buggy code.]) The lack of integration can be seen in other areas too; take CPAN [perl's p= ackage manager] for instance -- it's essentially a giant archive of zip-fil= es and an index, synchronized across a network -- so far, so good & everyth= ing works well... until the text-based index is corrupted or there's clashe= s between zip-files or such. // An alternative would be to store the code a= s a DB-amiable IR, which is stored in a DB... things could be done here lik= e *automatically* tracking dependencies, and compatibilities within these d= ependencies; such an effort would be incredibly hard to set-up [and maintai= n] in the "text-file + zip-files" approach. This sort of integration is something that isn't all that common in the pla= ces I've worked, which usually go with various individual tools. ---------- This Technical Report [1988; 92 pg] describes the whole thing: http://resources.sei.cmu.edu/asset_files/TechnicalReport/1988_005_001_15650= .pdf There's an Army Report [1995; 72 pg] here, which I haven't read yet: http://www.dtic.mil/get-tr-doc/pdf?AD=3DADA301551