On 1/28/2022 3:44 PM, Bill Gunshannon wrote:
> On 1/28/22 14:46, Arne Vajhøj wrote:
>> On 1/28/2022 12:37 PM, John Reagan wrote:
>>> On Friday, January 28, 2022 at 8:51:57 AM UTC-5, Arne Vajhøj wrote:
>>>> On 1/28/2022 4:06 AM, cao...@pitbulluk.org wrote:
>>>>> On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
>>>>>>> Which I do not consider exotic.
>>>>>> Sure, fine, but look at the results from the current blend of (what
>>>>>> are, I assume) defaults. Whether or not better results are so "easy",
>>>>>> the existing situation (mess) is the existing situation (mess).
>>>>>>
>>>>>> As I said, "unrealistic". That was an inference, not a postulate.
>>>>>
>>>>> Aren't C/C++ the only VMS languages capable of using the full 64 bit
>>>>> address space?
>>>>> Perhaps some others are (partially) capable but it doesn't look at all
>>>>> convenient.
>>>>> Pascal has IADDRESS64 in addition to IADDRESS but why bother to call a _64
>>>>> system service when you can't really do much else with it?
>>>> I believe Fortran supports usage of P2 space.
>>>>
>>> Fortran lets you allocate COMMON in P2 and it has the CDEC$ POINTER64 (or
>>> however it is spelled)
>>> attribute. You can have "top level" 64-bit pointers but you can't get
>>> 64-bit pointers as fields in a structure.
>>
>> Real Fortran programmer does not use pointers.
>>
>> :-)
>>
>> Example with common:
>>
>> $ type f64.for
>> program f64
>> implicit none
>> real*8 x(10),y(10)
>> common /cx/x
>> !DEC$ATTRIBUTES ADDRESS64::cy
>> common /cy/y
>> write(*,'(1x,z16.16)') %loc(x)
>> write(*,'(1x,z16.16)') %loc(y)
>> end
>> $ for f64
>> $ link f64
>> $ run f64
>> 0000000000040000
>> 0000000080000000
>>
>
> I ran that thru every FORTRAN compiler I had. Sorry, it's not
> FORTRAN.
>
> bill
>
>

Your problem is that you don't have the correct FORTRAN compiler.

That code is ArneFortran ...

--
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 1/28/2022 2:14 PM, Simon Clubley wrote:
> On 2022-01-27, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <ssurv4$nm1$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>> On a more serious note, what would be an acceptable programming language
>>> for userland tools which need to be shipped as part of the operating system ?
>>>
>>> Let's look at the language options for creating a new userland level
>>> tool on VMS today:
>>>
>>> Macro-32 and BLISS are absolutely unsuitable for obvious reasons.

Simon, you're rather good at assuming that you are always correct. But that is
an opinion, everyone is entitled to one, and we do not all have to agree.

>> What *obvious* reasons?
>>
>
> 1) No type safety (even C has _some_ type safety but not as much as say
> Pascal, Ada, or the Wirth languages in general),

You like "type safety", and I will not argue against it. But not having type
safety does not guarantee mistakes.

> 2) ability to make more really silly mistakes that the compiler will not
> catch because it doesn't have enough information to tell you,

I like the computer to do the grunt work. But not doing so does not mean
"unsuitable".

> 3) vast amount of effort to do anything significant compared with the amount
> of effort required even in C to do the same thing,
>
> 4) lack of people who understand the languages when changes are required.

Now, that is an issue. I used to muddle through Macro-32, but, after a lengthy
period of not using it, I have discovered that I'm now not competent to do so.
(Just like I find myself spell checking every other word.)

> BLISS, and especially Macro-32, belong in the past for any brand new
> programs (as opposed to maintaining existing ones)

Bliss was developed for writing system level code. Why has it all of a sudden
become unsuitable? I will admit that it isn't so well known.

> The absolute minimum standard for any new applications these days is C.
> (And yes, that's a _minimum_ standard. :-))

King Simon speaks, we all must obey. Or, we dump him, like we dumped King Donald.

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

Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 1/28/22 14:46, Arne Vajh?j wrote:
>> On 1/28/2022 12:37 PM, John Reagan wrote:
>>> On Friday, January 28, 2022 at 8:51:57 AM UTC-5, Arne Vajh?j wrote:
>>>> On 1/28/2022 4:06 AM, cao...@pitbulluk.org wrote:
>>>>> On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
>>>>>>> Which I do not consider exotic.
>>>>>> Sure, fine, but look at the results from the current blend of (what
>>>>>> are, I assume) defaults. Whether or not better results are so "easy",
>>>>>> the existing situation (mess) is the existing situation (mess).
>>>>>>
>>>>>> As I said, "unrealistic". That was an inference, not a postulate.
>>>>>
>>>>> Aren't C/C++ the only VMS languages capable of using the full 64 bit
>>>>> address space?
>>>>> Perhaps some others are (partially) capable but it doesn't look at
>>>>> all convenient.
>>>>> Pascal has IADDRESS64 in addition to IADDRESS but why bother to call
>>>>> a _64 system service when you can't really do much else with it?
>>>> I believe Fortran supports usage of P2 space.
>>>>
>>> Fortran lets you allocate COMMON in P2 and it has the CDEC$ POINTER64
>>> (or however it is spelled)
>>> attribute.?? You can have "top level" 64-bit pointers but you can't
>>> get 64-bit pointers as fields in a structure.
>>
>> Real Fortran programmer does not use pointers.
>>
>> :-)
>>
>> Example with common:
>>
>> $ type f64.for
>> ????? program f64
>> ????? implicit none
>> ????? real*8 x(10),y(10)
>> ????? common /cx/x
>> ????? !DEC$ATTRIBUTES ADDRESS64::cy
>> ????? common /cy/y
>> ????? write(*,'(1x,z16.16)') %loc(x)
>> ????? write(*,'(1x,z16.16)') %loc(y)
>> ????? end
>> $ for f64
>> $ link f64
>> $ run f64
>> 0000000000040000
>> 0000000080000000
>>
>
> I ran that thru every FORTRAN compiler I had. Sorry, it's not
> FORTRAN.

