[Info-vax] Userland programming languages on VMS.

[Arne Vajhøj]

On 2/3/2022 12:11 PM, Bill Gunshannon wrote:
> On 2/3/22 10:37, Arne Vajhøj wrote:
>> 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.
> 
> Any shortcomings in string handling in Fortran didn't seem to
> stop it from proving the 41 primitives and 50 utilities in
> STVOS.

There is a big difference between "being able to" and
"being a good choice".

Lines of code required and number of bugs matters.

>> C's with null terminated fixed size char arrays sucks
>> just as much as Fortran fixed length characters.
> 
> Believe it or not, some of us still fail to see why null terminated
> strings are such a problem.

Fixed length strings are inflexible to work with and require more code.

Terminated strings are inefficient as the length need to be calculated
instead of just looked up.

Terminated strings are dangerous as the terminator can be missing.

>                             Time to stop blaming a feature of the
> language for the incompetence of some programmers.

A good language is a language that gives compiler errors instead
of runtime errors.

Arne