On 5/19/22 19:52, Arne Vajhøj wrote:
> On 5/19/2022 3:17 PM, Bill Gunshannon wrote:
>> On 5/16/22 14:02, Simon Clubley wrote:
>>> On 2022-05-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> Rust and Go is what is new with some serious momentum/backing.
>>>>
>>>> If you are willing to go for more exotic options, then maybe
>>>> Hare will fit your requirements.
>>>
>>> Interesting. I wasn't aware of that one.
>>>
>>> No 32-bit ARM support however (or 32-bit support in general).
>>>
>>> It does appear to have some package/module based support.
>>
>> Just what the industry needs.  A few more ego languages.
>
> Programming languages is very much a matter of evolution.
>
> New languages show up all the time. Those that are good replace
> older languages. Those that are not good dies.
>
> What if Wirth and K&R had decided in the late 60's that
> Fortran, Cobol and PL/I had everything so no need for
> any "ego languages".
>

None of those languages do what the Wirth and K&R languages do.
Ignoring the fact that people took Pascal and C and proceeded
to use them for things they were not designed for and for which
there already were perfectly good languages.

What does Java do that other languages don't do (Other than the OOP
concept which I didn't drink the KoolAid for either)? Python? PHP?
Need I go on?

bill

On 5/19/2022 9:05 PM, Bill Gunshannon wrote:
> On 5/19/22 19:52, Arne Vajhøj wrote:
>> On 5/19/2022 3:17 PM, Bill Gunshannon wrote:
>>> On 5/16/22 14:02, Simon Clubley wrote:
>>>> On 2022-05-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> Rust and Go is what is new with some serious momentum/backing.
>>>>>
>>>>> If you are willing to go for more exotic options, then maybe
>>>>> Hare will fit your requirements.
>>>>
>>>> Interesting. I wasn't aware of that one.
>>>>
>>>> No 32-bit ARM support however (or 32-bit support in general).
>>>>
>>>> It does appear to have some package/module based support.
>>>
>>> Just what the industry needs.  A few more ego languages.
>>
>> Programming languages is very much a matter of evolution.
>>
>> New languages show up all the time. Those that are good replace
>> older languages. Those that are not good dies.
>>
>> What if Wirth and K&R had decided in the late 60's that
>> Fortran, Cobol and PL/I had everything so no need for
>> any "ego languages".
>
> None of those languages do what the Wirth and K&R languages do.

The wrote Multics in PL/I and OS is supposed to be C core
competency.

> Ignoring the fact that people took Pascal and C and proceeded
> to use them for things they were not designed for and for which
> there already were perfectly good languages.
>
> What does Java do that other languages don't do (Other than the OOP
> concept which I didn't drink the KoolAid for either)?  Python? PHP?
> Need I go on?

You may not like OOP but most do. Then there is generic programming.
Functional programming. Automatic garbage collection. Reflection.
Well defined types.

I have probably forgot a few things, but ...

Arne

On 5/19/2022 7:52 PM, Arne Vajhøj wrote:
> On 5/19/2022 3:17 PM, Bill Gunshannon wrote:
>> On 5/16/22 14:02, Simon Clubley wrote:
>>> On 2022-05-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> Rust and Go is what is new with some serious momentum/backing.
>>>>
>>>> If you are willing to go for more exotic options, then maybe
>>>> Hare will fit your requirements.
>>>
>>> Interesting. I wasn't aware of that one.
>>>
>>> No 32-bit ARM support however (or 32-bit support in general).
>>>
>>> It does appear to have some package/module based support.
>>
>> Just what the industry needs. A few more ego languages.
>
> Programming languages is very much a matter of evolution.
>
> New languages show up all the time. Those that are good replace
> older languages. Those that are not good dies.
>
> What if Wirth and K&R had decided in the late 60's that
> Fortran, Cobol and PL/I had everything so no need for
> any "ego languages".
>
> Arne

Are you saying existing languages cannot evolve, and get new and better
capabilities?

A while back this happened to DEC Basic. Lots of enhancements.

Afraid I have to agree with the "ego" thing ...

