On 4/7/22 10:45, Dan Cross wrote:
> In article <t2l82r$1s8o$1@gioia.aioe.org>,
> chris <chris-nospam@tridac.net> wrote:
>> I don't like anything that claims or predisposes to protect me from
>> my own stupidity. Prefer the freedom to make my own mistakes and
>> learn from them. Not more nanny state, however fashionable it
>> may be...
>
> Seatbelts are for wimps, I guess. There's lots to be learned
> being thrown through the windshield of a moving car.
>

Another problem, really but seatbelts are more of a matter of
political control than safety. Other wise most states would
not prohibit the use of 4 and 6 point belts in favor of 3 point
belts with high failure rates that are also harder to get the
occupant out of the car when overturned than the standard 4 or
6 point belt.

bill

On 4/7/22 10:55, Dan Cross wrote:
>
>
> I'm old enough to remember that, as well. Indeed, I read a
> pre-alpha Java spec and thought it was pretty nifty at the time.
> Then the snakeoil "Uncle Bob" types got a hold of it and it
> became a bloated mess.
>

Congratulations. You just described Ada. :-)

bill

In article <t2l9jp$b8i$1@gioia.aioe.org>,
chris <chris-nospam@tridac.net> wrote:
>On 04/06/22 01:25, Dan Cross wrote:
>This sounds like medication to cure everyone from their sloppy
>programming. The infantilisation of complex subjects, just to give the
>lazy an easier time, while still getting the product built.
>The answer to that is not languages that constrain movement, but
>developing more professional skills and applying due diligence
>and attention to detail to system design and implementation.
>
>I must be getting old, so what happened to pursuit of excellence
>and more ?...

Excellent practitioners curate their tools and select the ones
that give them the best chance of maximizing the effectiveness
of their work products. Ego driven machismo and disdain for
tooling that helps prevent defects is a sign of an amateurish
attitude towards software development, not that of a
professional, let alone an engineer.

- Dan C.

In article <jb8cf5F6634U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>On 4/7/22 10:45, Dan Cross wrote:
>> In article <t2l82r$1s8o$1@gioia.aioe.org>,
>> chris <chris-nospam@tridac.net> wrote:
>>> I don't like anything that claims or predisposes to protect me from
>>> my own stupidity. Prefer the freedom to make my own mistakes and
>>> learn from them. Not more nanny state, however fashionable it
>>> may be...
>>
>> Seatbelts are for wimps, I guess. There's lots to be learned
>> being thrown through the windshield of a moving car.
>>
>
>Another problem, really but seatbelts are more of a matter of
>political control than safety. Other wise most states would
>not prohibit the use of 4 and 6 point belts in favor of 3 point
>belts with high failure rates that are also harder to get the
>occupant out of the car when overturned than the standard 4 or
>6 point belt.

But we generally agree that restraints help prevent injuries
versus no restraints, right?

- Dan C.

In article <jb8ci7F6634U2@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>On 4/7/22 10:55, Dan Cross wrote:
>>
>>
>> I'm old enough to remember that, as well. Indeed, I read a
>> pre-alpha Java spec and thought it was pretty nifty at the time.
>> Then the snakeoil "Uncle Bob" types got a hold of it and it
>> became a bloated mess.
>
>Congratulations. You just described Ada. :-)

*rimshot*

But in fairness to Ada, I'm pretty sure that the agile snakeoil
folks would struggle mightily with it. Have the likes of Robert
C Martin ever actually delivered a large program?

- Dan C.

On 04/07/22 03:43, plugh wrote:
> On Wednesday, April 6, 2022 at 5:01:02 PM UTC-7, chris wrote:

<snipped>

>>
>> This sounds like medication to cure everyone from their sloppy
>> programming. The infantilisation of complex subjects, just to give the
>> lazy an easier time, while still getting the product built.
>> The answer to that is not languages that constrain movement, but
>> developing more professional skills and applying due diligence
>> and attention to detail to system design and implementation.
>>
>> I must be getting old, so what happened to pursuit of excellence
>> and more ?...
>>
>> Chris
>
> It's a question of provability. No current C project can implement the kind of toolchain that duplicates the compiler's static analysis proofs. And we haven't gotten to its runtime proofs. When combined with its runtime guarantees, it is a significant step forward.
> The compiler is only one part of Rust's toolchain, but that's another story.
>
> Here's a car analogy: do you want to change a tire using a power tool or good ol' muscles?
>
> If by chance we see this language on VMS within our lifetimes, we should be prepared. We'd be unstoppable.

