On Friday, November 12, 2021 at 5:21:48 AM UTC+13, Arne Vajhøj wrote:
> On 11/10/2021 11:48 PM, Lawrence D’Oliveiro wrote:
>> On Thursday, November 11, 2021 at 3:33:33 PM UTC+13, Arne Vajhøj wrote:
>>> The biggest problems with UTF-8 is that the byte length is not
>>> necessarily the character length ...
>>
>> That would be true of any Unicode encoding, even UCS-4.
>
> No.

You didn’t know, then, that what Unicode codes define are not characters, but code points?

On Friday, November 12, 2021 at 7:17:58 AM UTC+13, Craig A. Berry wrote:
> Back when it was called UCS-4, I think that was true.

It was never true. In Unicode, a “character” consists of a base code point followed by any number of combining code points. Some combinations may have their own assigned code point; many don’t.

> But even if the
> encoding is not varying width, the number of characters displayed might
> not match the number of code points because of things like combining
> characters.

And it is worth keeping the distinction between “code points” and “characters” in mind, for this reason.

On Friday, November 12, 2021 at 8:36:00 AM UTC+13, Craig A. Berry wrote:
> For some reason I had thought they'd blown the 4-byte limit with emojis ....

Nowhere near. Unicode currently only officially has room for about a million “code points” (not the same as “characters”), and the emojis I think only number a few hundred at most.

Also, they did a clever thing with the representation of ISO 3166 national/regional flag codes, using just 26 code points.

> but it doesn't seem UTF-32 has any provision for surrogate pairs.

Surrogates were a hack to turn UCS-2 into UTF-16. Remember, back when Unicode was young, it was only a fixed-width 16-bit code, and I’m pretty sure there were even assurances given that it would remain that way. So Microsoft took them at their word when incorporating Unicode into the heart of Windows NT, and so did Sun with Java.

So now, they have this horrible “UTF-16” thing baked into them. It’s not an encoding anybody would adopt voluntarily.

On Friday, November 12, 2021 at 7:53:21 AM UTC+13, Arne Vajhøj wrote:
> <quote>
> Each Unicode code point is represented directly by a single 32-bit
> code unit. Because of this, UTF-32 has a one-to-one relationship
> between encoded character and code unit; it is a fixed-width character
> encoding form.
> </quote>

Beware of terminology! What a normal person might call a “character”, they call a “text element”. This is represented by one or more of what they are calling an “encoded character”.

So they are able to call UTF-32/UCS-4 a “fixed-width” encoding, only with reference to “encoded characters”, not actually to “characters”.

On Friday, November 12, 2021 at 11:45:39 AM UTC+13, I wrote:
> On Friday, November 12, 2021 at 7:53:21 AM UTC+13, Arne Vajhøj wrote:
>> <quote>
>> Each Unicode code point is represented directly by a single 32-bit
>> code unit. Because of this, UTF-32 has a one-to-one relationship
>> between encoded character and code unit; it is a fixed-width character
>> encoding form.
>> </quote>
>
> Beware of terminology! What a normal person might call a “character”, they call a “text
> element”. This is represented by one or more of what they are calling an “encoded character”.

Actually, the term “text element” is less specific than that. More accurate terms, according to <https://www.unicode.org/reports/tr29/tr29-39.html>, would be “user-perceived character” or “grapheme cluster”.

On 11/11/2021 4:57 PM, Lawrence D’Oliveiro wrote:
> On Friday, November 12, 2021 at 5:21:48 AM UTC+13, Arne Vajhøj wrote:
>> On 11/10/2021 11:48 PM, Lawrence D’Oliveiro wrote:
>>> On Thursday, November 11, 2021 at 3:33:33 PM UTC+13, Arne Vajhøj wrote:
>>>> The biggest problems with UTF-8 is that the byte length is not
>>>> necessarily the character length ...
>>>
>>> That would be true of any Unicode encoding, even UCS-4.
>>
>> No.
>
> You didn’t know, then, that what Unicode codes define are not characters, but code points?

Nonsense.

<quote>
The Unicode Standard specifies a numeric value (code point) and a name
for each of its characters.
....
Unicode characters are represented in one of three encoding forms: a
32-bit form (UTF-32), a 16-bit form (UTF-16), and an 8-bit form (UTF-8).
</quote>

Arne

