On 10/15/2021 8:37 AM, Arne Vajhøj wrote:
> On 10/15/2021 2:03 AM, Phillip Helbig (undress to reply) wrote:
>> In article <6168b9b9$0$700$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>>> On 10/14/2021 3:42 PM, Dave Froble wrote:
>>>> On 10/14/2021 2:36 PM, Arne VajhÞj wrote:
>>>>> On 10/14/2021 2:06 PM, Simon Clubley wrote:
>>>>>> BTW, Basic really does like spewing its special characters onto the
>>>>>> end of variable references. :-)
>>>
>>>> Basic can be very happy to let the programmer specify that all variables
>>>> must be declared. Then variable names can be whatever they are declared
>>>> to be. Frankly, I see no decent reason to do all that typing when the
>>>> compiler can do a much better job than any programmer. One just needs to
>>>> give it some hints. I learned the variable suffex stuff long ago, and
>>>> it's just natural to me. Just as conventions in another language might
>>>> be natural to someone used to that language.
>>>
>>> Having variable type determined by variable name is definitely
>>> out of fashion. The only other language i know doing that is
>>> Fortran (Fortran is first letter while Basic is suffix but
>>> same concept).
>
>> In Fortran, the implicit typing is only for INTEGER and REAL; it doesn't
>> work for other data types.
>
> In VMS Basic suffix only works for integer and string.
>
> Arne
>
>

Not quite. Lack of suffix implies a REAL.

--
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 10/14/2021 9:56 PM, Dave Froble wrote:
> On 10/14/2021 7:20 PM, Arne Vajhøj wrote:
>> On 10/14/2021 3:36 PM, Dave Froble wrote:
>>> Did I mention I don't like C, and most likely would not like Ada?
>>
>> What languages do you like besides Basic?
>
> Basic is the only language I sort of like.  I've done others when I
> needed to.
>
> Basic is the only language my IDE supports.
>
> Haven't found much I cannot do in Basic.
>
> Basic isn't very performance oriented.

VMS Basic is probably way more performance oriented than
all script languages: Python, PHP etc. (at least as long
they get interpreted and not JIT compiled in VM).

:-)

Arne

On 10/14/2021 10:10 PM, Lawrence D’Oliveiro wrote:
> On Friday, October 15, 2021 at 2:36:27 PM UTC+13, Arne Vajhøj wrote:
>> On 10/14/2021 9:11 PM, Lawrence D’Oliveiro wrote:
>>> And VMS can do the same thing. All the compatibility stuff can live in userland.
>>
>> I am having a hard time seeing: VMS scheduling, VMS memory protection,
>> VMS clustering, ...
>
> None of which are relevant, because Linux already offers better functionality in all those areas.

All of which are relevant, because without them it would not be VMS.

>> DECnet, LAT ...
>
> They can be implemented in userland. If Netatalk can implement AppleTalk entirely in userland, why not them?

DECnet is a bit possessive with NIC's - first thing it does is to change
the MAC address.

>> ... device handling ...
>
> Unneeded, since Linux already has the needed device drivers.

Not enough for existing code and scripts to work.

>> ... ODS-2 & ODS-5 ...
>
> New filesystems don’t have to be implemented as kernel modules, they could be done via FUSE.

Maybe.

>> 4 mode logicals etc ...
>
> Name services can be provided via a daemon communicating via, e.g. D-Bus. PF_UNIX sockets allow you to control access based on the credentials of the process you are talking to.

Maybe.

Arne