--
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 5/19/2022 10:22 PM, Dave Froble wrote:
> On 5/19/2022 7:52 PM, Arne Vajhøj wrote:
>> On 5/19/2022 3:17 PM, Bill Gunshannon wrote:
>>> On 5/16/22 14:02, Simon Clubley wrote:
>>>> On 2022-05-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> Rust and Go is what is new with some serious momentum/backing.
>>>>>
>>>>> If you are willing to go for more exotic options, then maybe
>>>>> Hare will fit your requirements.
>>>>
>>>> Interesting. I wasn't aware of that one.
>>>>
>>>> No 32-bit ARM support however (or 32-bit support in general).
>>>>
>>>> It does appear to have some package/module based support.
>>>
>>> Just what the industry needs.  A few more ego languages.
>>
>> Programming languages is very much a matter of evolution.
>>
>> New languages show up all the time. Those that are good replace
>> older languages. Those that are not good dies.
>>
>> What if Wirth and K&R had decided in the late 60's that
>> Fortran, Cobol and PL/I had everything so no need for
>> any "ego languages".
>
> Are you saying existing languages cannot evolve, and get new and better
> capabilities?

No, because that happens.

Fortran 66 to 77 added if block and character type (and changed
semantics of do loop).

C 89 to 99 added declaration anywhere and // comments.

Java 1.4 to 1.5 added enum, annotations and generics.
Java 1.6 to 1.7 added try with resources.
Java 1.7 to 1.8 added lambdas.
Java 9 to 10 added type inference.

C# 1.2 to 2.0 added generics.
C# 2.0 to 3.0 added type inference and lambdas.
C# 4.0 to 5.0 added async and await.
C# 7.3 to 8.0 added optional nun-nullable reference types.

C++ got a bunch of big changes that I will not try and list.

But languages are somewhat restricted by their original design and
compatibility requirements.

Minor enhancements are usually not a problem.

But major enhancements tend to either break existing
code or end up with some ugly solutions.

From the above list there are a couple of examples
of ugly solutions. Java generics does not look as
they would have if they had been done in 1.0 but at
the time for 1.5 there were so much existing code
that a compromise was needed and as result performance
of generics with simple data types sucks. Same with
Java lambdas - calling with lambda looks fine but
defining something to be callable with lambda
looks ridiculous in the code.

So languages can evolve but there are limitations.
Limitation that new languages does not have.

If we go over to VMS Basic, then VSI can easily add new
types and new functions. No problem. But could VSI
remove the variable name suffix does implicit typing
mechanism? I don't think so.

Arne

On 5/19/22 22:22, Dave Froble wrote:
> On 5/19/2022 7:52 PM, Arne Vajhøj wrote:
>> On 5/19/2022 3:17 PM, Bill Gunshannon wrote:
>>> On 5/16/22 14:02, Simon Clubley wrote:
>>>> On 2022-05-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> Rust and Go is what is new with some serious momentum/backing.
>>>>>
>>>>> If you are willing to go for more exotic options, then maybe
>>>>> Hare will fit your requirements.
>>>>
>>>> Interesting. I wasn't aware of that one.
>>>>
>>>> No 32-bit ARM support however (or 32-bit support in general).
>>>>
>>>> It does appear to have some package/module based support.
>>>
>>> Just what the industry needs.  A few more ego languages.
>>
>> Programming languages is very much a matter of evolution.
>>
>> New languages show up all the time. Those that are good replace
>> older languages. Those that are not good dies.
>>
>> What if Wirth and K&R had decided in the late 60's that
>> Fortran, Cobol and PL/I had everything so no need for
>> any "ego languages".
>>
>> Arne
>
> Are you saying existing languages cannot evolve, and get new and better
> capabilities?

No, existing languages can and do evolve. Turbo Pascal was greatly
enhanced from the Pascal described in the Jensen & Wirth book. Many
enhancements like an actual string. Sadly, because of abuse of the
original language he had to create another. But it certainly wasn't
for ego.

>
> A while back this happened to DEC Basic.  Lots of enhancements.

Yes, another good example. But it also could have been someone creating
B++ with a totally different syntax that was unnecessary.

>
> Afraid I have to agree with the "ego" thing ...
>

When people create languages that basically mimic other languages
but have totally different syntax and coding nuances what else
could it be?

bill

