Re: Ada Successor Language

[Shark8 <onewingedshark@gmail.com>]

On Friday, June 15, 2018 at 11:55:18 AM UTC-6, jm.ta...@gmail.com wrote:
> > > 
> > 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
> 
> 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 interesting though is the statement "the price was quickly covered by the gains in productivity" -- this means the utility in ONLY productivity was enough to quickly pay for itself.

The reason is that the entire thing was an Integrated Development Environment in the true sense of the phrase, not the "hyped up editor" (a slight exaggeration) that modern IDEs get. / One of the issues is that the tools in such 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', "tabs vs. spaces" and other formatting elements are flagged as 'changes' completely apart from any semantic alteration. (This means that, within such source-control, there can be many "false positives" when you're looking at a change-log... and even if you have the proper revision loaded, finding the actual 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 changed tabs/spaces and they committed some buggy code.])

The lack of integration can be seen in other areas too; take CPAN [perl's package manager] for instance -- it's essentially a giant archive of zip-files and an index, synchronized across a network -- so far, so good & everything works well... until the text-based index is corrupted or there's clashes between zip-files or such. // An alternative would be to store the code as a DB-amiable IR, which is stored in a DB... things could be done here like *automatically* tracking dependencies, and compatibilities within these dependencies; such an effort would be incredibly hard to set-up [and maintain] in the "text-file + zip-files" approach.

This sort of integration is something that isn't all that common in the places 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=ADA301551