On 10/15/21 2:03 AM, Phillip Helbig (undress to reply) wrote:
> In article <6168b9b9$0$700$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>> On 10/14/2021 3:42 PM, Dave Froble wrote:
>>> On 10/14/2021 2:36 PM, Arne VajhÞj wrote:
>>>> On 10/14/2021 2:06 PM, Simon Clubley wrote:
>>>>> BTW, Basic really does like spewing its special characters onto the
>>>>> end of variable references. :-)
>>
>>> Basic can be very happy to let the programmer specify that all variables
>>> must be declared.  Then variable names can be whatever they are declared
>>> to be.  Frankly, I see no decent reason to do all that typing when the
>>> compiler can do a much better job than any programmer.  One just needs to
>>> give it some hints.  I learned the variable suffex stuff long ago, and
>>> it's just natural to me.  Just as conventions in another language might
>>> be natural to someone used to that language.
>>
>> Having variable type determined by variable name is definitely
>> out of fashion. The only other language i know doing that is
>> Fortran (Fortran is first letter while Basic is suffix but
>> same concept).
>>
>> But type inference is definitely in fashion.
>>
>> var v = 123
>>
>> instead of:
>>
>> int v = 123
>>
>> and:
>>
>> var v = "ABC"
>>
>> instead of:
>>
>> String v = "ABC"
>>
>> And for those that does not use languages less than 30 years
>> old: var means "dear compiler give this variable type based on
>> right hand side" not "I want to be able to assign anything to this
>> variable".
>
> In Fortran, the implicit typing is only for INTEGER and REAL; it doesn't
> work for other data types.
>

Relying on anything IMPLICIT is just bad programming practice.
I thought the languages settled that decades ago.

bill

On 10/15/2021 12:29 PM, Bill Gunshannon wrote:
> On 10/15/21 2:03 AM, Phillip Helbig (undress to reply) wrote:
>> In Fortran, the implicit typing is only for INTEGER and REAL; it doesn't
>> work for other data types.
>
> Relying on anything IMPLICIT is just bad programming practice.
> I thought the languages settled that decades ago.

I think it was settled like 1970-1995.

Since then loosely typed languages and type inference
has become widely used.

You may not like it, but ...

Arne

On 10/15/21 01:51, Lawrence D’Oliveiro wrote:
> On Friday, October 15, 2021 at 1:15:31 AM UTC+13, chris wrote:
>> Comparing Apples to Oranges is rarely productive...
>
> Because of course the rise of the automobile made no difference to the market for buggy whips, did it ...

Apparently, buggy whips still seem to sell well, but have no
knowledge of horse related use, or other potential applications...

Chris

On 2021-10-14, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
> On Friday, October 15, 2021 at 7:32:33 AM UTC+13, Simon Clubley wrote:
>> On 2021-10-13, Lawrence D?Oliveiro <lawren...@gmail.com> wrote:
>>> On Thursday, October 14, 2021 at 7:14:08 AM UTC+13, Simon Clubley wrote:
>>>>
>>>> Microkernels have moved on and microkernels have massive security advantages.
>>>
>>> Counterexample: Intel?s infamous Management Engine that exerts total control
>>> over its CPUs, that the OS cannot bypass, runs microkernel-based MINIX, and
>>> turned out to have massive security holes in it.
>>>
>> Wasn't that due to the applications running on top of Minix instead of
>> Minix itself ?
>>
>> The massive advantage of microkernels is that code which would otherwise
>> be in a shared fully privileged kernel address space is in fact isolated
>> in its own address space with far fewer access rights to other parts of
>> the system.
>
> But these separate processes are still able to compromise system security, as happened with the Intel MINIX example? So where exactly is the ?massive advantage? in security?
>

In that things which would operate in a privileged shared address space
environment in a normal monolithic kernel (such as drivers) would be
isolated in a microkernel. That's where the benefits come from.

>>> The fact that DCL runs in supervisor mode is an internal implementation matter.
>>> It could be replaced by a thread or an entirely separate process (even a privileged
>>> one), for example, and what difference would that make to user-mode code?
>>>
>> Unlike the Unix shells you are clearly thinking of, DCL provides services
>> to a program directly while the program is running.
>
> The same thing can be done from a separate thread or process.
>

Not with how DCL is currently implemented.

>>> ... as far as I know there is no user-controlled code in DCL.
>>
>> _Normally_, there isn't. :-)
>>
>> The point of my comments is that DCL needs to operate in a more
>> privileged environment than is available to user-mode code.
>
> I don?t understand why, unless it is to get around limitations of the current VMS design. Once you free yourself from that, you no longer need to structure your solutions the same way.
>
> Replace ?DCL? with ?process that is longer-lived than most user programs? and you will see what I mean. In the *nix world, we just call that a ?shell?.
>
>> In the current design, you can't fold user-mode code into DCL's
>> supervisor mode or move DCL into user mode without having a total
>> breakdown in system security, hence you need an extra mode other
>> than the normal KU modes to run DCL in.
>
> Scrap that current design, then.