Many years ago, worked on an avionics project where all the code
was written in micro assembler. That and other products
typically had a set of documents describing every aspect and stage
of the project. The was no concept ef mathematical provability,
and this was a safety critical system. Each module was individually
tested, where every line of the code was exercised to verify what
was in most cases, the obvious, but done anyway. At a higher level,
the whole system was subjected to rigorous testing with valid and
invalid data, stress testing, to confirm that it was doing as
expected.

What i's saying is that code integrity can be improved by various
means, but the main factor is always the process involved. Full
documentation at every stage of development, audit trail, peer
group code reviews, and a thorough test program to verify operation
to spec and reliability under extreme conditions. Problem is
that such a process is very expensive to do right and most companies
are not prepared to invest in that, especially with short
product lifetimes and pressure to get the product to market.

So the typical process these days is rapid development, which skimps
on process and testing and debugs the product at the customer. I
don't think any language can cure that, as it's the process and
attention to detail that are missing and no fault of the language
involved. To suggest that sort of thing can be fixed by the
current language fashion of the month is fantasy and ignores
the main problem...

Chris

On 04/07/22 15:59, Dan Cross wrote:
> In article<t2l9jp$b8i$1@gioia.aioe.org>,
> chris<chris-nospam@tridac.net> wrote:
>> On 04/06/22 01:25, Dan Cross wrote:
>> This sounds like medication to cure everyone from their sloppy
>> programming. The infantilisation of complex subjects, just to give the
>> lazy an easier time, while still getting the product built.
>> The answer to that is not languages that constrain movement, but
>> developing more professional skills and applying due diligence
>> and attention to detail to system design and implementation.
>>
>> I must be getting old, so what happened to pursuit of excellence
>> and more ?...
>
> Excellent practitioners curate their tools and select the ones
> that give them the best chance of maximizing the effectiveness
> of their work products. Ego driven machismo and disdain for
> tooling that helps prevent defects is a sign of an amateurish
> attitude towards software development, not that of a
> professional, let alone an engineer.
>
> - Dan C.
>
Agree 100% with that. Good engineers develop their own methods
and tools as experience accumulates. Having said that, if you
have been in the business for decades, you know what works and
what doesn't and what is fluff, so a certain arrogance and
intolerance of fools is normal. It's not an ego thing, but more
often hard won experience in product delivery, often against
the odds.

I don't apologise for that. Those who are not prepared to make
the effort to learn their craft and accept substandard should
not be in the business, no excuses...

Chris

On 4/7/22 08:46, chris wrote:
>
> Many years ago, worked on an avionics project where all the code
> was written in micro assembler. That and other products
> typically had a set of documents describing every aspect and stage
> of the project. The was no concept ef mathematical provability,
> and this was a safety critical system.

I can't fix The Olden Times. I consider software engineering to be a process, not an art. Art is that spontaneous flash of cultural creation.
Engineering is the slow process of putting an observatory into solar orbit at L2.

> Each module was individually
> tested, where every line of the code was exercised to verify what
> was in most cases, the obvious, but done anyway. At a higher level,
> the whole system was subjected to rigorous testing with valid and
> invalid data, stress testing, to confirm that it was doing as
> expected.

And how repeatable was that process?

> What i's saying is that code integrity can be improved by various
> means, but the main factor is always the process involved.

I'm glad we agree on that point!

> Full documentation at every stage of development, audit trail, peer
> group code reviews, and a thorough test program to verify operation
> to spec and reliability under extreme conditions. Problem is
> that such a process is very expensive to do right and most companies
> are not prepared to invest in that,
Full stop. Matter not do the following predicates
> especially with short product lifetimes and pressure to get the product to market.

It's Dilbert cartoons all the way down

> So the typical process these days is rapid development, which skimps
> on process and testing and debugs the product at the customer. I
> don't think any language can cure that, as it's the process and
> attention to detail that are missing and no fault of the language
> involved. To suggest that sort of thing can be fixed by the
> current language fashion of the month is fantasy and ignores
> the main problem...

With all respect, your confirmation bias is showing.

cheers,
jec