Works on Eisner.

$ show sys/noproc
OpenVMS V8.4-2L2 on node EISNER 29-JAN-2022 [...]

Here's the memory layout synopsis from a linker map:

Virtual memory allocated: 00010000 0005FFFF 00050000 (327680. bytes, 640. pages)
64-Bit Virtual memory allocated: 00000000 00000000 00000000
80000000 80010000 00010000 (65536. bytes, 128. pages)

The example, though, shows too small an allocation to escape 32 bit address space.

George

On 1/29/22 01:53, George Cornelius wrote:
> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 1/28/22 14:46, Arne Vajh?j wrote:
>>> On 1/28/2022 12:37 PM, John Reagan wrote:
>>>> On Friday, January 28, 2022 at 8:51:57 AM UTC-5, Arne Vajh?j wrote:
>>>>> On 1/28/2022 4:06 AM, cao...@pitbulluk.org wrote:
>>>>>> On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
>>>>>>>> Which I do not consider exotic.
>>>>>>> Sure, fine, but look at the results from the current blend of (what
>>>>>>> are, I assume) defaults. Whether or not better results are so "easy",
>>>>>>> the existing situation (mess) is the existing situation (mess).
>>>>>>>
>>>>>>> As I said, "unrealistic". That was an inference, not a postulate.
>>>>>>
>>>>>> Aren't C/C++ the only VMS languages capable of using the full 64 bit
>>>>>> address space?
>>>>>> Perhaps some others are (partially) capable but it doesn't look at
>>>>>> all convenient.
>>>>>> Pascal has IADDRESS64 in addition to IADDRESS but why bother to call
>>>>>> a _64 system service when you can't really do much else with it?
>>>>> I believe Fortran supports usage of P2 space.
>>>>>
>>>> Fortran lets you allocate COMMON in P2 and it has the CDEC$ POINTER64
>>>> (or however it is spelled)
>>>> attribute.?? You can have "top level" 64-bit pointers but you can't
>>>> get 64-bit pointers as fields in a structure.
>>>
>>> Real Fortran programmer does not use pointers.
>>>
>>> :-)
>>>
>>> Example with common:
>>>
>>> $ type f64.for
>>> ????? program f64
>>> ????? implicit none
>>> ????? real*8 x(10),y(10)
>>> ????? common /cx/x
>>> ????? !DEC$ATTRIBUTES ADDRESS64::cy
>>> ????? common /cy/y
>>> ????? write(*,'(1x,z16.16)') %loc(x)
>>> ????? write(*,'(1x,z16.16)') %loc(y)
>>> ????? end
>>> $ for f64
>>> $ link f64
>>> $ run f64
>>> 0000000000040000
>>> 0000000080000000
>>>
>>
>> I ran that thru every FORTRAN compiler I had. Sorry, it's not
>> FORTRAN.
>
> Works on Eisner.
>
> $ show sys/noproc
> OpenVMS V8.4-2L2 on node EISNER 29-JAN-2022 [...]
>
> Here's the memory layout synopsis from a linker map:
>
> Virtual memory allocated: 00010000 0005FFFF 00050000 (327680. bytes, 640. pages)
> 64-Bit Virtual memory allocated: 00000000 00000000 00000000
> 80000000 80010000 00010000 (65536. bytes, 128. pages)
>
> The example, though, shows too small an allocation to escape 32 bit address space.
>

Just because a non-Fortran compiler accepts it doesn't make it Fortran.

bill

Chris Townley <news@cct-net.co.uk> wrote:
>
>Where it was was nothing to do with using a high level language - for
>example I found a purge program on a large file that took nearly 3
>hours. It read the whole file sequentially, with a lock, to delete about
>10% of the records. I changed it to read without a lock, only getting a
>lock if we needed to delete. Dropped to 10 or 15 minutes. No assembly
>coded needed

"A penny's worth of better algorithm is worth a million dollars in
faster hardware." -- gus baird

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 1/29/2022 1:53 AM, George Cornelius wrote:
> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 1/28/22 14:46, Arne Vajh?j wrote:
>>> On 1/28/2022 12:37 PM, John Reagan wrote:
>>>> On Friday, January 28, 2022 at 8:51:57 AM UTC-5, Arne Vajh?j wrote:
>>>>> On 1/28/2022 4:06 AM, cao...@pitbulluk.org wrote:
>>>>>> On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
>>>>>>>> Which I do not consider exotic.
>>>>>>> Sure, fine, but look at the results from the current blend of (what
>>>>>>> are, I assume) defaults. Whether or not better results are so "easy",
>>>>>>> the existing situation (mess) is the existing situation (mess).
>>>>>>>
>>>>>>> As I said, "unrealistic". That was an inference, not a postulate.
>>>>>>
>>>>>> Aren't C/C++ the only VMS languages capable of using the full 64 bit
>>>>>> address space?
>>>>>> Perhaps some others are (partially) capable but it doesn't look at
>>>>>> all convenient.
>>>>>> Pascal has IADDRESS64 in addition to IADDRESS but why bother to call
>>>>>> a _64 system service when you can't really do much else with it?
>>>>> I believe Fortran supports usage of P2 space.
>>>>>
>>>> Fortran lets you allocate COMMON in P2 and it has the CDEC$ POINTER64
>>>> (or however it is spelled)
>>>> attribute.?? You can have "top level" 64-bit pointers but you can't
>>>> get 64-bit pointers as fields in a structure.
>>>
>>> Real Fortran programmer does not use pointers.
>>>
>>> :-)
>>>
>>> Example with common:
>>>
>>> $ type f64.for
>>> ????? program f64
>>> ????? implicit none
>>> ????? real*8 x(10),y(10)
>>> ????? common /cx/x
>>> ????? !DEC$ATTRIBUTES ADDRESS64::cy
>>> ????? common /cy/y
>>> ????? write(*,'(1x,z16.16)') %loc(x)
>>> ????? write(*,'(1x,z16.16)') %loc(y)
>>> ????? end
>>> $ for f64
>>> $ link f64
>>> $ run f64
>>> 0000000000040000
>>> 0000000080000000
>>>
>>
>> I ran that thru every FORTRAN compiler I had. Sorry, it's not
>> FORTRAN.
>
> Works on Eisner.
>
> $ show sys/noproc
> OpenVMS V8.4-2L2 on node EISNER 29-JAN-2022 [...]
>
> Here's the memory layout synopsis from a linker map:
>
> Virtual memory allocated: 00010000 0005FFFF 00050000 (327680. bytes, 640. pages)
> 64-Bit Virtual memory allocated: 00000000 00000000 00000000
> 80000000 80010000 00010000 (65536. bytes, 128. pages)
>
> The example, though, shows too small an allocation to escape 32 bit address space.

