On 2/2/22 13:54, Simon Clubley wrote:
> On 2022-02-01, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> It is a factor, when Simon wants it to be. It is not a factor when Simon does
>> not want it to be.
>>
>> He is also good at partially quoting what someone writes, when he wants to
>> change the message to what he wants to respond to.
>>
>
> No, it means that the Unix developers had a level of insight and
> forward thinking that DEC lacked when the Unix developers chose to
> rewrite Unix in a mostly portable programming language from top to
> bottom long before such ideas became mainstream.
>
> It's a pity that the move to what was essentially a portable version
> of VMS in Pillar 10 years after VMS was created was cancelled. That
> could have _really_ opened up the future use of VMS in the same way
> that the use of a mostly portable language did for Unix.
>

Really? How many systems have Pillar compilers today? Does VMS?

bill

On 2/2/22 14:30, Arne Vajhøj wrote:
> On 2/2/2022 1:41 PM, Simon Clubley wrote:
>> On 2022-02-01, Johnny Billquist <bqt@softjar.se> wrote:
>>> On 2022-02-01 19:28, Simon Clubley wrote:
>>>> On 2022-02-01, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>> On 2/1/2022 9:01 AM, Simon Clubley wrote:
>>>>>> On 2022-01-31, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>>>
>>>>>>> Don't people ever wonder what DEC people were thinking when they
>>>>>>> wrote VMS?
>>>>>>>
>>>>>>
>>>>>> Yes, I do. Then I remember it was written in the 1970s. :-) :-)
>>>>>
>>>>> What does that have to do with anything?
>>>>>
>>>>
>>>> What makes some things about VMS so limiting in the 21st century is
>>>> as a direct result of it being designed in the 1970s instead of it
>>>> being designed around more modern techniques and concepts.
>>>>
>>>> I believe I may have expressed some opinions in this area
>>>> previously. :-)
>>>
>>> This kind of argument always have the same problem that Unix is even
>>> older. Does that mean Unix have an even larger problem?
>>>
>>> Or is this in fact not a factor in there?
>>>
>>
>> No. It means that the Unix creators were _very_ insightful and _very_
>> forward looking in the early 1970s when they rewrote Unix, including
>> the kernel, in a mostly portable language that mostly decoupled the
>> implementation from the architecture it ran on, while most other people
>> still wrote their kernels, and maybe good portions of their userland
>> as well, in assembly language.
>
> The idea of an OS mostly written in a HLL is not invented by Unix.

Primos which predates VMS was written mostly in HLLs. Some pretty
obscure ones, but HLLs just the same. :-)

>
> But I agree that they made the right decision.
>
>> They were also very insightful in that the minimum application
>> programming
>> language they supported was also C. These factors laid the groundwork
>> for the future use of Unix across a large range of architectures and
>> was directly responsible for its rise to the position it gained.
>
> I believe that assembler has always been supported on Unix.
>
> With the traditional Unix C tool chain of compiler driver calling
> preprocessor, actual compiler, assembler and loader then it  is
> not even possible to compile on a system without the assembler.

I don;t think he was saying they had no assembler, they certainly did
and it got used. I have used it myself. And looking at assembler
output from the compiler is often a big help when trying to locate
and fix bugs. He just meant that the OS is not written in assembler.
I would have to go back an look but I am pretty sure even after the
advent of the C based Unix there were still pieces in assembler for
quite some time. I do not believe any of the current BSD's still
have any except maybe 2.11 on the PDP-11.

>
> And null terminated strings are not harder to do in assembler
> than descriptor strings.

Null terminated strings are common in MACRO-11.

>
>> They were a good 10 years earlier with these moves than when these ideas
>> started to become mainstream.
>>
>> DEC OTOH, took the traditional approach for the time and wrote their VMS
>> kernel in an assembly language that was directly tied to the architecture
>
> I believe a good chunk of VMS was not written in Macro-32 but in Bliss.
>
> In hindsight C would have been better than Bliss.
>
> In hindsight more Bliss/C and less Macro-32 would have been good.
>
> But 20/20 hindsight is easy.