On 04/07/22 15:45, Dan Cross wrote:
> In article<t2l82r$1s8o$1@gioia.aioe.org>,
> chris<chris-nospam@tridac.net> wrote:
>> I don't like anything that claims or predisposes to protect me from
>> my own stupidity. Prefer the freedom to make my own mistakes and
>> learn from them. Not more nanny state, however fashionable it
>> may be...
>
> Seatbelts are for wimps, I guess. There's lots to be learned
> being thrown through the windshield of a moving car.
>
> - Dan C.
>

Strawman alert :-)...

On 04/07/22 15:57, Bill Gunshannon wrote:
> On 4/7/22 10:45, Dan Cross wrote:
>> In article <t2l82r$1s8o$1@gioia.aioe.org>,
>> chris <chris-nospam@tridac.net> wrote:
>>> I don't like anything that claims or predisposes to protect me from
>>> my own stupidity. Prefer the freedom to make my own mistakes and
>>> learn from them. Not more nanny state, however fashionable it
>>> may be...
>>
>> Seatbelts are for wimps, I guess. There's lots to be learned
>> being thrown through the windshield of a moving car.
>>
>
> Another problem, really but seatbelts are more of a matter of
> political control than safety. Other wise most states would
> not prohibit the use of 4 and 6 point belts in favor of 3 point
> belts with high failure rates that are also harder to get the
> occupant out of the car when overturned than the standard 4 or
> 6 point belt.
>
> bill

4 and six point probably came from aviation, but they are more
expensive, so no more analysis needed there :-)...

Chris

On 4/7/2022 10:59 AM, Dan Cross wrote:
> In article <t2l9jp$b8i$1@gioia.aioe.org>,
> chris <chris-nospam@tridac.net> wrote:
>> On 04/06/22 01:25, Dan Cross wrote:
>> This sounds like medication to cure everyone from their sloppy
>> programming. The infantilisation of complex subjects, just to give the
>> lazy an easier time, while still getting the product built.
>> The answer to that is not languages that constrain movement, but
>> developing more professional skills and applying due diligence
>> and attention to detail to system design and implementation.
>>
>> I must be getting old, so what happened to pursuit of excellence
>> and more ?...
>
> Excellent practitioners curate their tools and select the ones
> that give them the best chance of maximizing the effectiveness
> of their work products. Ego driven machismo and disdain for
> tooling that helps prevent defects is a sign of an amateurish
> attitude towards software development, not that of a
> professional, let alone an engineer.
>
> - Dan C.
>

Perhaps "excellent practitioners" choose to stick with what they know and are
competent with so as to avoid mistakes with something "new and better".

I have caught some flack from some here for choosing to not always declare
variables. I feel that such a practice is safe, if care and tools to verify
some things are in use. The opinions of others are just that, opinions, and
subjective.

I do find that the better the definition of the task, the fewer mistakes occur.

--
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 4/6/22 22:43, plugh wrote:
>
> Here's a car analogy: do you want to change a tire using a power tool or good ol' muscles?

You better learn how to do it with "good ol' muscles" because
when you get that flat at 2AM in the middle of nowhere there
will be no power tool to do it for you.

bill

On 4/7/2022 10:45 AM, Dan Cross wrote:
> In article <t2l82r$1s8o$1@gioia.aioe.org>,
> chris <chris-nospam@tridac.net> wrote:
>> I don't like anything that claims or predisposes to protect me from
>> my own stupidity. Prefer the freedom to make my own mistakes and
>> learn from them. Not more nanny state, however fashionable it
>> may be...
>
> Seatbelts are for wimps, I guess. There's lots to be learned
> being thrown through the windshield of a moving car.

Very true, but has nothing to do with what Chris wrote.

--
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 4/7/2022 10:57 AM, Bill Gunshannon wrote:
> On 4/7/22 10:45, Dan Cross wrote:
>> In article <t2l82r$1s8o$1@gioia.aioe.org>,
>> chris <chris-nospam@tridac.net> wrote:
>>> I don't like anything that claims or predisposes to protect me from
>>> my own stupidity. Prefer the freedom to make my own mistakes and
>>> learn from them. Not more nanny state, however fashionable it
>>> may be...
>>
>> Seatbelts are for wimps, I guess. There's lots to be learned
>> being thrown through the windshield of a moving car.
>>
>
> Another problem, really but seatbelts are more of a matter of
> political control than safety. Other wise most states would
> not prohibit the use of 4 and 6 point belts in favor of 3 point
> belts with high failure rates that are also harder to get the
> occupant out of the car when overturned than the standard 4 or
> 6 point belt.
>
> bill