On 2021-11-11, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
> On 11/11/2021 4:01 PM, Arne Vajhøj wrote:
>> On 11/11/2021 3:57 PM, Michael Moroney wrote:
>
>>> You remember correctly. The hardwired '24 line terminal' assumption pissed me
>>> off and a few times I looked at it I said no way I can fix that spaghetti
>>> code. But one day the planets were aligned or something, and I just did it.
>>
>> Macro-32 ?
>
> BLISS-32
>

Same difference. :-)

On a more serious note, BLISS-32 was a nice idea, but it's at way too
low a level to make a real difference.

Now, if we had a Pascal-like or Ada-like language that could be used
as a system implementation language... :-)

Simon.

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

On 11/12/2021 1:28 PM, Simon Clubley wrote:
> On 2021-11-11, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
>> On 11/11/2021 4:01 PM, Arne Vajhøj wrote:
>>> On 11/11/2021 3:57 PM, Michael Moroney wrote:
>>
>>>> You remember correctly. The hardwired '24 line terminal' assumption pissed me
>>>> off and a few times I looked at it I said no way I can fix that spaghetti
>>>> code. But one day the planets were aligned or something, and I just did it.
>>>
>>> Macro-32 ?
>>
>> BLISS-32
>>
>
> Same difference. :-)

No, it's not. While it's true that one can write bad code in any language,
BLISS, due its procedural nature, does not default to spaghetti code.

While the EDT code can be confusing (due to lack of comments), the code flow
isn't that bad.

What can be confusing in BLISS is the use of nested macros, where a single
BLISS "statement" can expand into several pages of code.

--

-- Rob

On 11/12/2021 1:45 PM, Robert A. Brooks wrote:
> On 11/12/2021 1:28 PM, Simon Clubley wrote:
>> On 2021-11-11, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
>>> On 11/11/2021 4:01 PM, Arne Vajhøj wrote:
>>>> On 11/11/2021 3:57 PM, Michael Moroney wrote:
>>>
>>>>> You remember correctly. The hardwired '24 line terminal' assumption
>>>>> pissed me
>>>>> off and a few times I looked at it I said no way I can fix that
>>>>> spaghetti
>>>>> code. But one day the planets were aligned or something, and I just
>>>>> did it.
>>>>
>>>> Macro-32 ?
>>>
>>> BLISS-32
>>>
>>
>> Same difference. :-)
>
> No, it's not.  While it's true that one can write bad code in any language,
> BLISS, due its procedural nature, does not default to spaghetti code.
>
> While the EDT code can be confusing (due to lack of comments), the code
> flow
> isn't that bad.
>
> What can be confusing in BLISS is the use of nested macros, where a single
> BLISS "statement" can expand into several pages of code.
>
What made it difficult for me when first considering this were a few things:

1) I was relatively weak at BLISS. Almost everything I did in my VMS
career was C/MACRO-32 and some other languages.

2) I think the coding style threw me. Sometimes that does that. Even my
own! :-) Some of the code was trying to squeeze every byte out, as old
code almost always does.

3) There was no equivalent of C's .H file containing something like
'#define terminal_lines 24'. I went through ALL modules looking for
EVERY instance of the character string/constant '24'. EDT is split up
into many modules. I then had to look at EVERY instance of '23' and '22'
(number of lines of the edited file being displayed). I also looked at
'21' and '25'. There was much more but I forget.

My first pass was hardwiring everything to something like '40', that is
terminals all had 40 lines, not 24. Then I tried things in a fixed 40
line long terminal window. It mostly worked on the second attempt. Then
I went back to making things variable, based on terminal characteristics.

There is much more but I forget, it was some time ago that I did this.

On 2021-11-12 18:45:57 +0000, Robert A. Brooks said:

> On 11/12/2021 1:28 PM, Simon Clubley wrote:
>> On 2021-11-11, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
>>> On 11/11/2021 4:01 PM, Arne Vajhøj wrote:
>>>> On 11/11/2021 3:57 PM, Michael Moroney wrote:
>>>
>>>>> You remember correctly. The hardwired '24 line terminal' assumption pissed me
>>>>> off and a few times I looked at it I said no way I can fix that spaghetti
>>>>> code. But one day the planets were aligned or something, and I just did it.
>>>>
>>>> Macro-32 ?
>>>
>>> BLISS-32
>>>
>>
>> Same difference. :-)
>
> No, it's not. While it's true that one can write bad code in any
> language, BLISS, due its procedural nature, does not default to
> spaghetti code.

