[Info-vax] Userland programming languages on VMS.
Arne Vajhøj
arne at vajhoej.dk
Thu Feb 3 10:37:38 EST 2022
On 2/3/2022 9:21 AM, Simon Clubley wrote:
> On 2022-02-02, Bill Gunshannon <bill.gunshannon at gmail.com> wrote:
>> On 2/2/22 13:21, Simon Clubley wrote:
>>> On 2022-02-01, Paul Hardy <p.g.hardy at btinternet.com> wrote:
>>>> Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>>> ?
>>>>> Fortran and COBOL are not suitable for writing operating system userland tools.
>>>>
>>>> Not that I would encourage it as an implementation language these days, but
>>>> Fortran has been used as such in the past. I believe the Fortran H Extended
>>>> optimising compiler for the IBM 360/370 was written largely in Fortran H
>>>> Extended.
>>>
>>> You are correct about past use. In the context of the discussion,
>>> I meant they are not suitable for writing userland tools _today_
>>
>> Why? Just because there are other languages doesn't obsolete their
>> use for the task. If that were true we never needed anything after
>> C was created. After all the first Open Source compilers for many
>> of the languages in use were just x-to-C translators. P2C, F2C,
>> heck even GNAT was originally just an Ada to C translator. And some
>> are still that way and work just fine. GnuCOBOL for example.
>
> Because C has turned out to be a better choice than Fortran for
> writing userland tools so you would choose C (at a minimum) for
> writing such tools today.
Maybe it would be more correct to say that C is a less bad
choice than Fortran.
A key thing in such tools are string handling.
C's with null terminated fixed size char arrays sucks
just as much as Fortran fixed length characters.
But the standard C string library (string.h) is just more
powerful than what a Fortran compiler comes with.
But most other languages would do better.
Neither C nor Fortran has much protection against
developers shooting themselves in the foot.
Arne
More information about the Info-vax
mailing list