Interesting. Are 4/6 point restraints actually prohibited? If so, call me a
scofflaw.

The thought that any government will ever get anything "right" is amusing ..

--
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 04/07/22 15:44, Dan Cross wrote:

>>
>> I wasn't suggesting that, but it takes years for all the issues
>> to be resolved and a language to become mature. That and the
>> language tends to be more fully documented formally. Sure, there
>> are always issues, but C has been around for long enough now that
>> most skilled users are to grips with the limitations and know
>> which potentially dangerous edge cases to avoid...
>
> That's demonstrably not true. C has become a tricky language,
> one where most people who claim to be "skilled C programmers"
> and who "know which potentially dangerous edge cases to avoid"
> are either compiler writers, or deluding themselves.
>
> PS: Rust will be 12 years old this year, but dates back to 2006.
>
> - Dan C.
>

Sorry, but that's absolute tripe. With minor effort, can still
build C code I wrote as far back as 1990, so it's about as
standard plain vanilla as any language could be.

The basic idea of a language as close as possible to the bare
metal, yet with enough capability for serious high level work,
with layered design, is as close to an ideal language as
anyone could wish for. Tricky language indeed ?, rofl...

Chris

On Thursday, April 7, 2022 at 9:09:08 AM UTC-7, Dave Froble wrote:
> Perhaps "excellent practitioners" choose to stick with what they know and are
> competent with so as to avoid mistakes with something "new and better".

There's always a learning curve. I'm pretty sure you didn't deploy a production version of your first Basic program
>
> I have caught some flack from some here for choosing to not always declare
> variables. I feel that such a practice is safe, if care and tools to verify
> some things are in use. The opinions of others are just that, opinions, and
> subjective.

Proof isn't subjective. That's the nice thing about rigor.
>
> I do find that the better the definition of the task, the fewer mistakes occur.

Agreed.

In article <t2n8va$1299$1@gioia.aioe.org>,
chris <chris-nospam@tridac.net> wrote:
>On 04/07/22 17:27, Dan Cross wrote:
>>> The basic idea of a language as close as possible to the bare
>>> metal, yet with enough capability for serious high level work,
>>> with layered design, is as close to an ideal language as
>>> anyone could wish for. Tricky language indeed ?, rofl...
>>
>> The "C is close to the hardware" thing hasn't been true a long
>> time now.
>>
>> https://queue.acm.org/detail.cfm?id=3212479
>
>Wrong again.

What, precisely, is wrong here?

>Mainly embedded work here and the first thing I
>do with a new architecture and tool set is to examine the assembler
>source to check for efficiency and sensible looking code. Even
>ten years ago, the gcc compiler often produced a single line
>of asm per C statement. That can be optimised by choices such
>as do while / for next style, for example. You can argue against
>that sort of thing, but you need to know your compiler to get the
>best out of it.

"It works with my compiler, so it's correct" used to get you
flamed out of e.g. comp.lang.c.

>That and being completely unambiguous in terms
>of source code and not trying to outsmart the compiler :-)...

It's funny that you are so fixated on compilers, but don't
really focus much on the language. The language is specified
against an abstract virtual machine that's behavior is
described in the language standard. What your program does is,
simply, not the same as what your hardware does.

Like you, I often have to read assembly language listings to
make sure I'm getting the output I expect. But I'm not a
cowboy about it.

- Dan C.

On 4/7/22 14:37, Dave Froble wrote:
> On 4/7/2022 12:13 PM, Bill Gunshannon wrote:
>> On 4/6/22 22:43, plugh wrote:
>>>
>>> Here's a car analogy: do you want to change a tire using a power tool
>>> or good
>>> ol' muscles?
>>
>> You better learn how to do it with "good ol' muscles" because
>> when you get that flat at 2AM in the middle of nowhere there
>> will be  no power tool to do it for you.
>>
>> bill
>>
>
> Batteries have come a long way ....
>

And I am sure everyone carries a battery powered impact wrench in their
Tesla.

bill

In article <t2n3cv$ed7$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>[snip]
>
>However, back to programming, restraints can happen in multiple ways. Good
>programming practices are one, tools that indicate questionable code another,
>and of course testing.

It somewhat boggles my mind that people are writing as if these
are mutually exclusive.

- Dan C.