I consider 0000000080000000 to be 64 bit space.

0000000000000000 - 000000007FFFFFFF is P0 and P1 space
FFFFFFFF80000000 - FFFFFFFFFFFFFFFF is S0 and S1 space
0000000080000000 and upward is P2 space

Arne

On 1/29/2022 12:11 AM, Dave Froble wrote:
> On 1/28/2022 2:14 PM, Simon Clubley wrote:
>> BLISS, and especially Macro-32, belong in the past for any brand new
>> programs (as opposed to maintaining existing ones)
>
> Bliss was developed for writing system level code.  Why has it all of a
> sudden become unsuitable?  I will admit that it isn't so well known.

Bliss does today what it did 40 years ago.

But the world has changed in those 40 years.

The code bases has increased in size. An OS is probably 10
times as many lines of code as it would have been 40 years ago.
Unless higher productivity languages and tools are introduced
that means more than 10 times as expensive.

Hardware for money has increase dramatically. Probably like
a factor 10000. An extra instruction here and there and a few
extra bytes here and there cost very little.

New languages and tools has shown up. C is far from new. But C++
and Rust are newer than Bliss.

So even if Bliss works the same today as it did 40 years ago,
then it can still have been the right choice 40 years ago and the
wrong choice today.

Arne

On 1/29/2022 8:23 AM, Bill Gunshannon wrote:
> On 1/29/22 01:53, George Cornelius wrote:
>> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>> On 1/28/22 14:46, Arne Vajh?j wrote:
>>>> On 1/28/2022 12:37 PM, John Reagan wrote:
>>>>> On Friday, January 28, 2022 at 8:51:57 AM UTC-5, Arne Vajh?j wrote:
>>>>>> On 1/28/2022 4:06 AM, cao...@pitbulluk.org wrote:
>>>>>>> On Friday, January 28, 2022 at 6:29:10 AM UTC, Steven Schweda wrote:
>>>>>>>>> Which I do not consider exotic.
>>>>>>>> Sure, fine, but look at the results from the current blend of (what
>>>>>>>> are, I assume) defaults. Whether or not better results are so "easy",
>>>>>>>> the existing situation (mess) is the existing situation (mess).
>>>>>>>>
>>>>>>>> As I said, "unrealistic". That was an inference, not a postulate.
>>>>>>>
>>>>>>> Aren't C/C++ the only VMS languages capable of using the full 64 bit
>>>>>>> address space?
>>>>>>> Perhaps some others are (partially) capable but it doesn't look at
>>>>>>> all convenient.
>>>>>>> Pascal has IADDRESS64 in addition to IADDRESS but why bother to call
>>>>>>> a _64 system service when you can't really do much else with it?
>>>>>> I believe Fortran supports usage of P2 space.
>>>>>>
>>>>> Fortran lets you allocate COMMON in P2 and it has the CDEC$ POINTER64
>>>>> (or however it is spelled)
>>>>> attribute.?? You can have "top level" 64-bit pointers but you can't
>>>>> get 64-bit pointers as fields in a structure.
>>>>
>>>> Real Fortran programmer does not use pointers.
>>>>
>>>> :-)
>>>>
>>>> Example with common:
>>>>
>>>> $ type f64.for
>>>> ????? program f64
>>>> ????? implicit none
>>>> ????? real*8 x(10),y(10)
>>>> ????? common /cx/x
>>>> ????? !DEC$ATTRIBUTES ADDRESS64::cy
>>>> ????? common /cy/y
>>>> ????? write(*,'(1x,z16.16)') %loc(x)
>>>> ????? write(*,'(1x,z16.16)') %loc(y)
>>>> ????? end
>>>> $ for f64
>>>> $ link f64
>>>> $ run f64
>>>> 0000000000040000
>>>> 0000000080000000
>>>>
>>>
>>> I ran that thru every FORTRAN compiler I had. Sorry, it's not
>>> FORTRAN.
>>
>> Works on Eisner.
>>
>> $ show sys/noproc
>> OpenVMS V8.4-2L2 on node EISNER 29-JAN-2022 [...]
>>
>> Here's the memory layout synopsis from a linker map:
>>
>> Virtual memory allocated: 00010000 0005FFFF 00050000
>> (327680. bytes, 640. pages)
>> 64-Bit Virtual memory allocated: 00000000 00000000 00000000
>> 80000000 80010000 00010000
>> (65536. bytes, 128. pages)
>>
>> The example, though, shows too small an allocation to escape 32 bit address
>> space.
>>
>
> Just because a non-Fortran compiler accepts it doesn't make it Fortran.
>
> bill
>