If you had been reading comp.os.vms for the last few years Lawrence,
you would know that I have made multiple suggestions in exactly this
area. I suspect I've annoyed multiple VSI employees with my rather
firm negative opinions on this part of VMS.

Simon.

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

On 2021-10-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 10/14/2021 10:10 PM, Lawrence D?Oliveiro wrote:
>> On Friday, October 15, 2021 at 2:36:27 PM UTC+13, Arne Vajhøj wrote:
>>> On 10/14/2021 9:11 PM, Lawrence D?Oliveiro wrote:
>>>> And VMS can do the same thing. All the compatibility stuff can live in userland.
>>>
>>> I am having a hard time seeing: VMS scheduling, VMS memory protection,
>>> VMS clustering, ...
>>
>> None of which are relevant, because Linux already offers better functionality in all those areas.
>
> All of which are relevant, because without them it would not be VMS.
>

I wonder if Lawrence has compared VMS clustering functionality with
the clustering functionality offered elsewhere. The gap has got closer
in recent years but there's a reason why everyone looks to VMS as the
model to emulate when it comes to clustering.

>>> ... ODS-2 & ODS-5 ...
>>
>> New filesystems don?t have to be implemented as kernel modules, they could be done via FUSE.
>
> Maybe.
>

FUSE filesystems come with performance limitations on Linux.

Besides, running a driver in user mode sounds like the kind of thing
that a microkernel would do. I thought Lawrence didn't like that kind
of thing ? :-)

On a more serious note, adding a new filesystem to Linux as a kernel
module is a much easier thing to do on Linux than on VMS. Having written
Linux kernel modules in the past, I don't see writing a filesystem as
a kernel module as being much more difficult than as a FUSE module.

Simon.

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

On 2021-10-14, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
>
> If you want to look at which is the single biggest company that is contributing to Linux, that would have to be Microsoft.
>
> Which is the most popular Linux distro in the world today? Hard to tell, but it isn?t anything from Red Hat. Ubuntu most likely, and they are certainly getting very cosy with Microsoft.
>

When answering that question, you need to think about the market segment
you want to run Linux in.

Business servers have different requirements than consumer and desktop
machines.

Simon.

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

On 10/15/2021 2:01 PM, Simon Clubley wrote:
> On a more serious note, adding a new filesystem to Linux as a kernel
> module is a much easier thing to do on Linux than on VMS. Having written
> Linux kernel modules in the past, I don't see writing a filesystem as
> a kernel module as being much more difficult than as a FUSE module.

But for a kernel module it is either GPL or the shim trick.

Arne

On 10/15/21 02:07, Lawrence D’Oliveiro wrote:
> On Friday, October 15, 2021 at 12:55:18 AM UTC+13, chris wrote:
>>
>> On 10/14/21 01:29, Lawrence D’Oliveiro wrote:
>>>
>>> There are no such things as “power grabs” in Free software.
>>
>> Perhaps, but the amount of money and effort that Red Hat (now owned
>> by IBM btw) put into Linux means they have disproportionate amount of
>> influence in the direction of the project.
>
> If you want to look at which is the single biggest company that is contributing to Linux, that would have to be
Microsoft.

Well, warning, that may eventually be the kiss of death for Linux.
What was the saying about uSoft getting involved with other
companies ?. Something about assimilate and suppress :-). Even more
reason to avoid Linux.

>
> Which is the most popular Linux distro in the world today? Hard to tell, but it isn’t anything from Red Hat. Ubuntu most likely, and they are certainly getting very cosy with Microsoft.
>

No idea which is the most popular, but it isn't show business after
all, nor willy waving :-).

Already told you. Check out the service management facility in Solaris
10 for example. FreeBSD also has lightweight service control commands
that interface with the underlying init framework and running
process management. Far more lightweight and less complex than systemd.
But, if that's what rocks your boat, then stick with it.

As for coding, do plenty of that as well, but more for fun these days,
so can afford to pick and choose and be more critical.