On 20/05/2022 13:16, Arne Vajhøj wrote:
> On 5/19/2022 10:22 PM, Dave Froble wrote:
>> On 5/19/2022 7:52 PM, Arne Vajhøj wrote:
>>> On 5/19/2022 3:17 PM, Bill Gunshannon wrote:
>>>> On 5/16/22 14:02, Simon Clubley wrote:
>>>>> On 2022-05-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>>> Rust and Go is what is new with some serious momentum/backing.
>>>>>>
>>>>>> If you are willing to go for more exotic options, then maybe
>>>>>> Hare will fit your requirements.
>>>>>
>>>>> Interesting. I wasn't aware of that one.
>>>>>
>>>>> No 32-bit ARM support however (or 32-bit support in general).
>>>>>
>>>>> It does appear to have some package/module based support.
>>>>
>>>> Just what the industry needs.  A few more ego languages.
>>>
>>> Programming languages is very much a matter of evolution.
>>>
>>> New languages show up all the time. Those that are good replace
>>> older languages. Those that are not good dies.
>>>
>>> What if Wirth and K&R had decided in the late 60's that
>>> Fortran, Cobol and PL/I had everything so no need for
>>> any "ego languages".
>>
>> Are you saying existing languages cannot evolve, and get new and
>> better capabilities?
>
> No, because that happens.
>
> Fortran 66 to 77 added if block and character type (and changed
> semantics of do loop).
>
> C 89 to 99 added declaration anywhere and // comments.
>
> Java 1.4 to 1.5 added enum, annotations and generics.
> Java 1.6 to 1.7 added try with resources.
> Java 1.7 to 1.8 added lambdas.
> Java 9 to 10 added type inference.
>
> C# 1.2 to 2.0 added generics.
> C# 2.0 to 3.0 added type inference and lambdas.
> C# 4.0 to 5.0 added async and await.
> C# 7.3 to 8.0 added optional nun-nullable reference types.
>
> C++ got a bunch of big changes that I will not try and list.
>
> But languages are somewhat restricted by their original design and
> compatibility requirements.
>
> Minor enhancements are usually not a problem.
>
> But major enhancements tend to either break existing
> code or end up with some ugly solutions.
>
> From the above list there are a couple of examples
> of ugly solutions. Java generics does not look as
> they would have if they had been done in 1.0 but at
> the time for 1.5 there were so much existing code
> that a compromise was needed and as result performance
> of generics with simple data types sucks. Same with
> Java lambdas - calling with lambda looks fine but
> defining something to be callable with lambda
> looks ridiculous in the code.
>
> So languages can evolve but there are limitations.
> Limitation that new languages does not have.
>
> If we go over to VMS Basic, then VSI can easily add new
> types and new functions. No problem. But could VSI
> remove the variable name suffix does implicit typing
> mechanism? I don't think so.
>
> Arne
>

Easy - just enforce OPTION TYPE = EXPLICIT

--
Chris

On 5/20/2022 8:22 AM, Chris Townley wrote:
> On 20/05/2022 13:16, Arne Vajhøj wrote:
>> If we go over to VMS Basic, then VSI can easily add new
>> types and new functions. No problem. But could VSI
>> remove the variable name suffix does implicit typing
>> mechanism? I don't think so.
>
> Easy - just enforce OPTION TYPE = EXPLICIT

It is not a technical problem to implement but a customer
problem.

I am sure John Reagan could make the change in 10 minutes.

But VSI would need to get him bodyguards for the rest
of his life to protect him against angry VMS Basic users.

:-)

Arne

On 5/19/22 21:49, Arne Vajhøj wrote:
> On 5/19/2022 9:05 PM, Bill Gunshannon wrote:
>> On 5/19/22 19:52, Arne Vajhøj wrote:
>>> On 5/19/2022 3:17 PM, Bill Gunshannon wrote:
>>>> On 5/16/22 14:02, Simon Clubley wrote:
>>>>> On 2022-05-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>>> Rust and Go is what is new with some serious momentum/backing.
>>>>>>
>>>>>> If you are willing to go for more exotic options, then maybe
>>>>>> Hare will fit your requirements.
>>>>>
>>>>> Interesting. I wasn't aware of that one.
>>>>>
>>>>> No 32-bit ARM support however (or 32-bit support in general).
>>>>>
>>>>> It does appear to have some package/module based support.
>>>>
>>>> Just what the industry needs.  A few more ego languages.
>>>
>>> Programming languages is very much a matter of evolution.
>>>
>>> New languages show up all the time. Those that are good replace
>>> older languages. Those that are not good dies.
>>>
>>> What if Wirth and K&R had decided in the late 60's that
>>> Fortran, Cobol and PL/I had everything so no need for
>>> any "ego languages".
>>
>> None of those languages do what the Wirth and K&R languages do.
>
> The wrote Multics in PL/I and OS is supposed to be C core
> competency.