"non-Fortran compiler" ???????????????????
- Oh, no, Simon has been cloned. We are doomed!

:-)

--
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 1/29/2022 12:09 PM, Arne Vajhøj wrote:
> On 1/29/2022 12:11 AM, Dave Froble wrote:
>> On 1/28/2022 2:14 PM, Simon Clubley wrote:
>>> BLISS, and especially Macro-32, belong in the past for any brand new
>>> programs (as opposed to maintaining existing ones)
>>
>> Bliss was developed for writing system level code. Why has it all of a sudden
>> become unsuitable? I will admit that it isn't so well known.
>
> Bliss does today what it did 40 years ago.
>
> But the world has changed in those 40 years.

I thought we were still working with ones and zeros. Has that changed when I
wasn't looking?

> The code bases has increased in size. An OS is probably 10
> times as many lines of code as it would have been 40 years ago.
> Unless higher productivity languages and tools are introduced
> that means more than 10 times as expensive.

Just because there is bloatware doesn't make it better. Perhaps worse?

> Hardware for money has increase dramatically. Probably like
> a factor 10000. An extra instruction here and there and a few
> extra bytes here and there cost very little.

Not sure where you're going with that. Doesn't sound relevant.

> New languages and tools has shown up. C is far from new. But C++
> and Rust are newer than Bliss.

Yet C has widespread use, as far an I've been informed.

> So even if Bliss works the same today as it did 40 years ago,
> then it can still have been the right choice 40 years ago and the
> wrong choice today.

You haven't made that case. None of the above addresses the issue. Just a
bunch of handwaving.

I have never used Bliss, don't know it at all. So I cannot be the judge of it's
worthiness. But all I seem to read is "it's old" and "nobody known it".
Neither of those actually addresses it's suitability.

--
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 1/29/2022 1:12 PM, Dave Froble wrote:
> On 1/29/2022 12:09 PM, Arne Vajhøj wrote:
>> On 1/29/2022 12:11 AM, Dave Froble wrote:
>>> On 1/28/2022 2:14 PM, Simon Clubley wrote:
>>>> BLISS, and especially Macro-32, belong in the past for any brand new
>>>> programs (as opposed to maintaining existing ones)
>>>
>>> Bliss was developed for writing system level code.  Why has it all of
>>> a sudden
>>> become unsuitable?  I will admit that it isn't so well known.
>>
>> Bliss does today what it did 40 years ago.
>>
>> But the world has changed in those 40 years.
>
> I thought we were still working with ones and zeros.  Has that changed
> when I wasn't looking?

No and yes.

The HW still operates on ones and zeroes. But developers are usually far
away from that level.

>> The code bases has increased in size. An OS is probably 10
>> times as many lines of code as it would have been 40 years ago.
>> Unless higher productivity languages and tools are introduced
>> that means more than 10 times as expensive.
>
> Just because there is bloatware doesn't make it better.  Perhaps worse?

The fact is that code bases are increasing in size.

And saying that they should not does not to prevent development cost
increases.

>> Hardware for money has increase dramatically. Probably like
>> a factor 10000. An extra instruction here and there and a few
>> extra bytes here and there cost very little.
>
> Not sure where you're going with that.  Doesn't sound relevant.
>
>> New languages and tools has shown up. C is far from new. But C++
>> and Rust are newer than Bliss.
>
> Yet C has widespread use, as far an I've been informed.
>
>> So even if Bliss works the same today as it did 40 years ago,
>> then it can still have been the right choice 40 years ago and the
>> wrong choice today.
>
> You haven't made that case.  None of the above addresses the issue.

I think it does.

* larger code bases => need for a higher level language to prevent cost
from exploding
* more capable hardware => less need for low level language to save
instructions and bytes
* newer high level languages has been introduces

Explains why old low level languages is being replaced by newer
high level languages.

Arne

On 1/29/2022 2:53 PM, John Dallman wrote:
> In article <st401o$jaa$1@dont-email.me>, davef@tsoft-inc.com (Dave Froble)
> wrote:
>> I have never used Bliss, don't know it at all. So I cannot be the
>> judge of its worthiness. But all I seem to read is "it's old"
>> and "nobody knows it". Neither of those actually addresses its
>> suitability.
>
> I've done several assembly languages, BCPL and lots of C. I read the
> Bliss manual last year, and posted about it in March 2021.
>
> It is a language from the era when all programming was assumed to be hard,
> requiring detailed design documents, and painstaking specification of
> every data structure. This was entirely appropriate for a time when a
> mainframe's memory was measured in small numbers of megabytes. However,
> the hardware has changed. Packing data into every spare bit is rarely
> worthwhile. Using some of the computer's resources to make programming
> easier is usually desirable. Bliss is certainly better than assembler,
> but it assumes resources are scarce.
>
> The language seems unforgiving. An extra or missing "." or ";" can change
> the meaning of code in important ways. It's quite hard for a compiler to
> detect programming errors, more so than with C. Training programmers to
> be productive with Bliss looks as if it will take longer than teaching
> them appropriate C idioms for low-level programming, and will certainly
> produce more complaints.
>
> I don't know if equally skilled C or Bliss programmers would be more
> productive writing OS kernel code. I suspect it would depend on who had
> the better set of library routines and other project-specific tools. But
> if I had to put a team together for such work, I'd always choose C over
> Bliss. Doing the same makes sense for VSI, because they /are not DEC/.
> They don't have large pools of programmers to call on. They need to be
> able to hire people and have them become productive reasonably quickly.

Note that for the task that triggered this thread (DIRECTORY command)
which consist of:
- retrieving parameter and qualifiers
- get info via RMS calls
- output result
then something even higher level than C would make sense. There is no
need for any of the "flexibility" of C.

