On 2021-10-15, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
>
> I don?t care about anything beyond user mode (see above). I don?t think any of that is worth the effort.

Those compatibility layers already exist Lawrence and some VMS customers
have used them to move to Linux.

Yes, despite those compatibility layers already existing, enough VMS
customers needed "real" VMS on x86-64 at the start of the port that
VSI proceeded with a port of VMS to x86-64.

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, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
> On Saturday, October 16, 2021 at 7:01:22 AM UTC+13, Simon Clubley wrote:
>
>> FUSE filesystems come with performance limitations on Linux.
>
> They work well enough for NTFS, for example. Given that Linux already runs on higher-performance hardware than anything VMS can manage, I doubt the penalty will be noticeable. ;)
>
> I keep thinking in terms of reducing the amount of work (and hence time) to get something going. That means foregoing higher-performance, but possibly more difficult, design choices in favour of easier ones. Learn to walk before you can run. ;)

So in other words, you think you know how to do the easy bits to
get some VMS code running on Linux, but don't know how to handle
the difficult real-world cases that force some people to want
to stay with real VMS, even though compatibility kits exist right
now in 2021 for running some VMS code on Linux ?

Simon.

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

On 10/16/2021 8:16 PM, Lawrence D’Oliveiro wrote:
> On Sunday, October 17, 2021 at 1:00:38 PM UTC+13, John Dallman wrote:
>> May I suggest you start a project to demonstrate this?
>
> You want to do a pilot? Offer an example app that you think will cause trouble, and we can go over it step by step.

You just pick whatever you want.

Fully compatible DCL with logicals and symbols.

Fully compatible RMS library.

Fully compatible Basic implementation

Fully compatible Pascal implementation.

The behavior of these are reasonable well documented.

The important point is that you deliver something working.

We can find tens of thousands of people that will:
- claim that it is easy
- provide 10-20 lines of English description
- etc.

Arne

On 2021-10-16, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
>
> The sooner it is started, the sooner it is done. A year to implement the most important core user-mode APIs, as well as a DCL interpreter? May be doable, with a team of maybe half a dozen or less. If you can find the right half-dozen.
>

Some reading for you Lawrence:

https://sector7.com/

Yet, even though these alternatives existed at the start of the port
of VMS to x86-64, there was still sufficient customer demand for a
"real" VMS on x86-64.

The above should also give you a feeling for the scale of the issues
involved. And unlike your hand waving dismissal of the difficult issues,
these people have actually thought about the difficult issues and
provided answers for some of them.

Simon.

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

On 10/17/21 2:58 PM, Simon Clubley wrote:
>
>
> Have you ever read Dijkstra's paper on the subject of goto statements ?
>
> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf
>

Yes, and a number of his other comments. While I agree with
some of it I think for the most part he was an ass.

bill

On Monday, October 18, 2021 at 8:35:58 AM UTC+13, Arne Vajhøj wrote:

> Fully compatible DCL with logicals and symbols.

The core of the VMS emulation, as far as user-mode code sees it, would be the compatibility library that the program links against -- call this “libstarlet”. This would implement QIO, RMS and whatever else we want to salvage from the VMS API. As I mentioned, this would not be completely self-contained: where necessary, it would communicate with other service processes.

For example, we would need a program called “dcl”. This would not only be a DCL-compatible command shell, spawning user-mode code in a child process, it would also provide services to that child process for accessing DCL variables and process/job logical names. And PPFs.

I think terminal I/O would also need to be mediated by the dcl process. That way, it can implement correct behaviour for control characters, read-with-prompt, broadcasts etc.

As for group- and systemwide logical names, I think we would need a separate daemon for that, longer-lived than any dcl process. That would also manage common event flag clusters and mailboxes. We could give it a boring, obvious name like “vmssys”. Or we could go for something more deeply meaningful, like “s0” or even “80000168” ...

> Fully compatible RMS library.

I think this can be contained entirely within libstarlet.

> Fully compatible Basic implementation
>
> Fully compatible Pascal implementation.

As mentioned, take the existing VMS-specific frontends and replace the backends with something from the GCC or LLVM projects.

> We can find tens of thousands of people that will:
> - claim that it is easy
> - provide 10-20 lines of English description
> - etc.

Like I said, give more specifics, and I can answer them more specifically. You want to talk about async QIOs? Event flags? Global sections? DECnet? Just ask. This is a discussion forum, we are here to discuss!