They could have written it in PL/M. Even Ada or Pascal. No task
is limited to just one language. Part of Software Engineering is
supposed to be picking the right tool for the job. Never having
played with Multics source I can't say why they chose the language
they did but there may have been a good reason. Who knows, that
early in the game maybe there was limited C experience. Was Multics
heavily loaded with IBMers? That could easily influence the use
of PL/I over C.

>
>> Ignoring the fact that people took Pascal and C and proceeded
>> to use them for things they were not designed for and for which
>> there already were perfectly good languages.
>>
>> What does Java do that other languages don't do (Other than the OOP
>> concept which I didn't drink the KoolAid for either)?  Python? PHP?
>> Need I go on?
>
> You may not like OOP but most do.

I blame academia for that. :-)
I remember reading article a number of years ago on a meeting of all
the big names in OOP at an international OOP conference where they
admitted that the whole OOP thing had gotten out of hand and what
resulted was not what was intended.

> Then there is generic programming.
> Functional programming. Automatic garbage collection. Reflection.
> Well defined types.

Hmmm. Garbage collection is done different ways on different systems.
It wasn't a new idea and other languages did have it. Like Lisp.
Unless you have a different meaning for functional programming than
what I learned, lots of languages had that. Generic programming, same
thing, really. Pascal (in its misused manner), Modula, even C are all
capable of generic programming. Well defined types? Pascal, Modula,
Ada and even C where the builtin types are very well defined. You just
have ability to define more.

>
> I have probably forgot a few things, but ...

And, I think we look at a lot of this in a very different manner.
But that would be expected as we both come from very different
backgrounds, educations and experiences.

bill

On 5/20/22 08:29, Arne Vajhøj wrote:
> On 5/20/2022 8:22 AM, Chris Townley wrote:
>> On 20/05/2022 13:16, Arne Vajhøj wrote:
>>> If we go over to VMS Basic, then VSI can easily add new
>>> types and new functions. No problem. But could VSI
>>> remove the variable name suffix does implicit typing
>>> mechanism? I don't think so.
>>
>> Easy - just enforce OPTION TYPE = EXPLICIT
>
> It is not a technical problem to implement but a customer
> problem.
>
> I am sure John Reagan could make the change in 10 minutes.
>
> But VSI would need to get him bodyguards for the rest
> of his life to protect him against angry VMS Basic users.
>
> :-)

Thus what I meant about background, education and experience being
great influencers. I, personally, do not believe in IMPLICIT anything.
Even in Fortran I always explicitly declared all of my variables.
Trust no one, especially compilers. :-)

bill

On 5/20/2022 8:16 AM, Arne Vajhøj wrote:

> If we go over to VMS Basic, then VSI can easily add new
> types and new functions. No problem. But could VSI
> remove the variable name suffix does implicit typing
> mechanism? I don't think so.
>
> Arne
>

Why would you want to remove something that perhaps some users want to continue
to use? Leaving it doesn't hurt, and users can choose to not use it.

Starting with something existing is easier than starting from scratch. There is
nothing, other than omissions and restrictions, in any of the ego languages that
cannot be implemented in say, Basic. Since much of the compiler exists, that
work is already done, and only modifications need to be implemented.

It's ego. And perhaps so is coming up with meaningless objections, such as
yours above.

