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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!.POSTED!not-for-mail From: "G.B." Newsgroups: comp.lang.ada Subject: Re: GNAT GPL is not shareware Date: Fri, 09 Jan 2015 15:11:10 +0100 Organization: A noiseless patient Spider 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> Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 9 Jan 2015 14:10:41 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="b96887e80893c84a90c3007226ca0d1c"; logging-data="8607"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19h0niuHE6efORM7m2OiMGicekG1Ku+YJs=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: Cancel-Lock: sha1:fkhX3d1qbXWF9iounK1Wj5rCmFA= Xref: news.eternal-september.org comp.lang.ada:24502 Date: 2015-01-09T15:11:10+01:00 List-Id: On 09.01.15 03:20, Randy Brukardt wrote: > But using the "relational model" is nowhere near free. One has to import > some giant bloatware A relational model is not the same thing as using an RDBMS. When a language has it as a built-in, nothing is imported at all. (SETL, LINQ, …). > There of course are problems for which DBs are well suited, but there are > far fewer of them out there than are generally supposed. I'd rather say that not enough problems are being addressed by skillfully using good relational techniques, as they take learning, and thinking. Ad-hoc solutions seem to be a replacement, because they are quicker to get our the door, initially. Maintenance of idiosyncratic programs in the aftermath. >> 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. 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.) > because the answer is in the hundreds for > many common identifiers. And if not, simple text search gets you the answer. Simple text search will hardly find identifiers at Ada grade reliability; rather, this kind of text search is called semantic analysis, and is typically performed by a full Ada compiler, or equivalently by an ASIS tool ;-) > 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! >> 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. >> 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.