On Monday, October 18, 2021 at 8:38:42 AM UTC+13, Simon Clubley wrote:
>
> Some reading for you Lawrence:
>
> https://sector7.com/

Are you trying to prove it can’t be done, or that it can?

Hmm, I can’t seem to find any mention of VMS terminal driver emulation. Even I can figure out how to do that...

Or subprocess semantics, for that matter.

Or DECnet. Or PPFs.

> Yet, even though these alternatives existed at the start of the port
> of VMS to x86-64, there was still sufficient customer demand for a
> "real" VMS on x86-64.

Maybe the technical quality of their solution is not up to scratch (as per the issues above). Or maybe the issues are not technical, but marketing.

> The above should also give you a feeling for the scale of the issues
> involved. And unlike your hand waving dismissal of the difficult issues ....

I haven’t handwaved anything. I’ve been quite prepared to give detailed, considered answers to detailed, considered questions.

> these people have actually thought about the difficult issues and
> provided answers for some of them.

And maybe they missed some ...

On Monday, October 18, 2021 at 10:23:51 AM UTC+13, Bill Gunshannon wrote:
> On 10/17/21 2:58 PM, Simon Clubley wrote:
>>
>> Have you ever read Dijkstra's paper on the subject of goto statements ?
>>
>> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf
>>
> Yes, and a number of his other comments. While I agree with
> some of it I think for the most part he was an ass.

Maybe you think his arguments were too vague, too pontifical. Maybe you want something a bit more specific, with example code you can get your teeth into, to show you why gotos are a bad idea.

Try this: <https://github.com/ldo/a_structured_discipline_of_programming>.

(Dis)claimer: I have never written a goto in C code. Not in a program that did anything useful, anyway.

On 10/17/2021 6:36 PM, Lawrence D’Oliveiro wrote:
> On Monday, October 18, 2021 at 8:35:58 AM UTC+13, Arne Vajhøj wrote:
>
>> Fully compatible DCL with logicals and symbols.
>
> The core of the VMS emulation, as far as user-mode code sees it,
> would be the compatibility library that the program links against --
> call this “libstarlet”. This would implement QIO, RMS and whatever
> else we want to salvage from the VMS API. As I mentioned, this would
> not be completely self-contained: where necessary, it would
> communicate with other service processes.
>
> For example, we would need a program called “dcl”. This would not
> only be a DCL-compatible command shell, spawning user-mode code in a
> child process, it would also provide services to that child process
> for accessing DCL variables and process/job logical names. And PPFs.
>
> I think terminal I/O would also need to be mediated by the dcl
> process. That way, it can implement correct behaviour for control
> characters, read-with-prompt, broadcasts etc.
>
> As for group- and systemwide logical names, I think we would need a
> separate daemon for that, longer-lived than any dcl process. That
> would also manage common event flag clusters and mailboxes. We could
> give it a boring, obvious name like “vmssys”. Or we could go for
> something more deeply meaningful, like “s0” or even “80000168” ...
>
>> Fully compatible RMS library.
>
> I think this can be contained entirely within libstarlet.
>
>> Fully compatible Basic implementation
>>
>> Fully compatible Pascal implementation.
>
> As mentioned, take the existing VMS-specific frontends and replace
> the backends with something from the GCC or LLVM projects.
>
>> We can find tens of thousands of people that will: - claim that it
>> is easy - provide 10-20 lines of English description - etc.
>
> Like I said, give more specifics, and I can answer them more
> specifically. You want to talk about async QIOs? Event flags? Global
> sections? DECnet? Just ask. This is a discussion forum, we are here
> to discuss!

You apparently missed the point.

Anybody can claim that they can do stuff like this in 10 months or
10 weeks or 10 days.

And they can discuss it from now to eternity on usenet.

But it means nothing.

If they actually implement a significant part, then it means something.

Arne

On 2021-10-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> You apparently missed the point.
>
> Anybody can claim that they can do stuff like this in 10 months or
> 10 weeks or 10 days.
>
> And they can discuss it from now to eternity on usenet.
>
> But it means nothing.
>
> If they actually implement a significant part, then it means something.
>

And Sector 7 (and others IIRC) have done various pieces of this, yet
there's still a market for real VMS systems.

Perhaps if Lawrence thinks he is such hot stuff, then he should offer
his services to Sector 7 or another company and then capture the rest
of the VMS market, putting real VMS out of business.

