[Info-vax] Userland programming languages on VMS.

[Bill Gunshannon]

On 2/3/22 10:43, Arne Vajhøj wrote:
> On 2/3/2022 10:17 AM, Bill Gunshannon wrote:
>> On 2/3/22 09:21, 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.
>>
>> In what way?  :-)  There are a lot of people in the industry today
>> that feel that C isn't a good choice for anything.
> 
> C with its low level direct access no check to prevent users
> from shooting themselves in the foot approach does make
> sense for some OS kernel stuff and low level RTL stuff.

But Simon was talking about userland, not OS kernel stuff.

> 
> In recent years new languages has arrived that allows for
> limiting the unsafe stuff to explicit specified blocks.
> 
> The:
> 
> // your code is checked
> unsafe {
>      // your code is not checked
> }
> 
> approach.
> 
> And I consider it quite likely that approach will take over from C.
> 
> In the next 25-50 years.   :-)

I won;t be holding my breath.  :-)

> 
>>>>> and I gave an example of where I had seen Fortran used in the
>>>>> distant past while I was still in school and before before C got
>>>>> established outside of Unix.
>>>>
>>>> Ind I have seen Fortran used for this stuff long after C escaped
>>>> into the wild.  There really is no legitimate reason why languages
>>>> Pascal, Modula, Fortran, PL/I, or anything else is unsuitable as
>>>> long as it is available on the system and there is a programmer
>>>> willing to work with it.  After all, in the nd it's all just ones
>>>> and zeroes.
>>>>
>>>
>>> Pascal and the Modula variants offer far more than C. Fortran does not
>>> when it comes to implementing userland tools.
>>
>> Same question.  In what way?  I have already shown how Fortran was
>> used to write an entire userland for the first "POSIX" interface.
>> 41 primitives and 50 utilities.
> > They tend to protect the developers feet a bit.

How does one shoot themselves in the foot with Fortran? :-)

> 
> And most flavors got way better string handling than
> C and Fortran.

And, how much string handling do you need for the average userland
program?

bill