Hindsight is always 20/20.

bill

On 2/2/2022 4:34 PM, Bill Gunshannon wrote:
> On 2/2/22 14:30, Arne Vajhøj wrote:
>> On 2/2/2022 1:41 PM, Simon Clubley wrote:
>>> No. It means that the Unix creators were _very_ insightful and _very_
>>> forward looking in the early 1970s when they rewrote Unix, including
>>> the kernel, in a mostly portable language that mostly decoupled the
>>> implementation from the architecture it ran on, while most other people
>>> still wrote their kernels, and maybe good portions of their userland
>>> as well, in assembly language.
>>
>> The idea of an OS mostly written in a HLL is not invented by Unix.
>
> Primos which predates VMS was written mostly in HLLs. Some pretty
> obscure ones, but HLLs just the same.  :-)

And Multics predates Unix.

>> But I agree that they made the right decision.
>>
>>> They were also very insightful in that the minimum application
>>> programming
>>> language they supported was also C. These factors laid the groundwork
>>> for the future use of Unix across a large range of architectures and
>>> was directly responsible for its rise to the position it gained.
>>
>> I believe that assembler has always been supported on Unix.
>>
>> With the traditional Unix C tool chain of compiler driver calling
>> preprocessor, actual compiler, assembler and loader then it  is
>> not even possible to compile on a system without the assembler.
>
> I don;t think he was saying they had no assembler, they certainly did
> and it got used.  I have used it myself.  And looking at assembler
> output from the compiler is often a big help when trying to locate
> and fix bugs.  He just meant that the OS is not written in assembler.

That is how you read:

"the minimum application programming language they supported was also C"

?

> I would have to go back an look but I am pretty sure even after the
> advent of the C based Unix there were still pieces in assembler for
> quite some time.  I do not believe any of the current BSD's still
> have any except maybe 2.11 on the PDP-11.

I would have thought any OS needed a few assembler code files
or some C code files with ASM directives or some C code with
system specific pseudo functions mapping to native
instructions. To get some of really HW specific stuff done.

Arne

On 2022-02-02, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 2/2/2022 4:34 PM, Bill Gunshannon wrote:
>> On 2/2/22 14:30, Arne Vajhøj wrote:
>>> On 2/2/2022 1:41 PM, Simon Clubley wrote:
>>>> They were also very insightful in that the minimum application
>>>> programming
>>>> language they supported was also C. These factors laid the groundwork
>>>> for the future use of Unix across a large range of architectures and
>>>> was directly responsible for its rise to the position it gained.
>>>
>>> I believe that assembler has always been supported on Unix.
>>>
>>> With the traditional Unix C tool chain of compiler driver calling
>>> preprocessor, actual compiler, assembler and loader then it  is
>>> not even possible to compile on a system without the assembler.
>>
>> I don;t think he was saying they had no assembler, they certainly did
>> and it got used.  I have used it myself.  And looking at assembler
>> output from the compiler is often a big help when trying to locate
>> and fix bugs.  He just meant that the OS is not written in assembler.

That's right. The backend of the compiler gets given the IR code from
the front end after the front end parsed the user's source code and it
doesn't care what the code itself is doing or what part of the OS the
source code is interacting with.

The assembly language here is only a step along the way of creating the
final object code for the linker to use and is something that's private
to the compiler toolchain.

And yes Bill, you are correct in that the assembly language can be useful
in finding bugs, including compiler bugs. There's an Ada AI that's a direct
result of me looking at such code.

IOW, the assembly language is generated by the compiler and has absolutely
no meaning to the operating system itself.

>
> That is how you read:
>
> "the minimum application programming language they supported was also C"
>
> ?
>

That's exactly how you should read it Arne.

In VMS, I can point you to the operating supplied headers that allow
application programs to be written in Macro-32 and call VMS system
services, including all the structure definitions. That makes Macro-32
a supported language for application programming (unfortunately).