Alas, I've looked at a whole lot of Bliss spaghetti code over the
years. More than I'd prefer, though less than the amount of Macro32
spaghetti.

In the past decades, Bliss and Macro32 both effectively became DSLs for
OpenVMS, for better or worse.

The Bliss compiler itself and the Bliss language could use an overhaul
with better diagnostics, with code-refactoring support, with IDE
support, and with other enhancements. But Bliss enhancement work is not
likely a priority for anybody.

Automatic source code refactoring has gotten substantially better too,
for those that haven't worked with it. Between that and source code
formatting tools, more than a little source code spaghetti can be
remediated.

> While the EDT code can be confusing (due to lack of comments), the code
> flow isn't that bad.

Most of the Bliss code written by OpenVMS development was fairly well
done. The Bliss and Macro32 code with variant calling schemes was
always good for some puzzlement, though.

> What can be confusing in BLISS is the use of nested macros, where a
> single BLISS "statement" can expand into several pages of code.

Some examples of Bliss macros were near-impenetrable, and most easily
read with the assistance of the Bliss compiler listings macro
expansion. Macro32 macro support suffered somewhat similarly. C's
macro preprocessor is comparatively simplistic. Not that I haven't used
the C macro preprocessor on Fortran and BASIC code. In some ways. Bliss
macros remind me of C++ macros and C++ operator overloading support.

I've been coming around toward how Zig, Swift, and other programming
languages are designed; with the abstractions in the language and the
compiler and the run-time, and without executable code embedded within
macros.

--
Pure Personal Opinion | HoffmanLabs LLC

On 11/12/2021 6:59 PM, Stephen Hoffman wrote:
> On 2021-11-12 18:45:57 +0000, Robert A. Brooks said:
>> What can be confusing in BLISS is the use of nested macros, where a
>> single BLISS "statement" can expand into several pages of code.
>
> Some examples of Bliss macros were near-impenetrable, and most easily
> read with the assistance of the Bliss compiler listings macro
> expansion.  Macro32 macro support suffered somewhat similarly. C's macro
> preprocessor is comparatively simplistic. Not that I haven't used the C
> macro preprocessor on Fortran and BASIC code. In some ways. Bliss macros
> remind me of C++ macros and C++ operator overloading support.

C++ macros? Templates?

Arne

On Friday, November 12, 2021 at 1:28:38 PM UTC-5, Simon Clubley wrote:
> On 2021-11-11, Robert A. Brooks <FIRST...@vmssoftware.com> wrote:
> > On 11/11/2021 4:01 PM, Arne Vajhøj wrote:
> >> On 11/11/2021 3:57 PM, Michael Moroney wrote:
> >
> >>> You remember correctly. The hardwired '24 line terminal' assumption pissed me
> >>> off and a few times I looked at it I said no way I can fix that spaghetti
> >>> code. But one day the planets were aligned or something, and I just did it.
> >>
> >> Macro-32 ?
> >
> > BLISS-32
> >
> Same difference. :-)
>
> On a more serious note, BLISS-32 was a nice idea, but it's at way too
> low a level to make a real difference.
>
> Now, if we had a Pascal-like or Ada-like language that could be used
> as a system implementation language... :-)
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

Next time you post that, please add a "<Trigger warning for John Reagan>" at the top please.

On 2021-11-12, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>
> Some examples of Bliss macros were near-impenetrable, and most easily
> read with the assistance of the Bliss compiler listings macro
> expansion. Macro32 macro support suffered somewhat similarly. C's
> macro preprocessor is comparatively simplistic. Not that I haven't used
> the C macro preprocessor on Fortran and BASIC code. In some ways. Bliss
> macros remind me of C++ macros and C++ operator overloading support.
>

When people write code like that, they may think they are being
"clever" but in fact they are just being irresponsible because
they are just setting up major maintenance problems for further
down the road.

I refer you to the terminal driver for another example of this and
that, as a result, we don't even have something as simple as being
able to edit command lines that are longer than the terminal width.

This, BTW, is something that even the awful and primitive cmd shell
in Windows has absolutely no problem with.

Simon.

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