--
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 5/20/2022 8:22 AM, Chris Townley wrote:
> On 20/05/2022 13:16, Arne Vajhøj wrote:
>> On 5/19/2022 10:22 PM, Dave Froble wrote:
>>> On 5/19/2022 7:52 PM, Arne Vajhøj wrote:
>>>> On 5/19/2022 3:17 PM, Bill Gunshannon wrote:
>>>>> On 5/16/22 14:02, Simon Clubley wrote:
>>>>>> On 2022-05-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>>>> Rust and Go is what is new with some serious momentum/backing.
>>>>>>>
>>>>>>> If you are willing to go for more exotic options, then maybe
>>>>>>> Hare will fit your requirements.
>>>>>>
>>>>>> Interesting. I wasn't aware of that one.
>>>>>>
>>>>>> No 32-bit ARM support however (or 32-bit support in general).
>>>>>>
>>>>>> It does appear to have some package/module based support.
>>>>>
>>>>> Just what the industry needs. A few more ego languages.
>>>>
>>>> Programming languages is very much a matter of evolution.
>>>>
>>>> New languages show up all the time. Those that are good replace
>>>> older languages. Those that are not good dies.
>>>>
>>>> What if Wirth and K&R had decided in the late 60's that
>>>> Fortran, Cobol and PL/I had everything so no need for
>>>> any "ego languages".
>>>
>>> Are you saying existing languages cannot evolve, and get new and better
>>> capabilities?
>>
>> No, because that happens.
>>
>> Fortran 66 to 77 added if block and character type (and changed
>> semantics of do loop).
>>
>> C 89 to 99 added declaration anywhere and // comments.
>>
>> Java 1.4 to 1.5 added enum, annotations and generics.
>> Java 1.6 to 1.7 added try with resources.
>> Java 1.7 to 1.8 added lambdas.
>> Java 9 to 10 added type inference.
>>
>> C# 1.2 to 2.0 added generics.
>> C# 2.0 to 3.0 added type inference and lambdas.
>> C# 4.0 to 5.0 added async and await.
>> C# 7.3 to 8.0 added optional nun-nullable reference types.
>>
>> C++ got a bunch of big changes that I will not try and list.
>>
>> But languages are somewhat restricted by their original design and
>> compatibility requirements.
>>
>> Minor enhancements are usually not a problem.
>>
>> But major enhancements tend to either break existing
>> code or end up with some ugly solutions.
>>
>> From the above list there are a couple of examples
>> of ugly solutions. Java generics does not look as
>> they would have if they had been done in 1.0 but at
>> the time for 1.5 there were so much existing code
>> that a compromise was needed and as result performance
>> of generics with simple data types sucks. Same with
>> Java lambdas - calling with lambda looks fine but
>> defining something to be callable with lambda
>> looks ridiculous in the code.
>>
>> So languages can evolve but there are limitations.
>> Limitation that new languages does not have.
>>
>> If we go over to VMS Basic, then VSI can easily add new
>> types and new functions. No problem. But could VSI
>> remove the variable name suffix does implicit typing
>> mechanism? I don't think so.
>>
>> Arne
>>
>
> Easy - just enforce OPTION TYPE = EXPLICIT
>

See, already an option. But, I'm not too fond of the concept of "enforce".
I'll do my own enforcing.

--
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 20/05/2022 15:13, Dave Froble wrote:
> On 5/20/2022 8:22 AM, Chris Townley wrote:

>>
>> Easy - just enforce OPTION TYPE = EXPLICIT
>>
>
> See, already an option.  But, I'm not too fond of the concept of
> "enforce". I'll do my own enforcing.
>

In our team, it as required for any Vax/Dec Basic modules.
I also frowned on assuming default initialisation of variables, and
would pick it up in any code review

--
Chris

On 5/20/22 10:40, Chris Townley wrote:
> On 20/05/2022 15:13, Dave Froble wrote:
>> On 5/20/2022 8:22 AM, Chris Townley wrote:
>
>>>
>>> Easy - just enforce OPTION TYPE = EXPLICIT
>>>
>>
>> See, already an option.  But, I'm not too fond of the concept of
>> "enforce". I'll do my own enforcing.
>>
>
> In our team, it as required for any Vax/Dec Basic modules.
> I also frowned on assuming default initialisation of variables, and
> would pick it up in any code review
>

So, tell me, what year did you start in the IT biz?

bill

On 20/05/2022 15:49, Bill Gunshannon wrote:
> On 5/20/22 10:40, Chris Townley wrote:
>> On 20/05/2022 15:13, Dave Froble wrote:
>>> On 5/20/2022 8:22 AM, Chris Townley wrote:
>>
>>>>
>>>> Easy - just enforce OPTION TYPE = EXPLICIT
>>>>
>>>
>>> See, already an option.  But, I'm not too fond of the concept of
>>> "enforce". I'll do my own enforcing.
>>>
>>
>> In our team, it as required for any Vax/Dec Basic modules.
>> I also frowned on assuming default initialisation of variables, and
>> would pick it up in any code review
>>
>
> So, tell me, what year did you start in the IT biz?
>
> bill
>