In Linux, there are no such headers because assembly language is not
a supported application programming language. (And /usr/include/asm/
is _NOT_ about writing application programs in assembly language. :-) )

>> I would have to go back an look but I am pretty sure even after the
>> advent of the C based Unix there were still pieces in assembler for
>> quite some time.  I do not believe any of the current BSD's still
>> have any except maybe 2.11 on the PDP-11.
>
> I would have thought any OS needed a few assembler code files
> or some C code files with ASM directives or some C code with
> system specific pseudo functions mapping to native
> instructions. To get some of really HW specific stuff done.
>

That's for extremely low-level stuff such as initial boot code or
interrupt dispatch code that dispatches to a C language interrupt
handler. Even when working on kernel code, most people never even
go anywhere near such code.

About the only time you would see assembly language in application
programs is as tiny inline fragments called from a HLL if you needed
direct access to a specific specialist CPU register (for example)
and then you (and not the OS) are responsible for that assembly language.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-02-02, Johnny Billquist <bqt@softjar.se> wrote:
>
> You said above:
> "What makes some things about VMS so limiting in the 21st century is
> as a direct result of it being designed in the 1970s instead of it
> being designed around more modern techniques and concepts."
>
> The implementation language have pretty much nothing to do with the design.
>
> Maybe what you actually meant is that the problem with VMS was that the
> implementation was done in a very 70s non-portable way?
>

That could be a far better way of expressing this, especially when
compared to how forward looking the Unix designers were during the
same time frame. Thank you Johnny.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-02-02, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 2/2/22 13:21, Simon Clubley wrote:
>> On 2022-02-01, Paul Hardy <p.g.hardy@btinternet.com> wrote:
>>> Simon Clubley <clubley@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.

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

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-02-02, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 2/2/22 13:54, Simon Clubley wrote:
>> On 2022-02-01, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> It is a factor, when Simon wants it to be. It is not a factor when Simon does
>>> not want it to be.
>>>
>>> He is also good at partially quoting what someone writes, when he wants to
>>> change the message to what he wants to respond to.
>>>
>>
>> No, it means that the Unix developers had a level of insight and
>> forward thinking that DEC lacked when the Unix developers chose to
>> rewrite Unix in a mostly portable programming language from top to
>> bottom long before such ideas became mainstream.
>>
>> It's a pity that the move to what was essentially a portable version
>> of VMS in Pillar 10 years after VMS was created was cancelled. That
>> could have _really_ opened up the future use of VMS in the same way
>> that the use of a mostly portable language did for Unix.
>>
>
> Really? How many systems have Pillar compilers today? Does VMS?
>

Exactly zero systems have Pillar compilers today. Unfortunately.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2/3/22 09:21, Simon Clubley wrote:
> On 2022-02-02, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 2/2/22 13:21, Simon Clubley wrote:
>>> On 2022-02-01, Paul Hardy <p.g.hardy@btinternet.com> wrote:
>>>> Simon Clubley <clubley@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.

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

bill

On 2/3/2022 9:21 AM, Simon Clubley wrote:
> On 2022-02-02, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 2/2/22 13:21, Simon Clubley wrote:
>>> On 2022-02-01, Paul Hardy <p.g.hardy@btinternet.com> wrote:
>>>> Simon Clubley <clubley@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

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@gmail.com> wrote:
>>> On 2/2/22 13:21, Simon Clubley wrote:
>>>> On 2022-02-01, Paul Hardy <p.g.hardy@btinternet.com> wrote:
>>>>> Simon Clubley <clubley@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.

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

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

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

Arne

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@gmail.com> wrote:
>>>> On 2/2/22 13:21, Simon Clubley wrote:
>>>>> On 2022-02-01, Paul Hardy <p.g.hardy@btinternet.com> wrote:
>>>>>> Simon Clubley <clubley@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

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@gmail.com> wrote:
>>> On 2/2/22 13:21, Simon Clubley wrote:
>>>> On 2022-02-01, Paul Hardy <p.g.hardy@btinternet.com> wrote:
>>>>> Simon Clubley <clubley@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.

