[Info-vax] VMS Software: New US Mailing Address

[Arne Vajhøj]

On 10/24/2022 9:15 AM, Bill Gunshannon wrote:
> On 10/23/22 19:05, Arne Vajhøj wrote:
>> On 10/13/2022 9:18 PM, Bill Gunshannon wrote:
>>> On 10/13/22 19:14, Arne Vajhøj wrote:
>>>> MySQL/MariaDB - no pre-compilers
>>>
>>> No one has expressed a need or desire for it yet.  (I have done
>>> some playing with making ESQL work but nothing production level.)
>>> More a MySQL shortcoming than embedded SQL.
>>>
>>>> PostgreSQL - only C (from project itself - an open source Cobol exist)
>>>
>>> And that's the way Open Source works.  If there was a need other
>>> languages would be supported.
>>
>> It is not really open source specific.
>>
>> If there is a demand for something then it will be created.
>> Maybe commercial. Maybe open source.
>>
>> Given that MySQL/MariaDB is #2 in database market share
>> and PostgreSQL is #4 and they are used by by a huge number
>> of developers (magnitude 1 million), then the fact that there
>> are no pre-compilers for MySQL/MariaDB and only two for PostgreSQL
>> is a pretty good indication for very low interest for embedded
>> SQL among developers.
> 
> I think that has more to do with who is using each of these database
> systems than the popularity of Embedded SQL.  Embedded SQL is used
> mostly by COBOL, followed by some Fortran, probably a little PL/I.
> And, mostly mainframes or other large systems (like VMS).  It is
> MySQL/MariaDB that lack popularity in this community, not Embedded SQL.

That sounds very plausible.

The change in programming languages used, the changes in
platforms used and the change in databases used has undoubtedly
contributed heavily to the demise of embedded SQL.

>>> All of this shows a lack of interest in languages that most people
>>> think are dying.  Also in database systems not being used for the
>>> kind of work that Oracle, RDP, DB2 and Postgres are.  I see nothing
>>> here that even hints at embedded SQL going away.
>>
>> The fact that half the widely used databases has no pre-compilers
>> available and the remaining half only has support for typical
>> 2-3 out of maybe 20 languages used for database access shows that
>> for the vast majority (95% magnitude) of projects then embedded
>> SQL is not possible because no pre-compiler exist.
> 
> I think there are other reasons for the lack of pre-compilers.  The API
> for all these Open Source DB's is basically C oriented.  Why would there
> be a pre-compiler for languages for which that is the native API?

Because embedded SQL is actually often shorter and easier to
read than API calls.

And we can also see that those databases with C pre-compilers
also usually have C centric API's: Oracle OCI (and OCCI), DB2 CLI,
PgSQL libpq.

> Python, PHP, Perl, none of these are compiled so what would you
> pre-compile to?

A Cobol pre-compiler compiles to Cobol, so a Python/PHP
pre-compiler would of course compile to Python/PHP.

Since they are not compiled it would probably not be
called pre-compiler, but transpiler.

So: a Python/PHP transpiler would of course transpile
to Python/PHP.

But really same thing.

AFAIK such a thing has never been made.

And for pretty obvious reasons: for languages like Cobol and C
embedded SQL may mean fewer lines than API calls, but for
languages like Python and PHP embedded SQL would likely be
more lines than API calls.

>> And in the remaining few cases then it may be discarded due
>> to uncertainty about the future of the pre-compiler or because
>> the developers do not like it or don't know about it (most developers
>> under age 50 does not know that embedded SQL exist).
> 
> That I agree with but the question really is, why?  It is not that
> Embedded SQL is unpopular but that academia stopped teaching the
> languages most likely to use it even though those languages are
> still extremely common in the industry.

That developers under 50 does not know embedded SQL must have
something to do with educations.

But I think it would be difficult to justify being taught. Too
few would ever use it.

>> Cobol is probably the only language where embedded SQL will be
>> the most common choice for database access. The C/C++ crowd
>> has moved to various standards based or database specific API's.
> 
> As stated above, the databases API's are already targeted at C and
> C++.  What would an Embedded SQL Pre-Compiler convert it to?

C (and C++).

That is what Oracle, DB2 and PgSQL pre-compilers for C do.

Arne