80s

--
Chris

On 5/20/2022 10:10 AM, Dave Froble wrote:
> On 5/20/2022 8:16 AM, Arne Vajhøj wrote:
>> If we go over to VMS Basic, then VSI can easily add new
>> types and new functions. No problem. But could VSI
>> remove the variable name suffix does implicit typing
>> mechanism? I don't think so.
>
> Why would you want to remove something that perhaps some users want to
> continue to use?  Leaving it doesn't hurt, and users can choose to not
> use it.
>
> Starting with something existing is easier than starting from scratch.
> There is nothing, other than omissions and restrictions, in any of the
> ego languages that cannot be implemented in say, Basic.  Since much of
> the compiler exists, that work is already done, and only modifications
> need to be implemented.
>
> It's ego.  And perhaps so is coming up with meaningless objections, such
> as yours above.

The point is that backwards compatibility requirements impact
what languages can do.

And that sometimes makes it better to start from scratch.

Arne

On 5/20/2022 8:40 AM, Bill Gunshannon wrote:
> On 5/19/22 21:49, Arne Vajhøj wrote:
>> On 5/19/2022 9:05 PM, Bill Gunshannon wrote:
>>> Ignoring the fact that people took Pascal and C and proceeded
>>> to use them for things they were not designed for and for which
>>> there already were perfectly good languages.
>>>
>>> What does Java do that other languages don't do (Other than the OOP
>>> concept which I didn't drink the KoolAid for either)?  Python? PHP?
>>> Need I go on?
>>
>> You may not like OOP but most do.
>
> I blame academia for that. :-)
> I remember reading article a number of years ago on a meeting of all
> the big names in OOP at an international OOP conference where they
> admitted that the whole OOP thing had gotten out of hand and what
> resulted was not what was intended.

You could not write the software of today without it.

>>                                   Then there is generic programming.
>> Functional programming. Automatic garbage collection. Reflection.
>> Well defined types.
>
> Hmmm.   Garbage collection is done different ways on different systems.
> It wasn't a new idea and other languages did have it.  Like Lisp.

Java did not invent GC, but it was the first really widely used
language using it.

> Unless you have a different meaning for functional programming than
> what I learned, lots of languages had that.

FP today is pretty well defined. Methods expecting functions, callers
specifying lambdas, optionally currying and partially applied functions.

>   Generic programming, same
> thing, really.  Pascal (in its misused manner), Modula, even C are all
> capable of generic programming.

????

Except newer Delphi then I have not seen that.

>   Well defined types?  Pascal, Modula,
> Ada and even C where the builtin types are very well defined.  You just
> have ability to define more.

Neither Pascal nor C have well defined types in the standard.

The size of integer in bits and one or two complement is
implementation specific.

Arne

On 5/20/22 11:42, Chris Townley wrote:
> On 20/05/2022 15:49, Bill Gunshannon wrote:
>> On 5/20/22 10:40, Chris Townley wrote:
>>> On 20/05/2022 15:13, Dave Froble wrote:
>>>> On 5/20/2022 8:22 AM, Chris Townley wrote:
>>>
>>>>>
>>>>> Easy - just enforce OPTION TYPE = EXPLICIT
>>>>>
>>>>
>>>> See, already an option.  But, I'm not too fond of the concept of
>>>> "enforce". I'll do my own enforcing.
>>>>
>>>
>>> In our team, it as required for any Vax/Dec Basic modules.
>>> I also frowned on assuming default initialisation of variables, and
>>> would pick it up in any code review
>>>
>>
>> So, tell me, what year did you start in the IT biz?
>>
>> bill
>>
>
> 80s
>

Thank you. That's what I figured. It shows.
Oh, and if you don't get it, that is a compliment.

It was the 1980 when I really got into IT even though
I actually started in the very early 70's. We learned
a lot of things different (I think better) back then.

bill