On 2021-11-14, John Reagan <xyzzy1959@gmail.com> wrote:
> On Friday, November 12, 2021 at 1:28:38 PM UTC-5, Simon Clubley wrote:
>> On 2021-11-11, Robert A. Brooks <FIRST...@vmssoftware.com> wrote:
>> > On 11/11/2021 4:01 PM, Arne Vajhøj wrote:
>> >> On 11/11/2021 3:57 PM, Michael Moroney wrote:
>> >
>> >>> You remember correctly. The hardwired '24 line terminal' assumption pissed me
>> >>> off and a few times I looked at it I said no way I can fix that spaghetti
>> >>> code. But one day the planets were aligned or something, and I just did it.
>> >>
>> >> Macro-32 ?
>> >
>> > BLISS-32
>> >
>> Same difference. :-)
>>
>> On a more serious note, BLISS-32 was a nice idea, but it's at way too
>> low a level to make a real difference.
>>
>> Now, if we had a Pascal-like or Ada-like language that could be used
>> as a system implementation language... :-)
>>
>
> Next time you post that, please add a "<Trigger warning for John Reagan>" at the top please.
>

Sorry, but I live in a country where we don't yet have to issue
"trigger warnings" in everyday conversation. I don't know about
the rest of Europe however.

However, you have been way too quick to issue a "trigger warning"
request without even telling me what "triggered" you. :-)

Was it comparing BLISS-32 to Macro-32 ?

Was it the desire to have a Pascal-like or Ada-like language as a
viable system implementation language ?

Was it something else ? :-)

Simon.

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

On 11/14/2021 1:32 PM, Simon Clubley wrote:
> On 2021-11-12, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>
>> Some examples of Bliss macros were near-impenetrable, and most easily
>> read with the assistance of the Bliss compiler listings macro
>> expansion. Macro32 macro support suffered somewhat similarly. C's
>> macro preprocessor is comparatively simplistic. Not that I haven't used
>> the C macro preprocessor on Fortran and BASIC code. In some ways. Bliss
>> macros remind me of C++ macros and C++ operator overloading support.
>>
>
> When people write code like that, they may think they are being
> "clever" but in fact they are just being irresponsible because
> they are just setting up major maintenance problems for further
> down the road.

I have no problem with clever code, but, dammit, explain it!

A short while back some posts in reply to some of mine claimed that there is
such a thing as "too many comments". Isn't this an example of justifying my
claim that there is no such thing as "too many comments"?

Perhaps a paragraph or two to explain macros? Then the really tough thing.
Updates to the comments to explain modifications. I prefer to do so with
additional comments, leaving the originals intact.

--
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 11/14/2021 11:10 AM, John Reagan wrote:
> On Friday, November 12, 2021 at 1:28:38 PM UTC-5, Simon Clubley wrote:
>> On 2021-11-11, Robert A. Brooks <FIRST...@vmssoftware.com> wrote:
>>> On 11/11/2021 4:01 PM, Arne Vajhøj wrote:
>>>> On 11/11/2021 3:57 PM, Michael Moroney wrote:
>>>
>>>>> You remember correctly. The hardwired '24 line terminal' assumption pissed me
>>>>> off and a few times I looked at it I said no way I can fix that spaghetti
>>>>> code. But one day the planets were aligned or something, and I just did it.
>>>>
>>>> Macro-32 ?
>>>
>>> BLISS-32
>>>
>> Same difference. :-)
>>
>> On a more serious note, BLISS-32 was a nice idea, but it's at way too
>> low a level to make a real difference.
>>
>> Now, if we had a Pascal-like or Ada-like language that could be used
>> as a system implementation language... :-)
>>
>> Simon.
>>
>> --
>> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
>> Walking destinations on a map are further away than they appear.
>
> Next time you post that, please add a "<Trigger warning for John Reagan>" at the top please.
>

What? You don't like "walking destinations" ? Neither do I.

I really disagree with Simon on this topic, the implementation language thing,
not the walking thing. Well, maybe both.

One really doesn't need a language or compiler to get in the way of what needs
to be done.