>
> That you can easily display entries in any timezone, just by setting “TZ=«timezone»” at the front of the command.
>

So what, and how is that relevant to this discussion ?.

>> Well, do occasionally rebuild kernels, but an OS is here primarily to
>> enable productive work, not spend all day configuring or debugging it.
>
> In other words, you prefer to complain rather than to take effective action about it.
>

Well, years ago, most were stuck with the hw vendors OS, but there's
a vast range of quality open source to choose from now, so yes, make
choices, just like everyone else. Working on some open source projects
here, ntp and instrument control related, but am primarily a user
of os's. That doesn't stop me from making comparisons. So, what
contribution do you make, other than trolling against VMS ?.

>
> Umm, Netgate dropped from FreeBSD? But they practically *are* FreeBSD. And which “individual”? There are a number of individuals associated with the company, who have done dubious things as reported in the article. Which you did read the whole of, didn’t you?
>

Need some documentary evidence for that, not just arm waving. For
example, individuals within the FreeBSD leadership and how they are
connected to Netgate financially

>
> I am told that the pfSense developers have admitted that, were they to start again today, they would use

Linux as the basis of their product, not FreeBSD. Back in the day, the
BSDs had the high-performance,

configurable network stack that others envied, but not any more.

Good for them, even more reason to avoid them. The rest is just
hearsay.

I've seen a fair amount of embedded Linux, but none of those versions
included systemd, nor a lot of the other cruft that current distros
suffer from. Stripped down to a bare minimum for embedded work, which is
what we do here. There again, you can run FreeBSD from a memstick as
well and it is already real time ready, something Linux took
years to get together. Linux may be ok for undemanding embedded
tasks, but still a great risk to select it for hard real time work.

I stopped using pfsense a few years back. Liked it to start with,
but as it became more commercial and difficult to get a build
environment together locally, moved over to opnsense, a european
fork of pfsense. They didn't like the commercial aspects either
and neither did I...

Chris

On Friday, October 15, 2021 at 1:11:03 PM UTC-4, Arne Vajhøj wrote:
> On 10/15/2021 12:29 PM, Bill Gunshannon wrote:
> > On 10/15/21 2:03 AM, Phillip Helbig (undress to reply) wrote:
> >> In Fortran, the implicit typing is only for INTEGER and REAL; it doesn't
> >> work for other data types.
> >
> > Relying on anything IMPLICIT is just bad programming practice.
> > I thought the languages settled that decades ago.
> I think it was settled like 1970-1995.
>
> Since then loosely typed languages and type inference
> has become widely used.
>
> You may not like it, but ...
>

SQLite 3.37 will add the STRICT keyword to the CREATE TABLE statement. If present,
it requires that all column definitions include a known data type (INT, REAL, TEXT,
BLOB) and the value must be that type (or NULL if not constrained by NOT NULL).

On 2021-10-14, Dave Froble <davef@tsoft-inc.com> wrote:
> On 10/14/2021 2:06 PM, Simon Clubley wrote:
>>
>> Having compared the two programs, I find the Pascal version to be
>> a lot more readable and easier to follow than the Basic version,
>> although Arne does put his begin statements in a strange place... :-)
>
> Yeah, Arne's code had lots of comments to explain things. Not!
>
> I'd really be interested in what parts of the Basic code was so bad?
>

In addition to what I have already said, Arne's control blocks feature
indented code, while all your code is at the same indentation level.

Indenting code within control structures makes the code much easier
to read.

> I do realize that since you are not familiar with DAS and it's implementation,
> and my library routines, which would not be understood. That's normal.
>
>> The Basic version has much more jumping around and just doesn't read
>> as well as the Pascal version does.
>
> I really resent that claim. With a few exceptions, mainline code is pretty
> much straight through, and for someone who seems to like scripting languages
> with all their library routines, placing specific in subroutines should
> seem rather natural.
>

Even in scripting languages, you have the Pascal style control structures
and indentation of code. That makes a major difference in readability.

