Sun, 23 Jan 2022 10:18:58 +1100: Peter Moylan
<peter@pmoylan.org.invalid> scribeva:

>On 23/01/22 05:50, Peter T. Daniels wrote:
>> On Saturday, January 22, 2022 at 1:15:02 PM UTC-5, Tony Cooper
>> wrote:
>>
>>> Because it's not something I do, I may not have linked to what you
>>> actually want to know. I don't know, for example, if there's a
>>> difference between "group" and "merge" in this context.
>>
>> Just as a guess -- from how tables and graphics work in Word and
>> PowerPoint -- Merge leaves you with a single cell, and Group leaves
>> you with a Group of two or more cells that can be Ungrouped. (In
>> PowerPoint, the Ungroup command is on the same dropdown menu as the
>> Group command.) I don't use Excel, though.
>
>This sort of thing used to be a lot easier when MS-Word and Excel had
>real menus.

They still have, I think: press Alt to see them.

>It became more difficult when the ribbon-type menus were
>introduced. It's not so easy remembering where the function you want is
>on the ribbons, especially since it has changed from version to version.
>Even when you're looking at the right ribbon it's easy to miss seeing it.
>
>And, of course, the "function" features tend to be hidden by the greater
>number of "appearance" features.
>
>Videos don't help here, because they are often for a version you don't have.

--
Ruud Harmsen, http://rudhar.com

El Sat, 22 Jan 2022 20:28:51 +0100, Ruud Harmsen escribió:

> 22 Jan 2022 16:50:45 GMT: Paul Carmichael <wibbleypants@gmail.com>
> scribeva:
>
>>El Fri, 21 Jan 2022 16:15:34 -0700, Ken Blake escribió:
>>
>>> I think it's very rare that programmers write user documentation for
>>> the programs they write.
>
> I always did, and still do.
>
>>They are rarely expected to.
>
> They are, and I do expect myself to.

We are obviously from vastly different programming backgrounds.

I have never heard of a programmer being asked to produce end-user
documentation. Internal - yes.

Big companies often have entire departments devoted to documentation.
Unfortunately, the people that work in such departments are very mobile
and have little knowledge of the product.

--
Paul.

https://paulc.es/elpatio

On Sunday, January 23, 2022 at 4:16:30 AM UTC-5, Paul Carmichael wrote:
> El Sat, 22 Jan 2022 20:28:51 +0100, Ruud Harmsen escribió:
> > 22 Jan 2022 16:50:45 GMT: Paul Carmichael <wibble...@gmail.com>
> > scribeva:
> >>El Fri, 21 Jan 2022 16:15:34 -0700, Ken Blake escribió:

> >>> I think it's very rare that programmers write user documentation for
> >>> the programs they write.
> > I always did, and still do.
> >>They are rarely expected to.
> > They are, and I do expect myself to.
>
> We are obviously from vastly different programming backgrounds.
>
> I have never heard of a programmer being asked to produce end-user
> documentation. Internal - yes.
>
> Big companies often have entire departments devoted to documentation.
> Unfortunately, the people that work in such departments are very mobile
> and have little knowledge of the product.

When I went to the store for such things, I was faced with quite
an array of extensive series. The best ones proved to be "Missing
Manual" and "Bible" (the latter is a bit more comprehensive than
the ones in similar format published by Microsoft.) And a limited
series found only among the Bargain Books, "Made Easy." (Possibly
only for the four Office programs.) The PowerPoint one gave me
some new capabilities, and the Excel one is slightly understandable.

But I haven't had a reason to upgrade since 2013 so I don't know
what's available today -- the section seems smaller at the local
Barnes & Noble (Clifton, NJ), but they're retrenching in general: no
more CD/DVD department, and they closed the balcony entirely,
so that may be a local phenomenon.

On 23 Jan 2022 09:16:25 GMT, Paul Carmichael <wibbleypants@gmail.com>
wrote:

>El Sat, 22 Jan 2022 20:28:51 +0100, Ruud Harmsen escribió:
>
>> 22 Jan 2022 16:50:45 GMT: Paul Carmichael <wibbleypants@gmail.com>
>> scribeva:
>>
>>>El Fri, 21 Jan 2022 16:15:34 -0700, Ken Blake escribió:
>>>
>>>> I think it's very rare that programmers write user documentation for
>>>> the programs they write.
>>
>> I always did, and still do.
>>
>>>They are rarely expected to.
>>
>> They are, and I do expect myself to.
>
>We are obviously from vastly different programming backgrounds.
>
>I have never heard of a programmer being asked to produce end-user
>documentation. Internal - yes.