>
> 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. Time to stop blaming a feature of the
language for the incompetence of some programmers.

>
> But the standard C string library (string.h) is just more
> powerful than what a Fortran compiler comes with.

Maybe, but it doesn't stop you from doing userland in Fortran,
Pascal or any other language.

>
> But most other languages would do better.

Maybe.

>
> Neither C nor Fortran has much protection against
> developers shooting themselves in the foot.

I am still waiting to hear how one shoots one's self in the foot
writing userland utilities in Fortran.

bill

On 2/3/2022 12:11 PM, Bill Gunshannon wrote:

> Believe it or not, some of us still fail to see why null terminated
> strings are such a problem. Time to stop blaming a feature of the
> language for the incompetence of some programmers.

For one thing, it prevents a character value of zero in a string.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2/3/22 12:48, Dave Froble wrote:
> On 2/3/2022 12:11 PM, Bill Gunshannon wrote:
>
>> Believe it or not, some of us still fail to see why null terminated
>> strings are such a problem.  Time to stop blaming a feature of the
>> language for the incompetence of some programmers.
>
> For one thing, it prevents a character value of zero in a string.
>
>

And, in my 50 years of doing this stuff I have never run into a case
where that was a problem. Go figure.

bill

On 2022-02-03, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 2/3/22 09:21, Simon Clubley wrote:
>>
>> 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.
>

There's a reason I keep referring to C as the _minimum_ acceptable
option, not the maximum acceptable option. :-)

As for those people, they need to find a language that is implemented
as widely as C is, so that implementing something in that other language
becomes an asset and not a liability.

If I had my way, everything would be written in Ada, but unfortunately,
that's not a viable option in today's world.

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

In the case of Pascal and the Modula variants, that's easy.
Both of those options have strong type-safe and data manipulation
attributes and end up producing more robust code in general.

BTW, sort-of related to this, does anyone else wish C was a module
based language ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-02-03, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 2/3/22 10:43, Arne Vajhøj wrote:
>>
>> 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.
>

The RTL stuff is also in userland as well. For example, libc is not
part of the kernel (at least on the Unix variants I am aware of).

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

Those people need to make sure those languages are not write-only
languages when doing this. Here is flashing an LED in various programming
languages and the Rust one is rather interesting.

https://www.raspberrypi.com/news/multilingual-blink-for-raspberry-pi-pico/

The Rust one is doing explicit setup of the clocks and PLLs by calling
a library whereas the other ones leave it implicitly to the libraries
they are using, but what you should be looking at is the general "feel"
of the various languages and especially the Rust one.

I can tell you that my bare metal clock/PLL setup code is way more readable
than that, even when I am doing the whole thing myself without the help
of a library. :-)

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

For starters, everytime you do something related to parsing, a lot.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-02-03, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 2/3/2022 9:21 AM, Simon Clubley wrote:
>>
>> 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.
>

As just mentioned, there's a reason I call C the _minimum_ acceptable
option and not the maximum acceptable option. :-)

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

Agreed. But unfortunately, people tend to be forced towards C simply
because it's the only language that has universal coverage across
architectures and operating systems, including when operating in
kernel mode. It's also a language that's easy to call from other
languages as well so it's easy to call libraries written in C as well.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-02-03, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 2/3/22 10:37, Arne Vajhøj wrote:
>>
>> 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.
>

You can write a full-blown parser in Macro-32 if you really want to.

It doesn't mean that any sane person would want to do that when there
are better languages available. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2/3/22 13:43, Simon Clubley wrote:
> On 2022-02-03, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 2/3/22 09:21, Simon Clubley wrote:
>>>
>>> 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.
>>
>
> There's a reason I keep referring to C as the _minimum_ acceptable
> option, not the maximum acceptable option. :-)
>
> As for those people, they need to find a language that is implemented
> as widely as C is, so that implementing something in that other language
> becomes an asset and not a liability.
>
> If I had my way, everything would be written in Ada, but unfortunately,
> that's not a viable option in today's world.