Arne

On 1/29/2022 2:54 PM, John Dallman wrote:
> In article <st401o$jaa$1@dont-email.me>, davef@tsoft-inc.com (Dave Froble)
> wrote:
>
>> I have never used Bliss, don't know it at all. So I cannot be the
>> judge of its worthiness. But all I seem to read is "it's old"
>> and "nobody knows it". Neither of those actually addresses its
>> suitability.
>
> I've done several assembly languages, BCPL and lots of C. I read the
> Bliss manual last year, and posted about it in March 2021.
>
> It is a language from the era when all programming was assumed to be hard,
> requiring detailed design documents, and painstaking specification of
> every data structure. This was entirely appropriate for a time when a
> mainframe's memory was measured in small numbers of megabytes. However,
> the hardware has changed. Packing data into every spare bit is rarely
> worthwhile. Using some of the computer's resources to make programming
> easier is usually desirable. Bliss is certainly better than assembler,
> but it assumes resources are scarce.
>
> The language seems unforgiving. An extra or missing "." or ";" can change
> the meaning of code in important ways. It's quite hard for a compiler to
> detect programming errors, more so than with C. Training programmers to
> be productive with Bliss looks as if it will take longer than teaching
> them appropriate C idioms for low-level programming, and will certainly
> produce more complaints.

A response I can understand and agree with.

> I don't know if equally skilled C or Bliss programmers would be more
> productive writing OS kernel code. I suspect it would depend on who had
> the better set of library routines and other project-specific tools. But
> if I had to put a team together for such work, I'd always choose C over
> Bliss. Doing the same makes sense for VSI, because they /are not DEC/.
> They don't have large pools of programmers to call on. They need to be
> able to hire people and have them become productive reasonably quickly.
>
> John
>

--
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 1/29/2022 3:21 PM, Arne Vajhøj wrote:
> On 1/29/2022 2:53 PM, John Dallman wrote:
>> In article <st401o$jaa$1@dont-email.me>, davef@tsoft-inc.com (Dave
>> Froble)
>> wrote:
>>> I have never used Bliss, don't know it at all. So I cannot be the
>>> judge of its worthiness. But all I seem to  read is "it's old"
>>> and "nobody knows it". Neither of those actually addresses its
>>> suitability.
>>
>> I've done several assembly languages, BCPL and lots of C. I read the
>> Bliss manual last year, and posted about it in March 2021.
>>
>> It is a language from the era when all programming was assumed to be
>> hard,
>> requiring detailed design documents, and painstaking specification of
>> every data structure. This was entirely appropriate for a time when a
>> mainframe's memory was measured in small numbers of megabytes. However,
>> the hardware has changed. Packing data into every spare bit is rarely
>> worthwhile. Using some of the computer's resources to make programming
>> easier is usually desirable. Bliss is certainly better than assembler,
>> but it assumes resources are scarce.
>>
>> The language seems unforgiving. An extra or missing "." or ";" can change
>> the meaning of code in important ways. It's quite hard for a compiler to
>> detect programming errors, more so than with C. Training programmers to
>> be productive with Bliss looks as if it will take longer than teaching
>> them appropriate C idioms for low-level programming, and will certainly
>> produce more complaints.
>>
>> I don't know if equally skilled C or Bliss programmers would be more
>> productive writing OS kernel code. I suspect it would depend on who had
>> the better set of library routines and other project-specific tools. But
>> if I had to put a team together for such work, I'd always choose C over
>> Bliss. Doing the same makes sense for VSI, because they /are not DEC/.
>> They don't have large pools of programmers to call on. They need to be
>> able to hire people and have them become productive reasonably quickly.
>
> Note that for the task that triggered this thread (DIRECTORY command)
> which consist of:
> - retrieving parameter and qualifiers
> - get info via RMS calls
> - output result
> then something even higher level than C would make sense. There is no
> need for any of the "flexibility" of C.

One can of course always discuss levels - there is no clear
definition, but I would rank like:

Python, PHP, Perl
C++, Ada95, Java
Pascal, Basic, Ada83, Fortran 9X
Fortran 77, Cobol
C Bliss
Macro

YMMV

Arne

On Saturday, January 29, 2022 at 9:55:18 PM UTC, Arne Vajhøj wrote:
> On 1/29/2022 3:21 PM, Arne Vajhøj wrote:
> > On 1/29/2022 2:53 PM, John Dallman wrote:
> >> In article <st401o$jaa$1...@dont-email.me>, da...@tsoft-inc.com (Dave
> >> Froble)
> >> wrote:
> >>> I have never used Bliss, don't know it at all. So I cannot be the
> >>> judge of its worthiness. But all I seem to read is "it's old"
> >>> and "nobody knows it". Neither of those actually addresses its
> >>> suitability.
> >>
> >> I've done several assembly languages, BCPL and lots of C. I read the
> >> Bliss manual last year, and posted about it in March 2021.
> >>
> >> It is a language from the era when all programming was assumed to be
> >> hard,
> >> requiring detailed design documents, and painstaking specification of
> >> every data structure. This was entirely appropriate for a time when a
> >> mainframe's memory was measured in small numbers of megabytes. However,
> >> the hardware has changed. Packing data into every spare bit is rarely
> >> worthwhile. Using some of the computer's resources to make programming
> >> easier is usually desirable. Bliss is certainly better than assembler,
> >> but it assumes resources are scarce.
> >>
> >> The language seems unforgiving. An extra or missing "." or ";" can change
> >> the meaning of code in important ways. It's quite hard for a compiler to
> >> detect programming errors, more so than with C. Training programmers to
> >> be productive with Bliss looks as if it will take longer than teaching
> >> them appropriate C idioms for low-level programming, and will certainly
> >> produce more complaints.
> >>
> >> I don't know if equally skilled C or Bliss programmers would be more
> >> productive writing OS kernel code. I suspect it would depend on who had
> >> the better set of library routines and other project-specific tools. But
> >> if I had to put a team together for such work, I'd always choose C over
> >> Bliss. Doing the same makes sense for VSI, because they /are not DEC/.
> >> They don't have large pools of programmers to call on. They need to be
> >> able to hire people and have them become productive reasonably quickly..
> >
> > Note that for the task that triggered this thread (DIRECTORY command)
> > which consist of:
> > - retrieving parameter and qualifiers
> > - get info via RMS calls
> > - output result
> > then something even higher level than C would make sense. There is no
> > need for any of the "flexibility" of C.
> One can of course always discuss levels - there is no clear
> definition, but I would rank like:
>
> Python, PHP, Perl
> C++, Ada95, Java
> Pascal, Basic, Ada83, Fortran 9X
> Fortran 77, Cobol
> C
> Bliss
> Macro
>
> YMMV
>
> Arne