--
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 11/14/2021 1:41 PM, Simon Clubley wrote:
> On 2021-11-14, John Reagan <xyzzy1959@gmail.com> wrote:
>> On Friday, November 12, 2021 at 1:28:38 PM UTC-5, Simon Clubley wrote:
>>> On 2021-11-11, Robert A. Brooks <FIRST...@vmssoftware.com> wrote:
>>>> On 11/11/2021 4:01 PM, Arne Vajhøj wrote:
>>>>> On 11/11/2021 3:57 PM, Michael Moroney wrote:
>>>>
>>>>>> You remember correctly. The hardwired '24 line terminal' assumption pissed me
>>>>>> off and a few times I looked at it I said no way I can fix that spaghetti
>>>>>> code. But one day the planets were aligned or something, and I just did it.
>>>>>
>>>>> Macro-32 ?
>>>>
>>>> BLISS-32
>>>>
>>> Same difference. :-)
>>>
>>> On a more serious note, BLISS-32 was a nice idea, but it's at way too
>>> low a level to make a real difference.
>>>
>>> Now, if we had a Pascal-like or Ada-like language that could be used
>>> as a system implementation language... :-)
>>>
>>
>> Next time you post that, please add a "<Trigger warning for John Reagan>" at the top please.
>>
>
> Sorry, but I live in a country where we don't yet have to issue
> "trigger warnings" in everyday conversation. I don't know about
> the rest of Europe however.
>
> However, you have been way too quick to issue a "trigger warning"
> request without even telling me what "triggered" you. :-)
>
> Was it comparing BLISS-32 to Macro-32 ?
>
> Was it the desire to have a Pascal-like or Ada-like language as a
> viable system implementation language ?

I'm figuring this is it. No such thing as a language that can do everything.
Sometimes simpler is better.

> Was it something else ? :-)
>
> Simon.
>

--
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 2021-11-14, Dave Froble <davef@tsoft-inc.com> wrote:
> On 11/14/2021 11:10 AM, John Reagan wrote:
>> On Friday, November 12, 2021 at 1:28:38 PM UTC-5, Simon Clubley wrote:
>>> On 2021-11-11, Robert A. Brooks <FIRST...@vmssoftware.com> wrote:
>>>> On 11/11/2021 4:01 PM, Arne Vajhøj wrote:
>>>>> On 11/11/2021 3:57 PM, Michael Moroney wrote:
>>>>
>>>>>> You remember correctly. The hardwired '24 line terminal' assumption pissed me
>>>>>> off and a few times I looked at it I said no way I can fix that spaghetti
>>>>>> code. But one day the planets were aligned or something, and I just did it.
>>>>>
>>>>> Macro-32 ?
>>>>
>>>> BLISS-32
>>>>
>>> Same difference. :-)
>>>
>>> On a more serious note, BLISS-32 was a nice idea, but it's at way too
>>> low a level to make a real difference.
>>>
>>> Now, if we had a Pascal-like or Ada-like language that could be used
>>> as a system implementation language... :-)
>>>
>>> Simon.
>>>
>>> --
>>> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
>>> Walking destinations on a map are further away than they appear.
>>
>> Next time you post that, please add a "<Trigger warning for John Reagan>" at the top please.
>>
>
> What? You don't like "walking destinations" ? Neither do I.
>
> I really disagree with Simon on this topic, the implementation language thing,
> not the walking thing. Well, maybe both.
>

I take it you are not a walker David. :-)

I wonder how many people around here who are walkers either agree with
me or at least understand what I am saying ?

> One really doesn't need a language or compiler to get in the way of what needs
> to be done.
>

There is a move towards more safe languages for systems programming.

The current fashion, Rust, has horrible syntax, and I have no confidence
that code written in it today will still compile on the Rust compilers
of 5 to 10 years from now, but its use is being driven by the desire
for using safer languages.

When Rust falls out of fashion, it would be nice if whatever follows
Rust would address both of those problems.

Simon.

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