Yes.

>Big companies often have entire departments devoted to documentation.
>Unfortunately, the people that work in such departments are very mobile
>and have little knowledge of the product.

Yes, yes, and yes.

Sunday, Ken Blake murmurred ...
> On 23 Jan 2022 09:16:25 GMT, Paul Carmichael <wibbleypants@gmail.com>
> wrote:
>
>> El Sat, 22 Jan 2022 20:28:51 +0100, Ruud Harmsen escribió:
>>
>>> 22 Jan 2022 16:50:45 GMT: Paul Carmichael <wibbleypants@gmail.com>
>>> scribeva:
>>>
>>>> El Fri, 21 Jan 2022 16:15:34 -0700, Ken Blake escribió:
>>>>
>>>>> I think it's very rare that programmers write user documentation for
>>>>> the programs they write.
>>>
>>> I always did, and still do.
>>>
>>>> They are rarely expected to.
>>>
>>> They are, and I do expect myself to.
>>
>> We are obviously from vastly different programming backgrounds.
>>
>> I have never heard of a programmer being asked to produce end-user
>> documentation. Internal - yes.
>
> Yes.
>
>
>> Big companies often have entire departments devoted to documentation.
>> Unfortunately, the people that work in such departments are very mobile
>> and have little knowledge of the product.
>
>
> Yes, yes, and yes.

And big companies are not the only ones producing software.

But the time I did work for a big company on something customer-facing,
I was asked to draft a user document, and only after I finished that
did it go to an editor. An editor, not a writer.

/dps

--
You could try being nicer and politer
> instead, and see how that works out.
-- Katy Jennison

23 Jan 2022 09:16:25 GMT: Paul Carmichael <wibbleypants@gmail.com>
scribeva:

>El Sat, 22 Jan 2022 20:28:51 +0100, Ruud Harmsen escribió:
>
>> 22 Jan 2022 16:50:45 GMT: Paul Carmichael <wibbleypants@gmail.com>
>> scribeva:
>>
>>>El Fri, 21 Jan 2022 16:15:34 -0700, Ken Blake escribió:
>>>
>>>> I think it's very rare that programmers write user documentation for
>>>> the programs they write.
>>
>> I always did, and still do.
>>
>>>They are rarely expected to.
>>
>> They are, and I do expect myself to.
>
>We are obviously from vastly different programming backgrounds.
>
>I have never heard of a programmer being asked to produce end-user
>documentation. Internal - yes.

I did all of it.

>Big companies often have entire departments devoted to documentation.

Wrong approach. For me, anyway.

>Unfortunately, the people that work in such departments are very mobile
>and have little knowledge of the product.

That's exactly the problem.
--
Ruud Harmsen, http://rudhar.com

On Sun, 23 Jan 2022 22:41:14 +0100, Ruud Harmsen <rh@rudhar.com>
wrote:

>23 Jan 2022 09:16:25 GMT: Paul Carmichael <wibbleypants@gmail.com>
>scribeva:
>
>>El Sat, 22 Jan 2022 20:28:51 +0100, Ruud Harmsen escribió:
>>
>>> 22 Jan 2022 16:50:45 GMT: Paul Carmichael <wibbleypants@gmail.com>
>>> scribeva:
>>>
>>>>El Fri, 21 Jan 2022 16:15:34 -0700, Ken Blake escribió:
>>>>
>>>>> I think it's very rare that programmers write user documentation for
>>>>> the programs they write.
>>>
>>> I always did, and still do.
>>>
>>>>They are rarely expected to.
>>>
>>> They are, and I do expect myself to.
>>
>>We are obviously from vastly different programming backgrounds.
>>
>>I have never heard of a programmer being asked to produce end-user
>>documentation. Internal - yes.
>
>I did all of it.

OK, we haven't all have the same experiences. But yours is very
unusual in my experience.

>>Big companies often have entire departments devoted to documentation.
>
>Wrong approach. For me, anyway.

To me, it's the right approach.

>>Unfortunately, the people that work in such departments are very mobile
>>and have little knowledge of the product.
>
>That's exactly the problem.