Lawrence, Arne is right. Talking that consists of mainly hand waving
achieves nothing. You have to do something tangible in order for people
to take you seriously.

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-17, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
> On Monday, October 18, 2021 at 8:38:42 AM UTC+13, Simon Clubley wrote:
>>
>> Some reading for you Lawrence:
>>
>> https://sector7.com/
>
> Are you trying to prove it can?t be done, or that it can?
>

I'm showing you that someone has already done what you are suggesting.

> Hmm, I can?t seem to find any mention of VMS terminal driver emulation. Even I can figure out how to do that...
>
> Or subprocess semantics, for that matter.
>
> Or DECnet. Or PPFs.
>

Contact them and ask them about it. If they don't implement them, you
may also find they have equally viable alternatives. If they don't, and
if customers care about that, you could always offer your services.

>> Yet, even though these alternatives existed at the start of the port
>> of VMS to x86-64, there was still sufficient customer demand for a
>> "real" VMS on x86-64.
>
> Maybe the technical quality of their solution is not up to scratch (as per the issues above). Or maybe the issues are not technical, but marketing.
>

And maybe you could end up discovering that hand waving doesn't cut it
and that there are very real world issues in customer code that come
to light big time when you try to run VMS code on Linux even with the
help of a compatibility library.

>> The above should also give you a feeling for the scale of the issues
>> involved. And unlike your hand waving dismissal of the difficult issues ...
>
> I haven?t handwaved anything. I?ve been quite prepared to give detailed, considered answers to detailed, considered questions.
>
>> these people have actually thought about the difficult issues and
>> provided answers for some of them.
>
> And maybe they missed some ...

You could always contact them and find out.

Simon.

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

On 10/17/2021 2:58 PM, Simon Clubley wrote:
> On 2021-10-15, Dave Froble <davef@tsoft-inc.com> wrote:
>> 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:
>>>
>>> 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?
>>
>
> No, but that little bit doesn't really help you with understanding the code.
>
>>>>> 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.
>>
>
> Comment only, as to my eyes it makes the code look a little more ugly.
>
> But it could easily turn into a complaint if I had to type them all the time.
>
>>>>
>>>> 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.
>>
>
> Have you ever read Dijkstra's paper on the subject of goto statements ?
>
> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf
>
> Simon.
>

Sigh ....

Several times. Each time I get the same impression. Square pegs and round holes.

There are no bad instructions, including GoTo. There is just good and bad usage
of instructions. A well designed procedure can use any valid instruction. One can
also write trash without using GoTo.

When anyone sets themselves up as the instruction gods, I got no time for them.

--
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 Monday, October 18, 2021 at 1:32:38 PM UTC+13, Simon Clubley wrote:
>
> I'm showing you that someone has already done what you are suggesting.

Doesn’t seem like it. Everything on their site seems more like ... what was the word you used ... “handwaving”?

> Contact them and ask them about it.

No, you were the one who claimed they had done all these things, it is up to you to prove your point, not me. You said I had to do “some reading”, which I did, and showed how it came up short. Now it’s your turn.

On Monday, October 18, 2021 at 12:29:23 PM UTC+13, Arne Vajhøj wrote:
> Anybody can claim that they can do stuff like this in 10 months or
> 10 weeks or 10 days.

Who did?

On Monday, October 18, 2021 at 2:28:36 PM UTC+13, Dave Froble wrote:
> There are no bad instructions, including GoTo.

I have never found a use for a goto in production code. (Not at the level of C or higher, anyway.)

On 10/18/21 06:22, Lawrence D’Oliveiro wrote:
> On Monday, October 18, 2021 at 1:32:38 PM UTC+13, Simon Clubley wrote:
>>
>> I'm showing you that someone has already done what you are suggesting.
>
> Doesn’t seem like it. Everything on their site seems more like ... what was the word you used ... “handwaving”?
>
>> Contact them and ask them about it.
>
> No, you were the one who claimed they had done all these things, it is up to you to prove your point, not me. You said I had to do “some reading”, which I did, and showed how it came up short. Now it’s your turn.

I would stop digging if I were you :-).

I'm sure a lot of your ideas and solutions are possible, but the
primary task is to get VMS into the hands of the established
user base with the minimum of disruption to their ongoing
business. After all, it's just a port to new cpu architecture,
right ?.

Feel free to implement your own solutions and offer up as an
open source project, if it's that easy. What could possibly
go wrong ?...

Chris