Perhaps we should just have done with it and get .NET ported to VMS.... and then not bother with the VMS bit.

On 1/29/2022 5:33 PM, cao...@pitbulluk.org wrote:
> On Saturday, January 29, 2022 at 9:55:18 PM UTC, Arne Vajhøj wrote:
>> On 1/29/2022 3:21 PM, Arne Vajhøj wrote:
>>> Note that for the task that triggered this thread (DIRECTORY command)
>>> which consist of:
>>> - retrieving parameter and qualifiers
>>> - get info via RMS calls
>>> - output result
>>> then something even higher level than C would make sense. There is no
>>> need for any of the "flexibility" of C.
>> One can of course always discuss levels - there is no clear
>> definition, but I would rank like:
>>
>> Python, PHP, Perl
>> C++, Ada95, Java
>> Pascal, Basic, Ada83, Fortran 9X
>> Fortran 77, Cobol
>> C
>> Bliss
>> Macro
>>
>> YMMV
>
> Perhaps we should just have done with it and get .NET ported to VMS.... and then not bother with the VMS bit.

..NET is a good platform and C# is a very nice language.

So it would be great to have them available on VMS.

But my gut feeling is that the VMS world has more overlap
with the Java world and the Python world than with the
..NET world and the PHP world.

Arne

On 1/29/2022 3:21 PM, Arne Vajhøj wrote:
> On 1/29/2022 2:53 PM, John Dallman wrote:
>> In article <st401o$jaa$1@dont-email.me>, davef@tsoft-inc.com (Dave
>> Froble)
>> wrote:
>>> I have never used Bliss, don't know it at all. So I cannot be the
>>> judge of its worthiness. But all I seem to  read is "it's old"
>>> and "nobody knows it". Neither of those actually addresses its
>>> suitability.
>>
>> I've done several assembly languages, BCPL and lots of C. I read the
>> Bliss manual last year, and posted about it in March 2021.
>>
>> It is a language from the era when all programming was assumed to be
>> hard,
>> requiring detailed design documents, and painstaking specification of
>> every data structure. This was entirely appropriate for a time when a
>> mainframe's memory was measured in small numbers of megabytes. However,
>> the hardware has changed. Packing data into every spare bit is rarely
>> worthwhile. Using some of the computer's resources to make programming
>> easier is usually desirable. Bliss is certainly better than assembler,
>> but it assumes resources are scarce.
>>
>> The language seems unforgiving. An extra or missing "." or ";" can change
>> the meaning of code in important ways. It's quite hard for a compiler to
>> detect programming errors, more so than with C. Training programmers to
>> be productive with Bliss looks as if it will take longer than teaching
>> them appropriate C idioms for low-level programming, and will certainly
>> produce more complaints.
>>
>> I don't know if equally skilled C or Bliss programmers would be more
>> productive writing OS kernel code. I suspect it would depend on who had
>> the better set of library routines and other project-specific tools. But
>> if I had to put a team together for such work, I'd always choose C over
>> Bliss. Doing the same makes sense for VSI, because they /are not DEC/.
>> They don't have large pools of programmers to call on. They need to be
>> able to hire people and have them become productive reasonably quickly.
>
> Note that for the task that triggered this thread (DIRECTORY command)
> which consist of:
> - retrieving parameter and qualifiers
> - get info via RMS calls
> - output result
> then something even higher level than C would make sense. There is no
> need for any of the "flexibility" of C.

And it is not just me.

The rust people are rewriting GNU Coreutils (C) in
rust.

https://www.phoronix.com/scan.php?page=news_item&px=Rust-Coreutils-Jan-2022

Arne

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>> On 1/29/2022 2:53 PM, John Dallman wrote:
>>>
>>> It is a language from the era when all programming was assumed to be
>>> hard,
>>> requiring detailed design documents, and painstaking specification of
>>> every data structure. This was entirely appropriate for a time when a
>>> mainframe's memory was measured in small numbers of megabytes. However,
>>> the hardware has changed. Packing data into every spare bit is rarely
>>> worthwhile. Using some of the computer's resources to make programming
>>> easier is usually desirable. Bliss is certainly better than assembler,
>>> but it assumes resources are scarce.

Bliss is in these ways similar to HP's SPL/3000 "systems programming language"
and a fair choice for writing a kernel but not for writing the code that
the kernel runs. And as you mention, the syntax is not obvious and more
modern designs may make errors like misplaced endings much less of a problem.

>And it is not just me.
>
>The rust people are rewriting GNU Coreutils (C) in
>rust.
>
>https://www.phoronix.com/scan.php?page=news_item&px=Rust-Coreutils-Jan-2022

Didn't we already do that in Pascal back in the days of the Software Tools
In Pascal project?

