Re: GNAT GPL is not shareware

["Randy Brukardt" <randy@rrsoftware.com>]

"G.B." <bauhaus@futureapps.invalid> 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.