On 2021-10-18, chris <chris-nospam@tridac.net> wrote:
> On 10/18/21 06:22, Lawrence D?Oliveiro wrote:
>> On Monday, October 18, 2021 at 1:32:38 PM UTC+13, Simon Clubley wrote:
>>>
>>> I'm showing you that someone has already done what you are suggesting.
>>
>> Doesn?t seem like it. Everything on their site seems more like ... what was the word you used ... ?handwaving??
>>

You are shown a major vendor in the VMS world who does exactly what
you are claiming could be done and you promptly go into full denial
mode because VMS continues to exist alongside their products thereby
damaging your arguments that all VMS systems can be moved to Linux.

>>> Contact them and ask them about it.
>>
>> No, you were the one who claimed they had done all these things, it is up to you to prove your point, not me. You said I had to do ?some reading?, which I did, and showed how it came up short. Now it?s your turn.

These people have been around for decades and all that time they
have been helping move systems away from VMS, at least those systems
which a) can be moved and b) those which the customer wants to move
away from VMS.

>
> I would stop digging if I were you :-).
>

:-)

He's not the first person I've had to deal with in recent years who
has gone into full denial mode when presented with something they
don't like. :-)

> I'm sure a lot of your ideas and solutions are possible, but the
> primary task is to get VMS into the hands of the established
> user base with the minimum of disruption to their ongoing
> business. After all, it's just a port to new cpu architecture,
> right ?.
>

Sector 7 are already doing what Lawrence claims he can offer.

Yet there is still a market for real VMS in spite of that.

> Feel free to implement your own solutions and offer up as an
> open source project, if it's that easy. What could possibly
> go wrong ?...
>

What could go wrong is that Lawrence finds out that hand waving
doesn't work when you actually have to solve real technical issues. :-)

Simon.

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

On 10/17/2021 9:28 PM, Dave Froble wrote:
> On 10/17/2021 2:58 PM, Simon Clubley wrote:
>> Have you ever read Dijkstra's paper on the subject of goto statements ?
>>
>> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf

> Several times.  Each time I get the same impression.  Square pegs and
> round holes.
>
> There are no bad instructions, including GoTo.  There is just good and
> bad usage
> of instructions.  A well designed procedure can use any valid
> instruction.  One can
> also write trash without using GoTo.
>
> When anyone sets themselves up as the instruction gods, I got no time
> for them.

There may not be language constructs that are always bad to use.

But there are language constructs that are rarely good to use.

In most cases usage of GOTO do make the code more difficult to
follow.

I can only think of one case where I will prefer GOTO
over alternatives: in a language without exceptions to
jump to cleanup code in case of problems. I have done that
in both C and Pascal and I think it does make the code
more readable. In newer languages with a try catch
block there is no need.

Arne

On 10/17/21 9:28 PM, Dave Froble wrote:
> On 10/17/2021 2:58 PM, Simon Clubley wrote:
>> On 2021-10-15, Dave Froble <davef@tsoft-inc.com> wrote:
>>> 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:
>>>>
>>>> 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?
>>>
>>
>> No, but that little bit doesn't really help you with understanding the
>> code.
>>
>>>>>> 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.
>>>
>>
>> Comment only, as to my eyes it makes the code look a little more ugly.
>>
>> But it could easily turn into a complaint if I had to type them all
>> the time.
>>
>>>>>
>>>>> 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.
>>>
>>
>> Have you ever read Dijkstra's paper on the subject of goto statements ?
>>
>> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf
>>
>> Simon.
>>
>
> Sigh ....
>
> Several times.  Each time I get the same impression.  Square pegs and
> round holes.
>
> There are no bad instructions, including GoTo.  There is just good and
> bad usage
> of instructions.  A well designed procedure can use any valid
> instruction.  One can
> also write trash without using GoTo.
>
> When anyone sets themselves up as the instruction gods, I got no time
> for them.
>

That's funny... The academic world did that decades ago. That's
why we keep hearing that COBOL is dead and OOP and Agile are the
best thing since sliced bread.

bill

On Monday, October 18, 2021 at 12:34:13 PM UTC-4, Bill Gunshannon wrote:
> That's funny... The academic world did that decades ago. That's
> why we keep hearing that COBOL is dead and OOP and Agile are the
> best thing since sliced bread.
>

Didn't Functional Programming replace OOP as the new hotness?

On 2021-10-18, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> That's funny... The academic world did that decades ago. That's
> why we keep hearing that COBOL is dead and OOP and Agile are the
> best thing since sliced bread.
>

There's still a place for COBOL. Sometimes the practical language
instead of the fashionable language is required.