Pascal is pretty limited but makes it hard to shoot yourself in the foot.
And most implementations don't use null-terminated strings which are the
most serious source of vulnerabilities in C code.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 1/29/22 19:26, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>>> On 1/29/2022 2:53 PM, John Dallman wrote:
>>>>
>>>> It is a language from the era when all programming was assumed to be
>>>> hard,
>>>> requiring detailed design documents, and painstaking specification of
>>>> every data structure. This was entirely appropriate for a time when a
>>>> mainframe's memory was measured in small numbers of megabytes. However,
>>>> the hardware has changed. Packing data into every spare bit is rarely
>>>> worthwhile. Using some of the computer's resources to make programming
>>>> easier is usually desirable. Bliss is certainly better than assembler,
>>>> but it assumes resources are scarce.
>
> Bliss is in these ways similar to HP's SPL/3000 "systems programming language"
> and a fair choice for writing a kernel but not for writing the code that
> the kernel runs. And as you mention, the syntax is not obvious and more
> modern designs may make errors like misplaced endings much less of a problem.
>
>> And it is not just me.
>>
>> The rust people are rewriting GNU Coreutils (C) in
>> rust.
>>
>> https://www.phoronix.com/scan.php?page=news_item&px=Rust-Coreutils-Jan-2022
>
> Didn't we already do that in Pascal back in the days of the Software Tools
> In Pascal project?

And in Ratfor in the STVOS.

>
> Pascal is pretty limited but makes it hard to shoot yourself in the foot.
> And most implementations don't use null-terminated strings which are the
> most serious source of vulnerabilities in C code.

Isn't it time to drop this red herring. C was not the only and
probably not the first to use null terminated strings. If anyone
really cared it could have been fixed ages ago (it actually was
in Safe C and we see how much acceptance that got!!)

bill

On 1/29/2022 7:13 PM, Arne Vajhøj wrote:
> On 1/29/2022 3:21 PM, Arne Vajhøj wrote:
>> On 1/29/2022 2:53 PM, John Dallman wrote:
>>> In article <st401o$jaa$1@dont-email.me>, davef@tsoft-inc.com (Dave Froble)
>>> wrote:
>>>> I have never used Bliss, don't know it at all. So I cannot be the
>>>> judge of its worthiness. But all I seem to read is "it's old"
>>>> and "nobody knows it". Neither of those actually addresses its
>>>> suitability.
>>>
>>> I've done several assembly languages, BCPL and lots of C. I read the
>>> Bliss manual last year, and posted about it in March 2021.
>>>
>>> It is a language from the era when all programming was assumed to be hard,
>>> requiring detailed design documents, and painstaking specification of
>>> every data structure. This was entirely appropriate for a time when a
>>> mainframe's memory was measured in small numbers of megabytes. However,
>>> the hardware has changed. Packing data into every spare bit is rarely
>>> worthwhile. Using some of the computer's resources to make programming
>>> easier is usually desirable. Bliss is certainly better than assembler,
>>> but it assumes resources are scarce.
>>>
>>> The language seems unforgiving. An extra or missing "." or ";" can change
>>> the meaning of code in important ways. It's quite hard for a compiler to
>>> detect programming errors, more so than with C. Training programmers to
>>> be productive with Bliss looks as if it will take longer than teaching
>>> them appropriate C idioms for low-level programming, and will certainly
>>> produce more complaints.
>>>
>>> I don't know if equally skilled C or Bliss programmers would be more
>>> productive writing OS kernel code. I suspect it would depend on who had
>>> the better set of library routines and other project-specific tools. But
>>> if I had to put a team together for such work, I'd always choose C over
>>> Bliss. Doing the same makes sense for VSI, because they /are not DEC/.
>>> They don't have large pools of programmers to call on. They need to be
>>> able to hire people and have them become productive reasonably quickly.
>>
>> Note that for the task that triggered this thread (DIRECTORY command)
>> which consist of:
>> - retrieving parameter and qualifiers
>> - get info via RMS calls
>> - output result
>> then something even higher level than C would make sense. There is no
>> need for any of the "flexibility" of C.
>
> And it is not just me.
>
> The rust people are rewriting GNU Coreutils (C) in
> rust.
>
> https://www.phoronix.com/scan.php?page=news_item&px=Rust-Coreutils-Jan-2022
>
> Arne
>

Why?

Seems like another "language of the week". It ain't broke, but they are fixing
it anyway.

--
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 1/29/2022 7:45 PM, Bill Gunshannon wrote:
> On 1/29/22 19:26, Scott Dorsey wrote:
>> Pascal is pretty limited but makes it hard to shoot yourself in the foot.
>> And most implementations don't use null-terminated strings which are the
>> most serious source of vulnerabilities in C code.
>
> Isn't it time to drop this red herring.  C was not the only and
> probably not the first to use null terminated strings.

C and C++ are the only widely used languages only using
a terminator marker for strings.

>   If anyone
> really cared it could have been fixed ages ago (it actually was
> in Safe C and we see how much acceptance that got!!)

People do care.

But the typical choice is to switch to another language - not to
ask for fundamental changes to C.

C is almost dead in business applications. It is still big in
platform software. But even though Microsoft and Linux are
pretty far from each other in many aspects then they do share
an interest in looking at Rust as replacement for C.

Arne

On 1/29/2022 8:03 PM, Dave Froble wrote:
> On 1/29/2022 7:13 PM, Arne Vajhøj wrote:
>> And it is not just me.
>>
>> The rust people are rewriting GNU Coreutils (C) in
>> rust.
>>
>> https://www.phoronix.com/scan.php?page=news_item&px=Rust-Coreutils-Jan-2022
>
> Why?

The article explains why. Better security.

> Seems like another "language of the week".  It ain't broke, but they are
> fixing it anyway.

C is not really the right language for that type of application. There
is no need for any unsafe features just unnecessary risk.