> I'm a really big fan of modular code.
>
> My IDE is a big fan of things having a place, and things being in their place.
> Much of what you call jumping around is actually the IDE pulling in pieces of
> code to perform specific functions. I'm guessing if I had pulled in the forms
> control stuff, which is used for paging in reports, you'd be even more confused.
> But it works great, and doesn't have to be re-written for every program. Such
> also avoids coding errors.
>
>> BTW, Basic really does like spewing its special characters onto the
>> end of variable references. :-)
>
> And other languages don't have such quirks?
>

In general, not to that extent, although PHP likes its prefix character.

>> One thing I was surprised by was the goto and gosub to integer line
>> numbers instead of looping constructs and named function calls with
>> parameters as you see in the Pascal example and in other languages
>> such as C and Ada.
>
> I've seen people attempt to jump through many difficult hoops to attempt to follow
> some coding standard. Doesn't make any sense to me. There are perfectly logical
> uses for both GoSub and GoTo. Such as just throwing out the anchor if fatal errors
> occur. Moving special functionality out of the mainline code makes it more readable,
> for me.
>
> Did I mention I don't like C, and most likely would not like Ada?
>
> Got to ask, just what do you think a NEXT, WHILE_END, and such statements do?
> Sure looks like another form of GoTo to me.
>

Is code within these blocks written at an extra indentation level in
DEC Basic ?

It is in other languages with their control structures and it makes
the code much easier to read.

Simon.

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

On 10/15/2021 2:11 PM, chris wrote:
> On 10/15/21 02:07, Lawrence D’Oliveiro wrote:
>> On Friday, October 15, 2021 at 12:55:18 AM UTC+13, chris wrote:
>>>
>>> On 10/14/21 01:29, Lawrence D’Oliveiro wrote:
>>>>
>>>> There are no such things as “power grabs” in Free software.
>>>
>>> Perhaps, but the amount of money and effort that Red Hat (now owned
>>> by IBM btw) put into Linux means they have disproportionate amount of
>>> influence in the direction of the project.
>>
>> If you want to look at which is the single biggest company that is
>> contributing to Linux, that would have to be
> Microsoft.
>
> Well, warning, that may eventually be the kiss of death for Linux.
> What was the saying about uSoft getting involved with other
> companies ?. Something about assimilate and suppress :-). Even more
> reason to avoid Linux.

The saying was "Embrace, extend, and extinguish".

But don't worry - MS has in some periods release significant
chunks of code to Linux, but in general they are not that big
a contributor.

They did not make top 20 for 5.10:

https://news.itsfoss.com/huawei-kernel-contribution/

They did not make top 20 for 2008-2019 per Linux Kernel History Report 2020.

Arne

On 2021-10-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> Having variable type determined by variable name is definitely
> out of fashion. The only other language i know doing that is
> Fortran (Fortran is first letter while Basic is suffix but
> same concept).
>

Give it a few years and someone will suggest it as a bold new
concept for Rust or whatever is the fashion at that time... :-)

> But type inference is definitely in fashion.
>

Unless you are writing software that can kill people if it goes wrong.

There's always going to be a place for more formal and traditional
techniques when writing safety-critical software.

Simon.

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

On 10/15/2021 2:25 PM, Simon Clubley wrote:
> On 2021-10-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> But type inference is definitely in fashion.
>
> Unless you are writing software that can kill people if it goes wrong.

I suspect languages with type inference are occasionally used for that.

C++, Java, C#, Rust etc..

Arne

On 2021-10-15, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 10/15/2021 2:25 PM, Simon Clubley wrote:
>> On 2021-10-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> But type inference is definitely in fashion.
>>
>> Unless you are writing software that can kill people if it goes wrong.
>
> I suspect languages with type inference are occasionally used for that.
>
> C++, Java, C#, Rust etc..
>

But what do the safety-critical standards say about what you are and
are not allowed to do in those languages ?

Just because a language might have a certain feature, it doesn't mean
that you are allowed to use it in safety-critical software.

Simon.

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