In article <t2navi$sdf$2@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-04-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <jb8ci7F6634U2@mid.individual.net>,
>> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>>On 4/7/22 10:55, Dan Cross wrote:
>>>>
>>>>
>>>> I'm old enough to remember that, as well. Indeed, I read a
>>>> pre-alpha Java spec and thought it was pretty nifty at the time.
>>>> Then the snakeoil "Uncle Bob" types got a hold of it and it
>>>> became a bloated mess.
>>>
>>>Congratulations. You just described Ada. :-)
>>
>> *rimshot*
>>
>> But in fairness to Ada, I'm pretty sure that the agile snakeoil
>> folks would struggle mightily with it. Have the likes of Robert
>> C Martin ever actually delivered a large program?
>
>Ada forces you to think about your design. I consider that to be
>a good thing.

Indeed. Rust forces you to think similarly.

>BTW, I wouldn't mind seeing Ada's ranged integers showing up elsewhere,
>including being supported as an array index. That's a very nice feature
>of Ada.

That's a feature I would very much like to have.

- Dan C.

In article <t2na4b$sdf$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-04-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> I wonder where you are seeing that. Seriously. I know and/or
>> have worked with a number of members of the Rust community for
>> several years (members of the core, language, and tool teams,
>> for about 3 years), and they're quite gracious in admitting that
>> it's not the right solution for everything.
>
>That's nice to hear.
>
>As for where I am seeing it, it's more of a combined overall impression
>made up of gushing articles and what appears to be more like an organised
>religious cult (:-)) showing up at the usual places online.
>
>For example, articles that, instead of taking a balanced approach, spend
>the first 95% of the article saying how great and perfect Rust is, and only
>in the last 5% (if at all) start mentioning in passing the unsafe stuff
>"for when you really need to do that stuff".

Could you perhaps provide a citation to one of these articles?

- Dan C.

On 4/7/2022 1:39 PM, Simon Clubley wrote:
> On 2022-04-07, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> However, back to programming, restraints can happen in multiple ways. Good
>> programming practices are one, tools that indicate questionable code another,
>> and of course testing.
>>
>
> And programming languages that help stop you from making silly mistakes,
> but also let you do unsafe work when needed. I posted a couple of links
> from the Ada 95 Style Guide the other day that addresses exactly this issue.
>
> BTW, testing can only prove the presence of bugs and not the absence
> of them. Someone else can still come along and do testing in a different
> way that finds undiscovered issues. Look at the stuff about EVL that
> I posted recently as an example.
>
> Simon.
>

Not if all possible outcomes are expected and handled.

A good design will include handling all possible outcomes. Anything else is
just when, not if, something unexpected occurs.

--
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

In article <t2n1o9$1fjb$1@gioia.aioe.org>,
chris <chris-nospam@tridac.net> wrote:
>On 04/07/22 15:59, Dan Cross wrote:
>> In article<t2l9jp$b8i$1@gioia.aioe.org>,
>> chris<chris-nospam@tridac.net> wrote:
>>> On 04/06/22 01:25, Dan Cross wrote:
>>> This sounds like medication to cure everyone from their sloppy
>>> programming. The infantilisation of complex subjects, just to give the
>>> lazy an easier time, while still getting the product built.
>>> The answer to that is not languages that constrain movement, but
>>> developing more professional skills and applying due diligence
>>> and attention to detail to system design and implementation.
>>>
>>> I must be getting old, so what happened to pursuit of excellence
>>> and more ?...
>>
>> Excellent practitioners curate their tools and select the ones
>> that give them the best chance of maximizing the effectiveness
>> of their work products. Ego driven machismo and disdain for
>> tooling that helps prevent defects is a sign of an amateurish
>> attitude towards software development, not that of a
>> professional, let alone an engineer.
>
> Agree 100% with that. Good engineers develop their own methods
>and tools as experience accumulates. Having said that, if you
>have been in the business for decades, you know what works and
>what doesn't and what is fluff, so a certain arrogance and
>intolerance of fools is normal. It's not an ego thing, but more
>often hard won experience in product delivery, often against
>the odds.

That's funny. I've observed things changing significantly
across the industry in the last ~3 decades.

Entire new classes of problems that were once obscure research
domains have become the workaday domain of everyday programmers
(parallel programming, multithreading, distributed systems).
Interactivity has gone from terminals to graphical workstations
to web browsers. The unit of computing has gone from one CPU to
a multicore machine to a rack to a datacenter and beyond. We've
gone from "testing" being something lesser humans did to an
accepted practice performed by programmers and carried out in an
automated fashion.