Yes, they have little knowledge of the product. But they shouldn't
write the documentation based on their personal knowledge. They should
do the writing, not provide the knowledge. The knowledge should be
imparted to them by the programmers.

I'm sure there are exceptions, but in my experience, it's a rare good
programmer who can write well, and it's a rare good writer who can
program well (or at all).

Sun, 23 Jan 2022 15:23:57 -0700: Ken Blake <Ken@invalid.news.com>
scribeva:
>I'm sure there are exceptions, but in my experience, it's a rare good
>programmer who can write well, and it's a rare good writer who can
>program well (or at all).

True. I am exceptional.

I am now retired, can do what I want, and I program, test, implement,
document, write, translate, everything. No stupid managers going to
thwart me again. Plans to start playing and composing again too.
--
Ruud Harmsen, http://rudhar.com

On 23/01/22 17:21, Ruud Harmsen wrote:
> Sun, 23 Jan 2022 10:18:58 +1100: Peter Moylan
> <peter@pmoylan.org.invalid> scribeva:
>
>> On 23/01/22 05:50, Peter T. Daniels wrote:
>>> On Saturday, January 22, 2022 at 1:15:02 PM UTC-5, Tony Cooper
>>> wrote:
>>>
>>>> Because it's not something I do, I may not have linked to what
>>>> you actually want to know. I don't know, for example, if
>>>> there's a difference between "group" and "merge" in this
>>>> context.
>>>
>>> Just as a guess -- from how tables and graphics work in Word and
>>> PowerPoint -- Merge leaves you with a single cell, and Group
>>> leaves you with a Group of two or more cells that can be
>>> Ungrouped. (In PowerPoint, the Ungroup command is on the same
>>> dropdown menu as the Group command.) I don't use Excel, though.
>>
>> This sort of thing used to be a lot easier when MS-Word and Excel
>> had real menus.
>
> They still have, I think: press Alt to see them.

In the version I have, pressing Alt seems to label the ribbon with
keyboard shortcuts. That's OK if you've memorised what's on the ribbon,
and what the keyboard shortcuts mean, but it's not the same as having a
menu drop down so that you can see whether what you're looking for is on
that menu.

The major difference, I guess, is that a menu has words while a ribbon
has pictographs. They didn't teach us pictographs in school.

But maybe it's different in different versions.

In Thunderbird, by the way, I have a real menu bar across the top even
though the Thunderbird designers moved to hamburgers. There's some
setting in Thunderbird, which I've now forgotten, which means "Bring
back the old menus".

--
Peter Moylan Newcastle, NSW http://www.pmoylan.org

On 24/01/22 08:41, Ruud Harmsen wrote:
> 23 Jan 2022 09:16:25 GMT: Paul Carmichael <wibbleypants@gmail.com>
> scribeva:
>
>> El Sat, 22 Jan 2022 20:28:51 +0100, Ruud Harmsen escribió:
>>
>>> 22 Jan 2022 16:50:45 GMT: Paul Carmichael
>>> <wibbleypants@gmail.com> scribeva:
>>>
>>>> El Fri, 21 Jan 2022 16:15:34 -0700, Ken Blake escribió:
>>>>
>>>>> I think it's very rare that programmers write user
>>>>> documentation for the programs they write.
>>>
>>> I always did, and still do.
>>>
>>>> They are rarely expected to.
>>>
>>> They are, and I do expect myself to.
>>
>> We are obviously from vastly different programming backgrounds.
>>
>> I have never heard of a programmer being asked to produce end-user
>> documentation. Internal - yes.
>
> I did all of it.
>
>> Big companies often have entire departments devoted to
>> documentation.
>
> Wrong approach. For me, anyway.
>
>> Unfortunately, the people that work in such departments are very
>> mobile and have little knowledge of the product.
>
> That's exactly the problem.

How the world has changed. In the (good?) old days you picked your worst
programmers, the ones who always screwed up, and moved them on to doing
documentation to limit the damage they could do.

If they were just as bad at documentation, you moved them into management.

--
Peter Moylan Newcastle, NSW http://www.pmoylan.org