On 11/14/21 5:05 PM, Simon Clubley wrote:
> On 2021-11-14, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 11/14/2021 11:10 AM, John Reagan wrote:
>>> On Friday, November 12, 2021 at 1:28:38 PM UTC-5, Simon Clubley wrote:
>>>> On 2021-11-11, Robert A. Brooks <FIRST...@vmssoftware.com> wrote:
>>>>> On 11/11/2021 4:01 PM, Arne Vajhøj wrote:
>>>>>> On 11/11/2021 3:57 PM, Michael Moroney wrote:
>>>>>
>>>>>>> You remember correctly. The hardwired '24 line terminal' assumption pissed me
>>>>>>> off and a few times I looked at it I said no way I can fix that spaghetti
>>>>>>> code. But one day the planets were aligned or something, and I just did it.
>>>>>>
>>>>>> Macro-32 ?
>>>>>
>>>>> BLISS-32
>>>>>
>>>> Same difference. :-)
>>>>
>>>> On a more serious note, BLISS-32 was a nice idea, but it's at way too
>>>> low a level to make a real difference.
>>>>
>>>> Now, if we had a Pascal-like or Ada-like language that could be used
>>>> as a system implementation language... :-)
>>>>
>>>> Simon.
>>>>
>>>> --
>>>> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
>>>> Walking destinations on a map are further away than they appear.
>>>
>>> Next time you post that, please add a "<Trigger warning for John Reagan>" at the top please.
>>>
>>
>> What? You don't like "walking destinations" ? Neither do I.
>>
>> I really disagree with Simon on this topic, the implementation language thing,
>> not the walking thing. Well, maybe both.
>>
>
> I take it you are not a walker David. :-)
>
> I wonder how many people around here who are walkers either agree with
> me or at least understand what I am saying ?
>
>> One really doesn't need a language or compiler to get in the way of what needs
>> to be done.
>>
>
> There is a move towards more safe languages for systems programming.
>
> The current fashion, Rust, has horrible syntax, and I have no confidence
> that code written in it today will still compile on the Rust compilers
> of 5 to 10 years from now, but its use is being driven by the desire
> for using safer languages.
>
> When Rust falls out of fashion, it would be nice if whatever follows
> Rust would address both of those problems.
>

I thought this is the problem Ada was created to fix? :-)

bill

On 11/14/2021 2:43 PM, Dave Froble wrote:
> On 11/14/2021 1:41 PM, Simon Clubley wrote:
>> However, you have been way too quick to issue a "trigger warning"
>> request without even telling me what "triggered" you. :-)
>>
>> Was it comparing BLISS-32 to Macro-32 ?
>>
>> Was it the desire to have a Pascal-like or Ada-like language as a
>> viable system implementation language ?
>
> I'm figuring this is it.  No such thing as a language that can do
> everything. Sometimes simpler is better.

Programming languages are definitely not "one size fits all".

I totally agree that simpler is better for programming languages.

And this is not just you and me - very complex languages tend not
to prosper in the industry.

But I don't think Simon's point was complex vs simple.

More like structured vs goto style. and strong typing vs weak
typing.

Because Ada is a complex language, but Pascal is actually a relative
simple language (at least in traditional form and in VMS flavor - Delphi
has sort of moved a bit in the complex direction).

Arne

On 11/14/2021 5:05 PM, Simon Clubley wrote:
> On 2021-11-14, Dave Froble <davef@tsoft-inc.com> wrote:
>> One really doesn't need a language or compiler to get in the way of what needs
>> to be done.
>
> There is a move towards more safe languages for systems programming.
>
> The current fashion, Rust, has horrible syntax, and I have no confidence
> that code written in it today will still compile on the Rust compilers
> of 5 to 10 years from now, but its use is being driven by the desire
> for using safer languages.
>
> When Rust falls out of fashion, it would be nice if whatever follows
> Rust would address both of those problems.

Rust seems to be getting some traction.

With Mozilla, Microsoft and Linux kernel adding Rust code and
with Google and Amazon also backing it, then it may be difficult
to fall out of fashion.

Arne

On 11/14/2021 6:50 PM, Arne Vajhøj wrote:
> On 11/14/2021 2:43 PM, Dave Froble wrote:
>> On 11/14/2021 1:41 PM, Simon Clubley wrote:
>>> However, you have been way too quick to issue a "trigger warning"
>>> request without even telling me what "triggered" you. :-)
>>>
>>> Was it comparing BLISS-32 to Macro-32 ?
>>>
>>> Was it the desire to have a Pascal-like or Ada-like language as a
>>> viable system implementation language ?
>>
>> I'm figuring this is it.  No such thing as a language that can do
>> everything. Sometimes simpler is better.
>
> Programming languages are definitely not "one size fits all".
>
> I totally agree that simpler is better for programming languages.
>
> And this is not just you and me - very complex languages tend not
> to prosper in the industry.
>
> But I don't think Simon's point was complex vs simple.
>
> More like structured vs goto style. and strong typing vs weak
> typing.
>
> Because Ada is a complex language, but Pascal is actually a relative
> simple language (at least in traditional form and in VMS flavor - Delphi
> has sort of moved a bit in the complex direction).

I like Pascal, but for something real I would probably prefer
Modula-2. I have always loved that language!

Arne