On 10/15/2021 12:29 PM, Bill Gunshannon wrote:
> On 10/15/21 2:03 AM, Phillip Helbig (undress to reply) wrote:
>> In article <6168b9b9$0$700$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>>> On 10/14/2021 3:42 PM, Dave Froble wrote:
>>>> On 10/14/2021 2:36 PM, Arne VajhÞj wrote:
>>>>> On 10/14/2021 2:06 PM, Simon Clubley wrote:
>>>>>> BTW, Basic really does like spewing its special characters onto the
>>>>>> end of variable references. :-)
>>>
>>>> Basic can be very happy to let the programmer specify that all variables
>>>> must be declared. Then variable names can be whatever they are declared
>>>> to be. Frankly, I see no decent reason to do all that typing when the
>>>> compiler can do a much better job than any programmer. One just needs to
>>>> give it some hints. I learned the variable suffex stuff long ago, and
>>>> it's just natural to me. Just as conventions in another language might
>>>> be natural to someone used to that language.
>>>
>>> Having variable type determined by variable name is definitely
>>> out of fashion. The only other language i know doing that is
>>> Fortran (Fortran is first letter while Basic is suffix but
>>> same concept).
>>>
>>> But type inference is definitely in fashion.
>>>
>>> var v = 123
>>>
>>> instead of:
>>>
>>> int v = 123
>>>
>>> and:
>>>
>>> var v = "ABC"
>>>
>>> instead of:
>>>
>>> String v = "ABC"
>>>
>>> And for those that does not use languages less than 30 years
>>> old: var means "dear compiler give this variable type based on
>>> right hand side" not "I want to be able to assign anything to this
>>> variable".
>>
>> In Fortran, the implicit typing is only for INTEGER and REAL; it doesn't
>> work for other data types.
>>
>
> Relying on anything IMPLICIT is just bad programming practice.
> I thought the languages settled that decades ago.
>
> bill
>

That's your opinion Bill, and perhaps the opinion of some others. I'm allowed
to have contrary opinions, and I do. Doesn't that make me right, and the rest
of you wrong?

--
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 10/15/2021 2:17 PM, Simon Clubley wrote:
> On 2021-10-14, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 10/14/2021 2:06 PM, Simon Clubley wrote:
>>>
>>> Having compared the two programs, I find the Pascal version to be
>>> a lot more readable and easier to follow than the Basic version,
>>> although Arne does put his begin statements in a strange place... :-)
>>
>> Yeah, Arne's code had lots of comments to explain things. Not!
>>
>> I'd really be interested in what parts of the Basic code was so bad?
>>
>
> In addition to what I have already said, Arne's control blocks feature
> indented code, while all your code is at the same indentation level.

We must not be looking at the same code. Did you miss the "If Then Else End If"
indentations? I guess some people can go a bit wild on such, wonder what it's
like to read code in column 382?

> Indenting code within control structures makes the code much easier
> to read.

I agree. In fact I've found myself doing more than I should.

>> I do realize that since you are not familiar with DAS and it's implementation,
>> and my library routines, which would not be understood. That's normal.
>>
>>> The Basic version has much more jumping around and just doesn't read
>>> as well as the Pascal version does.
>>
>> I really resent that claim. With a few exceptions, mainline code is pretty
>> much straight through, and for someone who seems to like scripting languages
>> with all their library routines, placing specific in subroutines should
>> seem rather natural.
>>
>
> Even in scripting languages, you have the Pascal style control structures
> and indentation of code. That makes a major difference in readability.
>
>> I'm a really big fan of modular code.
>>
>> My IDE is a big fan of things having a place, and things being in their place.
>> Much of what you call jumping around is actually the IDE pulling in pieces of
>> code to perform specific functions. I'm guessing if I had pulled in the forms
>> control stuff, which is used for paging in reports, you'd be even more confused.
>> But it works great, and doesn't have to be re-written for every program. Such
>> also avoids coding errors.
>>
>>> BTW, Basic really does like spewing its special characters onto the
>>> end of variable references. :-)

Do you say that as a complaint, or just a comment. I find such to be helpful,
not having to go back to check any variable declarations.