Peter Moylan pounded on thar keyboard to tell us
> On 24/01/22 08:41, Ruud Harmsen wrote:
>> 23 Jan 2022 09:16:25 GMT: Paul Carmichael <wibbleypants@gmail.com>
>> scribeva:
>>
>>> El Sat, 22 Jan 2022 20:28:51 +0100, Ruud Harmsen escribió:
>>>
>>>> 22 Jan 2022 16:50:45 GMT: Paul Carmichael
>>>> <wibbleypants@gmail.com> scribeva:
>>>>
>>>>> El Fri, 21 Jan 2022 16:15:34 -0700, Ken Blake escribió:
>>>>>
>>>>>> I think it's very rare that programmers write user
>>>>>> documentation for the programs they write.
>>>>
>>>> I always did, and still do.
>>>>
>>>>> They are rarely expected to.
>>>>
>>>> They are, and I do expect myself to.
>>>
>>> We are obviously from vastly different programming backgrounds.
>>>
>>> I have never heard of a programmer being asked to produce end-user
>>> documentation. Internal - yes.
>>
>> I did all of it.
>>
>>> Big companies often have entire departments devoted to
>>> documentation.
>>
>> Wrong approach. For me, anyway.
>>
>>> Unfortunately, the people that work in such departments are very
>>> mobile and have little knowledge of the product.
>>
>> That's exactly the problem.
>
> How the world has changed. In the (good?) old days you picked your worst
> programmers, the ones who always screwed up, and moved them on to doing
> documentation to limit the damage they could do.
>
> If they were just as bad at documentation, you moved them into management.

I've known some Psych majors who moved into managment. I happen to be
glad they weren't in my department.

/dps

--
I have always been glad we weren't killed that night. I do not know
any particular reason, but I have always been glad.
_Roughing It_, Mark Twain

On 24-Jan-22 10:24, Snidely wrote:
> Peter Moylan pounded on thar keyboard to tell us

>> If they were just as bad at documentation, you moved them into
>> management.
>
> I've known some Psych majors who moved into management.  I happen to be
> glad they weren't in my department.

How did that make you feel?

--
Sam Plusnet

On Thursday, January 20, 2022 at 3:53:27 AM UTC-8, hongy...@gmail.com wrote:
> See the following comment posted here by me [1]:
>
> === begin ===
> You're welcome. Based on your script, I created a new GitHub
> repository [1] that I hope will facilitate the collaborative
> development of the script and make it more accessible and usable by
> others.
> === end ===
> By language-feel, it seems that the usage of "that I hope will" is not correct/appropriate, but I don't know how to improve/touch-up it.
> Any hints will be highly appreciated.
>
I think it works as it stands, but if it feels awkward to you, try "a new GitHub
repository, which I hope will faciliate..."

bill

> [1] https://lists.quantum-espresso.org/pipermail/users/2022-January/048589.html
>
> Regards,
> HZ

On Mon, 24 Jan 2022 18:39:07 +0000
Sam Plusnet <not@home.com> wrote:

> On 24-Jan-22 10:24, Snidely wrote:
> > Peter Moylan pounded on thar keyboard to tell us
>
> >> If they were just as bad at documentation, you moved them into
> >> management.
> >
> > I've known some Psych majors who moved into management.  I happen to be
> > glad they weren't in my department.
>
> How did that make you feel?
>
Eliza, is that you?

--
Bah, and indeed Humbug.

On Monday, January 24, 2022 at 1:45:30 PM UTC-8, Kerr-Mudd, John wrote:
> On Mon, 24 Jan 2022 18:39:07 +0000
> Sam Plusnet <n...@home.com> wrote:
>
> > On 24-Jan-22 10:24, Snidely wrote:
> > > Peter Moylan pounded on thar keyboard to tell us
> >
> > >> If they were just as bad at documentation, you moved them into
> > >> management.
> > >
> > > I've known some Psych majors who moved into management. I happen to be
> > > glad they weren't in my department.
> >
> > How did that make you feel?
> >
> Eliza, is that you?
We ought IMO give token respect to Knuth's "literate programming" which
would have eliminated documenting by expanding the comments into a
narrative which included the code.

Knuth's idea is hard to implement. His own attempt to translate "Colossal
Cavern" (original in FORTRAN) is a disaster. It was a bad choice of example
because it is hard to imagine anything less documentable than CC.

But literate programming remains a feasible alternative even if nobody
uses it.