OOP allows you to very nicely implement abstraction layers provided
you don't go overboard and have 10 layers of abstraction to write
out a single character (for example). :-)

Agile OTOH seems way too often to be used as an excuse to not to do
the hard and real work of designing and laying out the overall
architecture before implementing the design.

Simon.

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

On 10/18/2021 12:34 PM, Bill Gunshannon wrote:
> On 10/17/21 9:28 PM, Dave Froble wrote:
>> There are no bad instructions, including GoTo.  There is just good and
>> bad usage
>> of instructions.  A well designed procedure can use any valid
>> instruction.  One can
>> also write trash without using GoTo.
>>
>> When anyone sets themselves up as the instruction gods, I got no time
>> for them.
>
> That's funny...  The academic world did that decades ago.  That's
> why we keep hearing that COBOL is dead  and OOP and Agile are the
> best thing since sliced bread.

It may depend.

Where the last word in "Computer Science" is in 72 pt and there
is violin music in the background I would expect focus to be
in math, FP and languages that are rare in real world like
Haskel and OCaml - with no focus on development methodology.

Lesser pure and more practical institutions may indeed teach
OOP, widely used languages as Python and Java and C#,
relational databases and SQL plus some development methodology
including a bit of waterfall and some generic agile and
probably Scrum.

But there must be extremely few if any all all that
teaches Cobol.

Arne

On 10/18/2021 12:34 PM, Bill Gunshannon wrote:
> On 10/17/21 9:28 PM, Dave Froble wrote:
>> On 10/17/2021 2:58 PM, Simon Clubley wrote:
>>> On 2021-10-15, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> 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:
>>>>>
>>>>> 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?
>>>>
>>>
>>> No, but that little bit doesn't really help you with understanding the code.
>>>
>>>>>>> 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.
>>>>
>>>
>>> Comment only, as to my eyes it makes the code look a little more ugly.
>>>
>>> But it could easily turn into a complaint if I had to type them all the time.
>>>
>>>>>>
>>>>>> 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.
>>>>
>>>
>>> Have you ever read Dijkstra's paper on the subject of goto statements ?
>>>
>>> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf
>>>
>>> Simon.
>>>
>>
>> Sigh ....
>>
>> Several times. Each time I get the same impression. Square pegs and round holes.
>>
>> There are no bad instructions, including GoTo. There is just good and bad usage
>> of instructions. A well designed procedure can use any valid instruction. One can
>> also write trash without using GoTo.
>>
>> When anyone sets themselves up as the instruction gods, I got no time for them.
>>
>
> That's funny... The academic world did that decades ago. That's
> why we keep hearing that COBOL is dead and OOP and Agile are the
> best thing since sliced bread.
>
> bill
>

Those who can, do ...
Those who cannot do, teach ...
Those who cannot teach, write about IT, causing mass confusion ...

--
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 Tuesday, October 19, 2021 at 1:27:51 AM UTC+13, Simon Clubley wrote:
>
> On 10/18/21 06:22, Lawrence D?Oliveiro wrote:
>>
>> On Monday, October 18, 2021 at 1:32:38 PM UTC+13, Simon Clubley wrote:
>>
>>> I'm showing you that someone has already done what you are suggesting.
>>
>> Doesn’t seem like it. Everything on their site seems more like .... what was the word
> you used ... “handwaving”?
>
> You are shown a major vendor in the VMS world who does exactly what
> you are claiming ...

Are they indeed? Not much evidence of that from their website.

Seems you are willing to give them a free absolution from the same objections you were trying to raise against me.

>>> Contact them and ask them about it.
>
>> No, you were the one who claimed they had done all these things, it is up to you to prove
>> your point, not me. You said I had to do “some reading”, which I did, and showed how
>> it came up short. Now it’s your turn.
>
> These people have been around for decades and all that time they
> have been helping move systems away from VMS, at least those systems
> which a) can be moved and b) those which the customer wants to move
> away from VMS.

Which is exactly the kind of thing a management type would say. You know, the type who describes themself as a “big picture” type of person, who leaves the troublesome details of actually getting things working to some hapless underling.

In other words, the type that is easily taken in by a slick advertising campaign.

On Tuesday, October 19, 2021 at 5:53:47 AM UTC+13, osuv...@gmail.com wrote:
> Didn't Functional Programming replace OOP as the new hotness?

I use a lot of functional constructs in my Python code, but never saw a pure-functional language as very practical.