>> And other languages don't have such quirks?
>>
>
> In general, not to that extent, although PHP likes its prefix character.
>
>>> One thing I was surprised by was the goto and gosub to integer line
>>> numbers instead of looping constructs and named function calls with
>>> parameters as you see in the Pascal example and in other languages
>>> such as C and Ada.
>>
>> I've seen people attempt to jump through many difficult hoops to attempt to follow
>> some coding standard. Doesn't make any sense to me. There are perfectly logical
>> uses for both GoSub and GoTo. Such as just throwing out the anchor if fatal errors
>> occur. Moving special functionality out of the mainline code makes it more readable,
>> for me.
>>
>> Did I mention I don't like C, and most likely would not like Ada?
>>
>> Got to ask, just what do you think a NEXT, WHILE_END, and such statements do?
>> Sure looks like another form of GoTo to me.
>>
>
> Is code within these blocks written at an extra indentation level in
> DEC Basic ?

I do that when I feel it is appropriate. Usually in small pieces of code.
You do that in the program mainline, and it soon becomes very hard to read.
I'm aware of that because someone here liked to write such code, and after
a dozen indentations, it gets rather tiresome.

> It is in other languages with their control structures and it makes
> the code much easier to read.

Sometimes it is just a particular person's practice, and yours being good
for you doesn't mean mine isn't good for me.

--
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 10/15/2021 11:38 AM, Arne Vajhøj wrote:
> On 10/14/2021 10:10 PM, Lawrence D’Oliveiro wrote:
>> On Friday, October 15, 2021 at 2:36:27 PM UTC+13, Arne Vajhøj wrote:
>>> On 10/14/2021 9:11 PM, Lawrence D’Oliveiro wrote:
>>>> And VMS can do the same thing. All the compatibility stuff can live in userland.
>>>
>>> I am having a hard time seeing: VMS scheduling, VMS memory protection,
>>> VMS clustering, ...
>>
>> None of which are relevant, because Linux already offers better functionality in all those areas.
>
> All of which are relevant, because without them it would not be VMS.
>
>>> DECnet, LAT ...
>>
>> They can be implemented in userland. If Netatalk can implement AppleTalk entirely in userland, why not them?
>
> DECnet is a bit possessive with NIC's - first thing it does is to change
> the MAC address.
>
>>> ... device handling ...
>>
>> Unneeded, since Linux already has the needed device drivers.
>
> Not enough for existing code and scripts to work.
>
>>> ... ODS-2 & ODS-5 ...
>>
>> New filesystems don’t have to be implemented as kernel modules, they could be done via FUSE.
>
> Maybe.
>
>>> 4 mode logicals etc ...
>>
>> Name services can be provided via a daemon communicating via, e.g. D-Bus. PF_UNIX sockets allow you to control access based on the credentials of the process you are talking to.
>
> Maybe.
>
> Arne

Arne, didn't I warn you about arguing with the Linux fanboy? He's going to
drag you down to his level, and then we won't be able to tell you two apart.

:-)

--
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 10/15/21 19:35, Simon Clubley wrote:
> On 2021-10-15, Arne Vajhøj<arne@vajhoej.dk> wrote:
>> On 10/15/2021 2:25 PM, Simon Clubley wrote:
>>> On 2021-10-14, Arne Vajhøj<arne@vajhoej.dk> wrote:
>>>> But type inference is definitely in fashion.
>>>
>>> Unless you are writing software that can kill people if it goes wrong.
>>
>> I suspect languages with type inference are occasionally used for that.
>>
>> C++, Java, C#, Rust etc..
>>
>
> But what do the safety-critical standards say about what you are and
> are not allowed to do in those languages ?
>
> Just because a language might have a certain feature, it doesn't mean
> that you are allowed to use it in safety-critical software.
>
> Simon.
>

I bought a copy of the MISRA standard years ago and more or less stick
to it's recommendations. As for variables and coding im general, still
using approx Hungarian system, where variables and function names always
have a type prefix, then camel case for long names. Also, tend not to
use the C standard library, as that defaults so much to int, where
unsigned would be more appropriate. Careless typing may work sometimes,
but can cause serious trouble as well...

Chris