On 2022-05-20, Dave Froble <davef@tsoft-inc.com> wrote:
> On 5/20/2022 8:16 AM, Arne Vajhøj wrote:
>
>> If we go over to VMS Basic, then VSI can easily add new
>> types and new functions. No problem. But could VSI
>> remove the variable name suffix does implicit typing
>> mechanism? I don't think so.
>>
>> Arne
>>
>
> Why would you want to remove something that perhaps some users want to continue
> to use? Leaving it doesn't hurt, and users can choose to not use it.
>

Because you want to remove dangerous features to force people to write
more robust code.

Hollerith constants (for example) have been removed from all current
Fortran compilers and for _very_ good reasons.

> Starting with something existing is easier than starting from scratch. There is
> nothing, other than omissions and restrictions, in any of the ego languages that
> cannot be implemented in say, Basic. Since much of the compiler exists, that
> work is already done, and only modifications need to be implemented.
>
> It's ego. And perhaps so is coming up with meaningless objections, such as
> yours above.
>

Sometimes yes, sometimes no.

Ada was created from scratch because none of the existing languages
at the time met the requirements of the US government.

Creating Ada was very much the right thing for the US government to
do at the time.

Likewise, creating Pillar was very much the right thing for DEC to
do at the time and if PRISM had not been cancelled, we would now
have another established programming 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-05-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> Neither Pascal nor C have well defined types in the standard.
>
> The size of integer in bits and one or two complement is
> implementation specific.
>

These days, I avoid this problem in my C code by using the uint[8/16/32]_t
(and friends) data types.

Simon.

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

On 5/20/2022 8:19 AM, Bill Gunshannon wrote:
> When people create languages that basically mimic other languages
> but have totally different syntax and coding nuances what else
> could it be?

The languages that started this thread certainly did not mimic
existing languages.

Rust - low level, well defined types (bit size), generic
programming, closures, safe/unsafe mode, memory ownership
model, traits, type inference etc.

Go - low level, well defined types (bit size), generic
programming, garbage collection, goroutines for
massive multi-threading, type inference etc.

Does not in any way look like C or C++.

(disclaimer: above feature list are features in those
languages today not features when the languages were
released)

Arne

On 5/20/2022 1:44 PM, Simon Clubley wrote:
> On 2022-05-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> Neither Pascal nor C have well defined types in the standard.
>>
>> The size of integer in bits and one or two complement is
>> implementation specific.
>
> These days, I avoid this problem in my C code by using the uint[8/16/32]_t
> (and friends) data types.

Which is as good as you can do in C.

But note that their existence is optional, if the system does
not have 32 bit integers then they don't exist.

And intN_t is guaranteed to be two's complement but uintN_T is not.

Arne

On 20/05/2022 17:05, Bill Gunshannon wrote:
> On 5/20/22 11:42, Chris Townley wrote:
>> On 20/05/2022 15:49, Bill Gunshannon wrote:
>>> On 5/20/22 10:40, Chris Townley wrote:
>>>> On 20/05/2022 15:13, Dave Froble wrote:
>>>>> On 5/20/2022 8:22 AM, Chris Townley wrote:
>>>>
>>>>>>
>>>>>> Easy - just enforce OPTION TYPE = EXPLICIT
>>>>>>
>>>>>
>>>>> See, already an option.  But, I'm not too fond of the concept of
>>>>> "enforce". I'll do my own enforcing.
>>>>>
>>>>
>>>> In our team, it as required for any Vax/Dec Basic modules.
>>>> I also frowned on assuming default initialisation of variables, and
>>>> would pick it up in any code review
>>>>
>>>
>>> So, tell me, what year did you start in the IT biz?
>>>
>>> bill
>>>
>>
>> 80s
>>
>
> Thank you.  That's what I figured.  It shows.
> Oh, and if you don't get it, that is a compliment.
>
> It was the 1980 when I really got into IT even though
> I actually started in the very early 70's.  We learned
> a lot of things different (I think better) back then.
>
> bill

I know what you mean!

I actually started in a small way in 1965, being taught (without access
to a system) some form of assembler - aged 13! That along with binary
logic was very useful later

--
Chris