There are reasons why Ada didn't become the success story people
originally thought it would.

>
>>>
>>> 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.
>>
>
> In the case of Pascal and the Modula variants, that's easy.
> Both of those options have strong type-safe and data manipulation
> attributes and end up producing more robust code in general.

Fortran is just as strongly typed. And what isn't robust about code
compiled from Fortran?

>
> BTW, sort-of related to this, does anyone else wish C was a module
> based language ?
>

Why did you take both of these conversations back to C?
In both of the above segments we were talking about the supposed
unsuitability of Fortran for writing userland applications.

bill

On 2/3/22 14:03, Simon Clubley wrote:
> On 2022-02-03, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 2/3/22 10:43, Arne Vajhøj wrote:
>>>
>>> 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.
>>
>
> The RTL stuff is also in userland as well. For example, libc is not
> part of the kernel (at least on the Unix variants I am aware of).
>
>>>
>>> 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. :-)
>>
>
> Those people need to make sure those languages are not write-only
> languages when doing this. Here is flashing an LED in various programming
> languages and the Rust one is rather interesting.
>
> https://www.raspberrypi.com/news/multilingual-blink-for-raspberry-pi-pico/
>
> The Rust one is doing explicit setup of the clocks and PLLs by calling
> a library whereas the other ones leave it implicitly to the libraries
> they are using, but what you should be looking at is the general "feel"
> of the various languages and especially the Rust one.
>
> I can tell you that my bare metal clock/PLL setup code is way more readable
> than that, even when I am doing the whole thing myself without the help
> of a library. :-)
>
>>>
>>> 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?
>>
>
> For starters, everytime you do something related to parsing, a lot.
>

And yet, the people working with STVOS didn't seem to have the problems
you are having. I guess because no one told them it was impossible
they just went ahead and did it.

bill

On 2/3/2022 2:20 PM, Bill Gunshannon wrote:
> On 2/3/22 13:43, Simon Clubley wrote:
>> On 2022-02-03, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>> On 2/3/22 09:21, Simon Clubley wrote:
>>>> 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.
>>>
>>
>> In the case of Pascal and the Modula variants, that's easy.
>> Both of those options have strong type-safe and data manipulation
>> attributes and end up producing more robust code in general.
>
> Fortran is just as strongly typed.
No it is not.

There is no argument type check between caller and called
in Fortran.

Arne

On 2/3/2022 1:43 PM, Simon Clubley wrote:
> BTW, sort-of related to this, does anyone else wish C was a module
> based language ?

I think those that need it use C as is + convention for source code
to achieve the same thing.

Arne

On 2/3/2022 12:04 PM, Bill Gunshannon wrote:
> On 2/3/22 10:43, Arne Vajhøj wrote:
>> On 2/3/2022 10:17 AM, Bill Gunshannon wrote:
>>>> 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? :-)

Call a subroutine/function with the wrong type of argument.

Use invalid character index.

Use invalid array index.

Have different declaration of same common block.

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

A lot.

They mess around with arguments, environment variables, filenames,
frequently do text io, occasionally does serious parsing.

Arne

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@gmail.com> wrote:
>>>> On 2/2/22 13:21, Simon Clubley wrote:
>>>>> On 2022-02-01, Paul Hardy <p.g.hardy@btinternet.com> wrote:
>>>>>> Simon Clubley <clubley@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

In article <sth9l2$7p8$4@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2022-02-03, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 2/3/22 10:37, Arne Vajh�j wrote:
>>>
>>> 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.
>>
>
>You can write a full-blown parser in Macro-32 if you really want to.

I call LIB$T(ABLE_)PARSE. I have a state table in my DCL debugger with over
800 lines to parse escape sequences. That's not counting the action routines.
I couldn't imagine doing it with that strtok() thang.

>It doesn't mean that any sane person would want to do that when there
>are better languages available. :-)

SCAN? :P

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.