On 10/15/21 19:24, Arne Vajhøj wrote:
> On 10/15/2021 2:11 PM, chris wrote:
>> On 10/15/21 02:07, Lawrence D’Oliveiro wrote:
>>> On Friday, October 15, 2021 at 12:55:18 AM UTC+13, chris wrote:
>>>>
>>>> On 10/14/21 01:29, Lawrence D’Oliveiro wrote:
>>>>>
>>>>> There are no such things as “power grabs” in Free software.
>>>>
>>>> Perhaps, but the amount of money and effort that Red Hat (now owned
>>>> by IBM btw) put into Linux means they have disproportionate amount of
>>>> influence in the direction of the project.
>>>
>>> If you want to look at which is the single biggest company that is
>>> contributing to Linux, that would have to be
>> Microsoft.
>>
>> Well, warning, that may eventually be the kiss of death for Linux.
>> What was the saying about uSoft getting involved with other
>> companies ?. Something about assimilate and suppress :-). Even more
>> reason to avoid Linux.
>
> The saying was "Embrace, extend, and extinguish".
>
> But don't worry - MS has in some periods release significant
> chunks of code to Linux, but in general they are not that big
> a contributor.
>
> They did not make top 20 for 5.10:
>
> https://news.itsfoss.com/huawei-kernel-contribution/
>
> They did not make top 20 for 2008-2019 per Linux Kernel History Report
> 2020.
>
> Arne

Thanks for the link, add flesh to the bones...

Chris

On 2021-10-15 17:52:25 +0000, Simon Clubley said:

> On 2021-10-14, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
>>
>> Scrap that current design, then.
>
> If you had been reading comp.os.vms for the last few years Lawrence,
> you would know that I have made multiple suggestions in exactly this
> area. I suspect I've annoyed multiple VSI employees with my rather firm
> negative opinions on this part of VMS.

I'm somehow reminded of jwz's CADT here, too.

https://www.jwz.org/doc/cadt.html

DCL absolutely needs work.

So too does OpenVMS.

Linux shimulation is not going to speed the delivery of the OpenVMS
x86-64 semi-production and production versions, nor the availability of
native compilers.

--
Pure Personal Opinion | HoffmanLabs LLC

On Friday, October 15, 2021 at 11:36:27 PM UTC+13, Phillip Helbig (undress to reply) wrote:
> The point about which both orbit is inside the Earth ...

Which, given what physics I was able to pick up, seems an entirely arbitrary thing to focus on. As the Moon recedes from the Earth, at some point that common point will exit the Earth’s surface. There is no special energy barrier to cross at that point, no special physical change in the system: it will simply exit and continue on its way.

> ... the orbit of the Moon is
> always concave relative to the Sun, which emphasizes the independence of
> the Moon.

That, to me, is the most important thing. Because without it, you can have no understanding of how the Moon moves.

> The current definition,
> which demoted Pluto, is that it is a body which dominates its orbit, so
> that applies to the Earth and not to the Moon.

Given the effect that the Moon has on the Earth, I’m not sure that’s so clear cut ...

On Saturday, October 16, 2021 at 4:38:37 AM UTC+13, Arne Vajhøj wrote:
> On 10/14/2021 10:10 PM, Lawrence D’Oliveiro wrote:
>> On Friday, October 15, 2021 at 2:36:27 PM UTC+13, Arne Vajhøj wrote:
>>> On 10/14/2021 9:11 PM, Lawrence D’Oliveiro wrote:
>>>> And VMS can do the same thing. All the compatibility stuff can live in userland.
>>>
>>> I am having a hard time seeing: VMS scheduling, VMS memory protection,
>>> VMS clustering, ...
>>
>> None of which are relevant, because Linux already offers better functionality
>> in all those areas.
>> All of which are relevant, because without them it would not be VMS.

Let us be clear what I’m getting at here: I’m not interested in curating a museum piece. I thought the important goal would be to allow existing user-mode code to run unchanged (as far as possible), and also existing DCL command procedures to run unchanged as far as possible. Everything else can go back to the museum. So what we want out of our compatibility layer is for it to look enough like VMS to satisfy those goals, even while its internals are entirely Linux-based.

> DECnet is a bit possessive with NIC's - first thing it does is to change
> the MAC address.

I know. It’s even more primitive than AppleTalk, it doesn’t have an ARP layer. So instead it has to compute the MAC address from the protocol address.

But we can cope with that.

>> Unneeded, since Linux already has the needed device drivers.
> Not enough for existing code and scripts to work.

I don’t care about anything beyond user mode (see above). I don’t think any of that is worth the effort.