Distributed, scalable systems hosted in geographically dispersed
facilities, often pushed automatically by continuous integration
pipelines fed by distributed revision control repositories are
the new normal for tens of thousands of programmers across the
industry.

So yeah, keep what works (let's be honest: mostly techniques),
but if you're not also keeping up with the changes in technology
you're going to be left behind in an asymptotically shrinking
pool of legacy technology.

>I don't apologise for that. Those who are not prepared to make
>the effort to learn their craft and accept substandard should
>not be in the business, no excuses...

I think it's odd that people reject better tooling while they
assert that programmers should "make the effort to learn their
craft." Why are these things perceived as mutually exclusive?
Indeed, why isn't part of learning the "craft" adopting better
tooling? And who suggested accepting substandard results?

On the other hand, those who stick their collective heads in the
sand and pretend that the same old techniques using the same old
tools in the same old way should consider leaving the business.

- Dan C.

In article <t2n2b1$nvk$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>On 4/7/2022 10:59 AM, Dan Cross wrote:
>> In article <t2l9jp$b8i$1@gioia.aioe.org>,
>> chris <chris-nospam@tridac.net> wrote:
>>> On 04/06/22 01:25, Dan Cross wrote:
>>> This sounds like medication to cure everyone from their sloppy
>>> programming. The infantilisation of complex subjects, just to give the
>>> lazy an easier time, while still getting the product built.
>>> The answer to that is not languages that constrain movement, but
>>> developing more professional skills and applying due diligence
>>> and attention to detail to system design and implementation.
>>>
>>> I must be getting old, so what happened to pursuit of excellence
>>> and more ?...
>>
>> Excellent practitioners curate their tools and select the ones
>> that give them the best chance of maximizing the effectiveness
>> of their work products. Ego driven machismo and disdain for
>> tooling that helps prevent defects is a sign of an amateurish
>> attitude towards software development, not that of a
>> professional, let alone an engineer.
>
>Perhaps "excellent practitioners" choose to stick with what they know and are
>competent with so as to avoid mistakes with something "new and better".

Maybe those practitioners aren't actually as excellent as they
think they are.

>I have caught some flack from some here for choosing to not always declare
>variables. I feel that such a practice is safe, if care and tools to verify
>some things are in use. The opinions of others are just that, opinions, and
>subjective.

*shrug* How do your maintainers feel about that?

It's odd to me that there are folks about being facile with
tools and languages and hard-earned experience, yet they reject
the very things that collective experience has taught the
industry at large. We know, for instance, that statically typed
languages have fewer defects than dynamically typed languages,
just as we know that declaring variables can serve documentary
and pedagogical purposes.

>I do find that the better the definition of the task, the fewer mistakes occur.

Can't argue with that.

- Dan C.

On 4/7/2022 12:24 PM, Bill Gunshannon wrote:
> On 4/7/22 12:06, chris wrote:
>> On 04/07/22 15:57, Bill Gunshannon wrote:
>>> On 4/7/22 10:45, Dan Cross wrote:
>>>> In article <t2l82r$1s8o$1@gioia.aioe.org>,
>>>> chris <chris-nospam@tridac.net> wrote:
>>>>> I don't like anything that claims or predisposes to protect me from
>>>>> my own stupidity. Prefer the freedom to make my own mistakes and
>>>>> learn from them. Not more nanny state, however fashionable it
>>>>> may be...
>>>>
>>>> Seatbelts are for wimps, I guess. There's lots to be learned
>>>> being thrown through the windshield of a moving car.
>>>>
>>>
>>> Another problem, really but seatbelts are more of a matter of
>>> political control than safety. Other wise most states would
>>> not prohibit the use of 4 and 6 point belts in favor of 3 point
>>> belts with high failure rates that are also harder to get the
>>> occupant out of the car when overturned than the standard 4 or
>>> 6 point belt.
>>>
>>> bill
>>
>> 4 and six point probably came from aviation,
>
> No, from racing where they have been developed, tested and refined
> in automobiles for decades.
>
>> but they are more
>> expensive, so no more analysis needed there :-)...
>
> Expensive isn't part of the argument. Even if I am willing to pay
> the added expense (and in many cases I would be) the various DOT's
> will not allow their use.

You got any pointers to info on that?

--
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