Whether Rust is the right language to replace it is another question.

Rust is 11 years old now. And have a pretty good backing: Mozilla,
Linux kernel, Microsoft, Amazon, Facebook, Apple, Telenor, ByteDance,
Canonical, Baidu, DropBox etc. are all using Rust in some way.

Are they given to be the future? No. Still way to soon to say. But
they are a serious contender.

And there are limited alternatives. "Modern" C++ and Go are
the only two that comes to my mind.

Arne

On 1/29/22 20:11, Arne Vajhøj wrote:
> On 1/29/2022 7:45 PM, Bill Gunshannon wrote:
>> On 1/29/22 19:26, Scott Dorsey wrote:
>>> Pascal is pretty limited but makes it hard to shoot yourself in the
>>> foot.
>>> And most implementations don't use null-terminated strings which are the
>>> most serious source of vulnerabilities in C code.
>>
>> Isn't it time to drop this red herring.  C was not the only and
>> probably not the first to use null terminated strings.
>
> C and C++ are the only widely used languages only using
> a terminator marker for strings.

Can't verify that as I don't know the internals of the many
language du jour today. But, as I said, when it started it
was not limited to C and probably didn't originate there.

>
>>                                                        If anyone
>> really cared it could have been fixed ages ago (it actually was
>> in Safe C and we see how much acceptance that got!!)
>
> People do care.
>
> But the typical choice is to switch to another language - not to
> ask for fundamental changes to C.

As I stated, the problem was fixed, in a version of C and
the company faded into oblivion with no one pushing for it's
widespread use.

>
> C is almost dead in business applications.

As it should be.

> It is still big in
> platform software.

As it should be. :-)

> But even though Microsoft and Linux are
> pretty far from each other in many aspects then they do share
> an interest in looking at Rust as replacement for C.

I will not be holding my breathe waiting for Unix to be re-written
in Rust.

bill

On 1/29/2022 8:29 PM, Bill Gunshannon wrote:
> On 1/29/22 20:11, Arne Vajhøj wrote:
>>                      But even though Microsoft and Linux are
>> pretty far from each other in many aspects then they do share
>> an interest in looking at Rust as replacement for C.
>
> I will not be holding my breathe waiting for Unix to be re-written
> in Rust.

Old commercial Unix'es will not be rewritten. Thee will be lucky
if they are even maintained.

But Linux is pretty serious about rust.

And the open source Unix world are "flirting a little bit"
with rust as well. FreeBSD has added support for
drivers in Rust and they have some userland stuff
in Rust in their ports collection.

But it would be very unhealthy to hold ones breath until Rust
takes over from C.

Arne

On 1/29/22 20:46, Arne Vajhøj wrote:
> On 1/29/2022 8:29 PM, Bill Gunshannon wrote:
>> On 1/29/22 20:11, Arne Vajhøj wrote:
>>>                      But even though Microsoft and Linux are
>>> pretty far from each other in many aspects then they do share
>>> an interest in looking at Rust as replacement for C.
>>
>> I will not be holding my breathe waiting for Unix to be re-written
>> in Rust.
>
> Old commercial Unix'es will not be rewritten. Thee will be lucky
> if they are even maintained.

Real Unix is still alive and well and being maintained at least as good
as Linux.

>
> But Linux is pretty serious about rust.

Wouldn't be the first mistake they have made.

>
> And the open source Unix world are "flirting a little bit"
> with rust as well. FreeBSD has added support for
> drivers in Rust and they have some userland stuff
> in Rust in their ports collection.

Sorry to hear that.

>
> But it would be very unhealthy to hold ones breath until Rust
> takes over from C.

C will still be around long after Rust is nothing but a vague
memory.

bill

On 28/01/2022 4:08 am, Arne Vajhøj wrote:
> On 1/27/2022 2:31 PM, Simon Clubley wrote:
>> On 2022-01-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 1/27/2022 11:25 AM, John Reagan wrote:
>>>> On Thursday, January 27, 2022 at 3:39:38 AM UTC-5, Dave Froble wrote:
>>>>> Why C, when there are better languages?
>>>>
>>>> If you are about to use the B-word, better is relative.
>>>
>>> Obviously.
>>>
>>> But not everybody is in love with C.
>>>
>>> Personally I consider C a fine language for OS kernel development
>>> but not so great a language for more regular applications. And
>>> DIR is really an application.
>>>
>>> I am not good at VMS Basic, so I would prefer VMS Pascal.
>>>
>>> :-)
>>
>> Pascal is acceptable, but Ada would be better. :-)
>>
>> On a more serious note, what would be an acceptable programming language
>> for userland tools which need to be shipped as part of the operating
>> system ?
>>
>> Let's look at the language options for creating a new userland level
>> tool on VMS today:
>>
>> Macro-32 and BLISS are absolutely unsuitable for obvious reasons.
>>
>> Basic appears to be a poor choice when compared to the alternatives
>> available.
>>
>> Ada is no longer available on VMS going forward.
>>
>> C is suitable, but is low-level.
>>
>> C++ is a possibility (provided a sane subset of the language is used).
>> However, am I the only one who finds that C++ compilers across all
>> operating systems get slower and slower as new versions some out ?
>> Look at how long it takes to compile the LLVM toolkit for example. :-(
>> :-(
>>
>> Pascal is also very much a possibility.
>>
>> Fortran and COBOL are not suitable for writing operating system userland
>> tools.
>>
>> So what programming language would you use for a new userland tool on VMS
>> if you couldn't use Pascal ? As far as I can see, it's only C or maybe
>> C++.
>
> I believe Basic would be a lot better than C.
>
> Arne
>

And COBOL is the besterest.

And if you can program some MACRO then you need a Garbage Collect to
cover up yor lack of skill in managing memory.