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: border2.nntp.dca1.giganews.com!nntp.giganews.com!news.glorb.com!news.ecp.fr!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: Thu, 8 Jan 2015 20:20:35 -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 1420770036 28246 24.196.82.226 (9 Jan 2015 02:20:36 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 9 Jan 2015 02:20:36 +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: number.nntp.giganews.com comp.lang.ada:191798 Date: 2015-01-08T20:20:35-06:00 List-Id: "G.B." wrote in message news:m8lnlg$eat$1@dont-email.me... > On 08.01.15 09:14, Dmitry A. Kazakov wrote: >> On Wed, 7 Jan 2015 16:47:25 -0600, Randy Brukardt wrote: >> >>> I have yet to use *anything* that used a DB that could not have been >>> done >>> better without the DB. >> >> True. > > False, in general: > > As soon as you start talking truly relational, you'll either > use Prolog-ish programs, which are DB programs. Anyone who's talking "truly relational" needs their head examined. > Or, in Ada, you'll use pointers or cursors, or symbols in > anything else, and start reinventing everything that the full > relational model provides for free. But using the "relational model" is nowhere near free. One has to import some giant bloatware that changes without warning, most likely has to employ an expert in said bloatware in order to get anything done, you have to force your software into an almost always inappropriate transactional model, and so on. The performance hit is fantastic. There of course are problems for which DBs are well suited, but there are far fewer of them out there than are generally supposed. That's because the makers of the bloatware (you know who they are) strongly promoted the DB-everywhere model, mainly so they could sell more bloatware. Unless your problem is very close to the strengths of a DB, just say no. > 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, because the answer is in the hundreds for many common identifiers. And if not, simple text search gets you the answer. 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. > 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. > For a worldly, commercial case, > Google's non-SQL hash table based "database" is a major > failure for programs using more than indexed lists, as is > demonstrated by 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). Microsoft and others got the world so used to that that no one expects more anymore. DB. Bah-humbug. :-) Randy.