[Info-vax] Listeners in VMS Basic, was: Re: Integrity iLO Configuration?

[Arne Vajhøj]

On 7/1/2021 10:40 AM, Dave Froble wrote:
> On 7/1/2021 10:17 AM, Arne Vajhøj wrote:
>> On 7/1/2021 8:16 AM, Bill Gunshannon wrote:
>>> On 7/1/21 8:12 AM, Simon Clubley wrote:
>>>> For David, if it worked 30 years ago, then its good enough for today.
>>>> :-)
>>>
>>> In too many cases, that is quite true.  Change for changes sake
>>> is not an improvement.  And change to increase the ego of some
>>> academic is even worse.
>>
>> Technology constantly makes progress.
>>
>> Problem is to know what provides significant benefits versus
>> what is just nice to have and to know what will become long term viable
>> and what will turn out to be a dead end.
> 
> If something has been working successfully for 30 years, and is still 
> working successfully, would that not rule out any "dead ends"?

It is proof that the right choices was made 30 years ago.

It does not guarantee anything about the future.

But being right in the past should make being right in the future
slightly more likely.

> I've looked at some "progress".  Many times I've then asked, why is all 
> the bloat being used?  As an example, there are things that are piled on 
> top of a socket connection, instead of just using the socket connection. 
>   What do they achieve, other than slowing down the entire process? They 
> are not less work for the programmer, just lots of extra code.

I am not sure what you are talking about.

Adding SSL on top of sockets tend to add more code, but it also
provides something.

Other than that then network API's seems to get simpler
over time.

> I'm not saying there cannot be better methods, I'm saying that it really 
> must be better, or, it's not really progress.

Yep.

> As for Arne's example, whatever it does, it sure is not maintainable. If 
> code is not maintainable, what good is it?

It is an rtificial piece of code as it basically does a very
trivial operation (sum an array) 5 different ways and time them.

But the basic elements should be relative easy
]understandable by millions of developers.

Basically it contains:
* Basic syntax
* OOP
* arrays
* calls
* basic thread usage
* basic thread pool usage
* fluent API syntax

You noted the lack of comments, but there really should
only be a few explaining what the classes and methods do.
The rest is RTFM stuff.

The worst part is probably the unchecked and undocumented
requirement for correctness that array size is a multipla
of number treads/tasks. That could bit somebody.

Arne