On 11/14/2021 6:43 PM, Bill Gunshannon wrote:
> On 11/14/21 5:05 PM, Simon Clubley wrote:
>> There is a move towards more safe languages for systems programming.
>>
>> The current fashion, Rust, has horrible syntax, and I have no confidence
>> that code written in it today will still compile on the Rust compilers
>> of 5 to 10 years from now, but its use is being driven by the desire
>> for using safer languages.
>>
>> When Rust falls out of fashion, it would be nice if whatever follows
>> Rust would address both of those problems.
>
> I thought this is the problem Ada was created to fix?  :-)

It was.

But Ada did fall out of fashion.

There are probably many explanations for that, but my guess
is that the complexity of the language turned out to be a
problem.

Arne

Am 15.11.2021 um 00:55 schrieb Arne Vajhøj:
> On 11/14/2021 6:50 PM, Arne Vajhøj wrote:
>> On 11/14/2021 2:43 PM, Dave Froble wrote:
>>> On 11/14/2021 1:41 PM, Simon Clubley wrote:
>>>> However, you have been way too quick to issue a "trigger warning"
>>>> request without even telling me what "triggered" you. :-)
>>>>
>>>> Was it comparing BLISS-32 to Macro-32 ?
>>>>
>>>> Was it the desire to have a Pascal-like or Ada-like language as a
>>>> viable system implementation language ?
>>>
>>> I'm figuring this is it.  No such thing as a language that can do
>>> everything. Sometimes simpler is better.
>>
>> Programming languages are definitely not "one size fits all".
>>
>> I totally agree that simpler is better for programming languages.
>>
>> And this is not just you and me - very complex languages tend not
>> to prosper in the industry.
>>
>> But I don't think Simon's point was complex vs simple.
>>
>> More like structured vs goto style. and strong typing vs weak
>> typing.
>>
>> Because Ada is a complex language, but Pascal is actually a relative
>> simple language (at least in traditional form and in VMS flavor - Delphi
>> has sort of moved a bit in the complex direction).
>
> I like Pascal, but for something real I would probably prefer
> Modula-2. I have always loved that language!
>
> Arne
>
I totally agree. Modula-2 from ModulAware for OpenVMS VAX and Alpha were
great and the support was excellent. Unfortunately it was not ported to
Itanium, so we had to port our code from Modula-2 to C when we moved
from Alpha to Itanium in 2006. It was not a pleasure. And I think there
will be no version for x86, unfortunately.

--
Norbert

On Sunday, November 14, 2021 at 1:41:04 PM UTC-5, Simon Clubley wrote:
> On 2021-11-14, John Reagan <xyzz...@gmail.com> wrote:
> > On Friday, November 12, 2021 at 1:28:38 PM UTC-5, Simon Clubley wrote:
> >> On 2021-11-11, Robert A. Brooks <FIRST...@vmssoftware.com> wrote:
> >> > On 11/11/2021 4:01 PM, Arne Vajhøj wrote:
> >> >> On 11/11/2021 3:57 PM, Michael Moroney wrote:
> >> >
> >> >>> You remember correctly. The hardwired '24 line terminal' assumption pissed me
> >> >>> off and a few times I looked at it I said no way I can fix that spaghetti
> >> >>> code. But one day the planets were aligned or something, and I just did it.
> >> >>
> >> >> Macro-32 ?
> >> >
> >> > BLISS-32
> >> >
> >> Same difference. :-)
> >>
> >> On a more serious note, BLISS-32 was a nice idea, but it's at way too
> >> low a level to make a real difference.
> >>
> >> Now, if we had a Pascal-like or Ada-like language that could be used
> >> as a system implementation language... :-)
> >>
> >
> > Next time you post that, please add a "<Trigger warning for John Reagan>" at the top please.
> >
> Sorry, but I live in a country where we don't yet have to issue
> "trigger warnings" in everyday conversation. I don't know about
> the rest of Europe however.
>
> However, you have been way too quick to issue a "trigger warning"
> request without even telling me what "triggered" you. :-)
>
> Was it comparing BLISS-32 to Macro-32 ?
>
> Was it the desire to have a Pascal-like or Ada-like language as a
> viable system implementation language ?
>
> Was it something else ? :-)
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
HaHa Both actually. :)

While BLISS has many shortcomings, I really can't compare it to assembly language much less equating the two.

And I actually agree with you that many parts of modern OS's could/should be written in a type-safe language. Unfortunately, many of the algorithms inside of OpenVMS don't lend themselves to type-safe languages.