On 25/01/22 09:28, David Kleinecke wrote:
> On Monday, January 24, 2022 at 1:45:30 PM UTC-8, Kerr-Mudd, John
> wrote:
>> On Mon, 24 Jan 2022 18:39:07 +0000 Sam Plusnet <n...@home.com>
>> wrote:
>>
>>> On 24-Jan-22 10:24, Snidely wrote:
>>>> Peter Moylan pounded on thar keyboard to tell us
>>>
>>>>> If they were just as bad at documentation, you moved them
>>>>> into management.
>>>>
>>>> I've known some Psych majors who moved into management. I
>>>> happen to be glad they weren't in my department.
>>>
>>> How did that make you feel?
>>>
>> Eliza, is that you?
>
> We ought IMO give token respect to Knuth's "literate programming"
> which would have eliminated documenting by expanding the comments
> into a narrative which included the code.
>
> Knuth's idea is hard to implement. His own attempt to translate
> "Colossal Cavern" (original in FORTRAN) is a disaster. It was a bad
> choice of example because it is hard to imagine anything less
> documentable than CC.
>
> But literate programming remains a feasible alternative even if
> nobody uses it.

I wouldn't go as far as Knuth, but in my own programming I go some
direction towards giving priority to comments. In particular, when
trying to work out a suitable algorithm to do something, I'll put the
comments in first, and then try to work out code that would match the
comments.

For a simple example, consider the "shift and subtract" algorithm for
division. Nearly everyone knows what that means and how it is
implemented, but if you try to do an implementation from scratch you're
likely to get the fine details [1] wrong. (e.g. by going around the loop
the wrong number of times.) So when I've had to implement it, which I've
done several times over the years, I've first put in a loop with an
unspecified number of iterations, then put in comments that show the
loop invariants, the starting conditions, and so on. Next, I put in code
that matched the conditions shown in the comments (the loop invariants
being the most important part).

When I was teaching programming, I often had students come to me with
the question "Why doesn't my program work?". Initially I would try to
trace the logic, and I would come to a point where I would say "What
were you trying to do here?" The student usually didn't know. So, in the
end, I adopted a policy of refusing to help on uncommented code. I'd
tell them to come back after they had put in the comments. In many cases
they didn't come back, because putting in the comments had shown them
where their reasoning was faulty.

[1] Initially I mistyped that as "find details". That's not because I
have some sort of liaison in my speech. It's more a matter of my fingers
looking ahead and seeing that a 'd' will be needed soon.

But of course often we do merge words this way. WIWAL I thought the
power poles in the street were called "lamb posts".

--
Peter Moylan Newcastle, NSW http://www.pmoylan.org

Peter Moylan explained on 1/24/2022 :

> Nearly everyone knows what that means and how it is
> implemented, but if you try to do an implementation from scratch you're
> likely to get the fine details [1] wrong.
[...]

> [1] Initially I mistyped that as "find details". That's not because I
> have some sort of liaison in my speech. It's more a matter of my fingers
> looking ahead and seeing that a 'd' will be needed soon.
>
> But of course often we do merge words this way. WIWAL I thought the
> power poles in the street were called "lamb posts".

Merino?

-d

--
Killing a mouse was hardly a Nobel Prize-worthy exercise, and Lawrence
went apopleptic when he learned a lousy rodent had peed away all his
precious heavy water.
_The Disappearing Spoon_, Sam Kean

On Mon, 24 Jan 2022 17:13:59 -0800
Snidely <snidely.too@gmail.com> wrote:

> Peter Moylan explained on 1/24/2022 :
>
> > Nearly everyone knows what that means and how it is
> > implemented, but if you try to do an implementation from scratch you're
> > likely to get the fine details [1] wrong.
> [...]
>
> > [1] Initially I mistyped that as "find details". That's not because I
> > have some sort of liaison in my speech. It's more a matter of my fingers
> > looking ahead and seeing that a 'd' will be needed soon.
> >
> > But of course often we do merge words this way. WIWAL I thought the
> > power poles in the street were called "lamb posts".
>
> Merino?
>
Android dreams.
--
Bah, and indeed Humbug.

On Tue, 25 Jan 2022 11:15:41 +1100, Peter Moylan
<peter@pmoylan.org.invalid> wrote:

>On 25/01/22 09:28, David Kleinecke wrote:
>> On Monday, January 24, 2022 at 1:45:30 PM UTC-8, Kerr-Mudd, John
>> wrote:
>>> On Mon, 24 Jan 2022 18:39:07 +0000 Sam Plusnet <n...@home.com>
>>> wrote:
>>>
>>>> On 24-Jan-22 10:24, Snidely wrote:
>>>>> Peter Moylan pounded on thar keyboard to tell us
>>>>
>>>>>> If they were just as bad at documentation, you moved them
>>>>>> into management.
>>>>>
>>>>> I've known some Psych majors who moved into management. I
>>>>> happen to be glad they weren't in my department.
>>>>
>>>> How did that make you feel?
>>>>
>>> Eliza, is that you?
>>
>> We ought IMO give token respect to Knuth's "literate programming"
>> which would have eliminated documenting by expanding the comments
>> into a narrative which included the code.
>>
>> Knuth's idea is hard to implement. His own attempt to translate
>> "Colossal Cavern" (original in FORTRAN) is a disaster. It was a bad
>> choice of example because it is hard to imagine anything less
>> documentable than CC.
>>
>> But literate programming remains a feasible alternative even if
>> nobody uses it.
>
>I wouldn't go as far as Knuth, but in my own programming I go some
>direction towards giving priority to comments. In particular, when
>trying to work out a suitable algorithm to do something, I'll put the
>comments in first, and then try to work out code that would match the
>comments.

It's been umpteen years since I've written a program, but I used to
do much the same.

On 2022-01-25 15:37:33 +0000, Ken Blake said:

> On Tue, 25 Jan 2022 11:15:41 +1100, Peter Moylan
> <peter@pmoylan.org.invalid> wrote:
>
>> On 25/01/22 09:28, David Kleinecke wrote:
>>> On Monday, January 24, 2022 at 1:45:30 PM UTC-8, Kerr-Mudd, John
>>> wrote:
>>>> On Mon, 24 Jan 2022 18:39:07 +0000 Sam Plusnet <n...@home.com>
>>>> wrote:
>>>>
>>>>> On 24-Jan-22 10:24, Snidely wrote:
>>>>>> Peter Moylan pounded on thar keyboard to tell us
>>>>>
>>>>>>> If they were just as bad at documentation, you moved them
>>>>>>> into management.
>>>>>>
>>>>>> I've known some Psych majors who moved into management. I
>>>>>> happen to be glad they weren't in my department.
>>>>>
>>>>> How did that make you feel?
>>>>>
>>>> Eliza, is that you?
>>>
>>> We ought IMO give token respect to Knuth's "literate programming"
>>> which would have eliminated documenting by expanding the comments
>>> into a narrative which included the code.
>>>
>>> Knuth's idea is hard to implement. His own attempt to translate
>>> "Colossal Cavern" (original in FORTRAN) is a disaster. It was a bad
>>> choice of example because it is hard to imagine anything less
>>> documentable than CC.
>>>
>>> But literate programming remains a feasible alternative even if
>>> nobody uses it.
>>
>> I wouldn't go as far as Knuth, but in my own programming I go some
>> direction towards giving priority to comments. In particular, when
>> trying to work out a suitable algorithm to do something, I'll put the
>> comments in first, and then try to work out code that would match the
>> comments.
>
>
> It's been umpteen years since I've written a program, but I used to
> do much the same.

In my Fortran days I used a lot of comments, but in Pascal I found most
could be rendered unnecessary by using names for procedures etc. that
made it obvious what their purposes were.

--
Athel -- French and British, living mainly in England until 1987.

El Tue, 25 Jan 2022 08:37:33 -0700, Ken Blake escribió:

> On Tue, 25 Jan 2022 11:15:41 +1100, Peter Moylan
> <peter@pmoylan.org.invalid> wrote:

>>I wouldn't go as far as Knuth, but in my own programming I go some
>>direction towards giving priority to comments. In particular, when
>>trying to work out a suitable algorithm to do something, I'll put the
>>comments in first, and then try to work out code that would match the
>>comments.
>
>
> It's been umpteen years since I've written a program, but I used to do
> much the same.

A block comment with a complete flow-chart showing all possible code
paths generally works.

How many major bugs have been caused by an unexpected code path?

The code can be debugged by somebody else and "missing" code paths /
error conditions added.

Just before I left my programming job, they were adding SEH all over the
place. Lazy bastards. Why not just code it right?

--
Paul.

https://paulc.es/elpatio