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

[Richard Maher]

On 25/10/2022 8:11 am, Arne Vajhøj wrote:
> 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.

Not with .LIS files. Precompilers make them illegible

> 
> 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.

I heard of Babel having to dumb down Javascript ES6 to ES5

> 
> 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
> 
>