On 2022-05-20 20:03, Arne Vajhøj wrote:
> On 5/20/2022 1:44 PM, Simon Clubley wrote:
>> On 2022-05-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> Neither Pascal nor C have well defined types in the standard.
>>>
>>> The size of integer in bits and one or two complement is
>>> implementation specific.
>>
>> These days, I avoid this problem in my C code by using the
>> uint[8/16/32]_t
>> (and friends) data types.
>
> Which is as good as you can do in C.
>
> But note that their existence is optional, if the system does
> not have 32 bit integers then they don't exist.

Well, if the system don't have 32 bit integers, then the code is doomed
to fail anyway, and it's good that it fails at compilation.

> And intN_t is guaranteed to be two's complement but uintN_T is not.

I would hope that an uintN_t is guaranteed to *not* be two complement.
It would sortof defeat the meaning of the 'u' if it was two complement.

Johnny

On 5/20/22 14:06, Chris Townley wrote:
> On 20/05/2022 17:05, Bill Gunshannon wrote:
>> On 5/20/22 11:42, Chris Townley wrote:
>>> On 20/05/2022 15:49, Bill Gunshannon wrote:
>>>> On 5/20/22 10:40, Chris Townley wrote:
>>>>> On 20/05/2022 15:13, Dave Froble wrote:
>>>>>> On 5/20/2022 8:22 AM, Chris Townley wrote:
>>>>>
>>>>>>>
>>>>>>> Easy - just enforce OPTION TYPE = EXPLICIT
>>>>>>>
>>>>>>
>>>>>> See, already an option.  But, I'm not too fond of the concept of
>>>>>> "enforce". I'll do my own enforcing.
>>>>>>
>>>>>
>>>>> In our team, it as required for any Vax/Dec Basic modules.
>>>>> I also frowned on assuming default initialisation of variables, and
>>>>> would pick it up in any code review
>>>>>
>>>>
>>>> So, tell me, what year did you start in the IT biz?
>>>>
>>>> bill
>>>>
>>>
>>> 80s
>>>
>>
>> Thank you.  That's what I figured.  It shows.
>> Oh, and if you don't get it, that is a compliment.
>>
>> It was the 1980 when I really got into IT even though
>> I actually started in the very early 70's.  We learned
>> a lot of things different (I think better) back then.
>>
>> bill
>
> I know what you mean!
>
> I actually started in a small way in 1965, being taught (without access
> to a system) some form of assembler - aged 13! That along with binary
> logic was very useful later
>

I started as a night shift operator on an IBM 1401 in Germany
in my first Army days. A senior NCO used to come in and run
a program at night that took several hours. During that time
he was nice enough to teach me Autocoder. Then I got out of
the Army to go to college. Only computer job I could get was
running card (actually, check) sorting machines night shift
in a bank. Pay sucked (tellers made more than the IT staff).
Work was boring. I was unimpressed with the IT world and
went back to working in a factory. In 1976 I went back in the
Army. Third hitch in 1980 found me becoming a Programmer/Analyst
and the rest, as they say, is history. Been an Applications
Programmer, Systems Programmer, Systems Engineer, Network
Engineer and an Academician. Been a wild and crazy ride.

bill

Bill Gunshannon <bill.gunshannon@gmail.com> writes:

> On 5/19/22 21:49, Arne Vajhøj wrote:

>> The wrote Multics in PL/I and OS is supposed to be C core
>> competency.

> They could have written it in PL/M. Even Ada or Pascal. No task
> is limited to just one language. Part of Software Engineering is
> supposed to be picking the right tool for the job. Never having
> played with Multics source I can't say why they chose the language
> they did but there may have been a good reason. Who knows, that
> early in the game maybe there was limited C experience. Was Multics
> heavily loaded with IBMers? That could easily influence the use
> of PL/I over C.

Multics was developed on the GE 645 (an extended 635) in the mid-1960s, in the
MIT lab which created CTSS on the IBM 7094, so I suppose you could call them
"IBMers" but I wouldn't. Funding came from GE (later Honeywell) and AT&T.

PL/I was the new language on the block, with a lot of bit-fiddling features not
found in FORTRAN of COBOL, combined with Algol-inspired block structures, which
made it interesting for an experimental OS. There was still a lot of assembler
in the low level.

The idea for writing OSes in languages at a higher level than assembler, such
as C, came from Thompson and Ritchie's experience with Multics.

None of those other languages existed.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen