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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: GNAT GPL is not shareware Date: Fri, 9 Jan 2015 15:33:30 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <87bnmetex4.fsf@ludovic-brenta.org> <87lhlirpk0.fsf@ludovic-brenta.org> <79f3eff7-2b45-40ae-af94-fa9a17426d82@googlegroups.com> <87bnmd8mg2.fsf@ixod.org> <19cf9bc2-f8b9-4735-b427-7b070dda59da@googlegroups.com> <1otenmcbgnvlt$.dn9361nl2jm8$.dlg@40tude.net> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1420839210 4383 24.196.82.226 (9 Jan 2015 21:33:30 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 9 Jan 2015 21:33:30 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:24507 Date: 2015-01-09T15:33:30-06:00 List-Id: "G.B." wrote in message news:m8onh1$8cv$1@dont-email.me... ... >>> Using the GNAT repertoire in the compiler sources, >>> this question is typical of thinking "relational": >>> >>> "List all Ada identifiers that are public in packages >>> that are children of P0, provided that they are not of >>> a pointer type." >> >> No one asks questions like that, > > Everyone asks questions like that. No they don't. I believe the "public in packages" part, but not the "not a pointer type" part. This question is far more complex than the real questions that get asked. Besides... >> Proof: >> the answer is proudly presented, even graphically (call graphs, >> identifiers with locations and full name in error messages, >> referring to others presented similarly on the same line, >> structure views of source for analysis, overview, inspection, >> review, etc.) Maybe, but that only illustrates the disconnect I have with modern, can't do anything themselves programmers. I have never used a tool that does any of the above (with the possible exception of the Rational Apex IDE, and I never figured out how to get it to do anything much beyond compiling) and the need is quite rare - surely not worth the effort to construct. A few things fall out for free (the location of declaration is stored with each declaration, of course, so once the compiler knows the item, it could put that into the error messages. But Janus/Ada does that only a very few cases, in large part because the size of the compiler was a critical constraint when it was designed. That made error handling quite rigid, with a single template for all messages.) ... >> Besides, visibility information can't sensibly be represented in a >> database, >> it depends on both the location of the declaration and the location of >> use. > > See? A relational form of dependence is right there > in front of the Adaist's eyes! I haven't any clue as to what you are talking about. Visiblity information is tree-structured, and it is not possible to map trees sensibly into the flat tables required by relational technology. Doing so distorts the problem (as Dmitry notes). >>> A standard RDBMS solution, while obvious, is perhaps >>> inadequate for reasons of performance, specialization, >>> Ada fanatism, etc. But it takes a political argument >>> to deny that compilers do actually include those data >>> structures and algorithms that the relational model >>> has as built-ins. >> >> This stuff is so basic that any program would have it (entity lookup, for >> instance). If a DB didn't have it, it would be completely useless. So >> that >> proves nothing whatsoever. > > If true, your observation proves that basic stuff can be > done well using a relational model, without reinventing wheels, > as soon as a viable one is available with, and controlled > by, a programming language. Last I saw this was an Ada forum, and the entire point of languages at the level of Ada is to build wheels (and engines and brakes and...). Perhaps you're right (although I happen to think the wheels you're worrying about are discredited as a solution for much), but even so, it has nothing to do with Ada. >>> For a worldly, commercial case, >>> >>> [.] the hugely successful addition of an RDB >>> option that Google added to the same App Engine. >> >> Which just shows that most so-called developers today could not program >> their way out of a paper bag. They depend on having everything pre-built >> for >> them, and then they make fragile mashups that depend on things that they >> have no control over at all (meaning that there code will break >> frequently). > > Actually, the technical aspect of Google's App Engine > reveals that programmers would have all control they might > want: It is Google's business driven closing of source, > not the relational model, that makes programmers depend > on Google. Or, similarly, on Microsoft (Azure), etc. The only thing dumber than depending a giant DB like Oracle is depending on some cloud software like Google App Engine. Their approach is that anything can be changed at any time, they don't have any notion of a contract (certainly not in the Ada sense), so your software can be broken at any time. Getting software right isn't even possible in such an environment, at best you can get it to work at some moment in time. Cloud people have completely lost the value of versioning and change control. You buy a new car all at once, and then get used to using it as everything non-critical will be different. You don't get a new seat one week and a new brakes the next and then new engine etc. Because there's a big chance that the new brakes won't work right with the old wheels. Randy.