In article <t2nc9n$91k$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>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.
>
>Not if all possible outcomes are expected and handled.

The exponential explosion of potential states in even simple
programs means that this is not realistic. Once multiple
threads of execution are involved, it's usually game over.
Combinatorics is something that every programmer should have
some working knowledge of.

Simply put, the _only_ thing that tests can show is that a
given program works as expected for some set of inputs in the
highly controlled and constrained testing environment. That's
extremely useful, and programmers should write tests liberally,
but it is not proof of correctness.

Contrast this with a langauge that simply won't allow you to
express a program that exhibits a certain class of problem.

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

Testing isn't a great way to ensure this.

- Dan C.

On 4/7/2022 2:42 PM, Bill Gunshannon wrote:
> 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

I cannot speak for "everyone", and it's not my fault some are not prepared.
Some of us carry a decent emergency kit in our vehicles.

Unfortunately I haven't yet acquired that Tesla.

Gas is now around $4.30/gal.

:-)

--
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/22 15:03, Dave Froble wrote:
> 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?
>
>
https://automodifying.com/are-racing-harnesses-street-legal/

bill

In article <jb8gsmF6ugqU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> 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.

This is missing the point of the analogy.

We're purporting ourselves to be professionals here, correct?
In a professional automotive shop, what's more likely: they've
got a set of professional-quality power tools for quickly
removing lug nuts, or they're out there with a wrench all the
time? Even in the cases where the power tool isn't appropriate
(or fails) a professional garage is going to have high quality
tools and know how to use them appropriate for the job at hand.

Some poor slob changing a tire on the side of the road is more
analogous to an amateur or hobby programmer.

- Dan C.

On 4/7/2022 2:59 PM, Dan Cross wrote:
> 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.
>

Perhaps it could be the language itself that is a problem.

I've looked at a few examples. The syntax is worse than C, which itself really
sucks.

My choice when seeing good new techniques would be to incorporate them into my
current language of choice, which I'm familiar with, not to abandon what I'm
familiar with and works well.

--
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 <t2ndd8$10m$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>On 4/7/2022 2:59 PM, Dan Cross wrote:
>> 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.
>
>Perhaps it could be the language itself that is a problem.
>
>I've looked at a few examples. The syntax is worse than C, which itself really
>sucks.

That's subjective.

>My choice when seeing good new techniques would be to incorporate them into my
>current language of choice, which I'm familiar with, not to abandon what I'm
>familiar with and works well.

Indeed. Learning Rust made me a better C programmer. For that
matter, it made me a better assembly language programmer.

But the critical part of what you wrote above is that you're
asserting that what you use _works well_. If it works well,
then that's great. No one is suggesting abandoning what works
_well_. But as the industry evolves, we sometimes find that
what _worked_ well 10, 15 or 20 years ago doesn't work as well
now, or that other tools _work better_.

- Dan C.

On 4/7/2022 3:03 PM, Dan Cross wrote:
> 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.

Then again, maybe 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?

Once maintainers are familiar with company standards and practices, they are
quite alright with the practice.

I just don't feel I should do the grunt work when I have a compiler to do it for
me. Then again, because of what I consider deficiencies in the compiler, I've
had to develop tools to process compiler listings looking for issues. Damn
compiler has the info, it should do that work also.

Another factor is, many variables are declared, for various reasons. Not so
many are undeclared.

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

"We know that?"

I'm not so sure about that.

Seems to me that a compiler that needs to figure out a few things might be more
precise than one which just assumes what it's given. But maybe that's just my
prejudice.

>> I do find that the better the definition of the task, the fewer mistakes occur.
>
> Can't argue with that.
>
> - Dan C.
>

--
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 2:43 PM, Dan Cross wrote:
> 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.
>

Not exclusive, required.

--
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 19:42, Dan Cross wrote:
> 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.

Fixated on compilers ?, looks like projection to me :-).

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

Now you are arm waving and can't resist sly ad hom, suggesting
you have nothing valid to say and possibly insecure about the
merits of you favourite solution.

We are all different. You seem interested in language design,
whereas a compiler is just a tool in the box and part of a
much larger system framewwork for me. It either produces the code
I expect it to, or it fails. If you like rust, go for it, but
I see no value for the work done here and I don't feel the
need to knock it, as C has a rich history going back decades
and is a proven solution for a wide variety of different work...

Chris

On 04/07/22 20:17, Dan Cross wrote:
> In article<jb8gsmF6ugqU1@mid.individual.net>,
> Bill Gunshannon<bill.gunshannon@gmail.com> 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.
>
> This is missing the point of the analogy.
>
> We're purporting ourselves to be professionals here, correct?
> In a professional automotive shop, what's more likely: they've
> got a set of professional-quality power tools for quickly
> removing lug nuts, or they're out there with a wrench all the
> time? Even in the cases where the power tool isn't appropriate
> (or fails) a professional garage is going to have high quality
> tools and know how to use them appropriate for the job at hand.
>
> Some poor slob changing a tire on the side of the road is more
> analogous to an amateur or hobby programmer.
>
> - Dan C.
>

I would prefer the simplest technology as backup, as that is
less likely to fail than a more complex solution. For wheel
change, that means a manual jack, wheel brace or spanner
and foot pump, which I always keep in the car. Only needed
once a flood anyway, so the simpler and more space saving
the better. Must be the practical engineer in me, less is
more etc...

Chris

In article <t2ne22$dl0$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>>> 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?
>
>Once maintainers are familiar with company standards and practices, they are
>quite alright with the practice.
>
>I just don't feel I should do the grunt work when I have a compiler to do it for
>me. Then again, because of what I consider deficiencies in the compiler, I've
>had to develop tools to process compiler listings looking for issues. Damn
>compiler has the info, it should do that work also.
>
>Another factor is, many variables are declared, for various reasons. Not so
>many are undeclared.

Lack of consistency creates cognitive load for readers. Code is
read many more times than it's written or changed.

>> 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.
>
>"We know that?"
>
>I'm not so sure about that.

Fortunately, we have empirical evidence we can evaluate.

https://danluu.com/empirical-pl/

- Dan C.

On 04/07/22 19:59, Dan Cross wrote:
> 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.

and, point being ?. How is that relevant ot what I said ?.

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

Yes, oh, the complexity :-).

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

Obviously, tech is a lifelong learning experience, always a
student makes it very attractive. Take the best or useful
ideas of the new, while maintaining core expertise in the
current technology. In practice though, real time embedded
work hasn't changed significantly in decades. Yes, we have more
powerful processors, embedded linux and more, but the core
techniques remain the same. No longer counting cycles in
interrupt handlers on 6502, or writing complete systems in
macro 11 asm (Yes, PDP11 was used extensively in oem real time
embedded systems). All those older systems have been outclassed
for years now, but the basic comp sci techniques developed back
then can still be of value in the present.

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

There you are again, another dig at others suggest insecurity, but
I digress. Fortunately, people like you don't get to decide who
works in the business and who doesn't. That's decided by project
managers and engineers who look for the right kind of experience
and attitude for the work they are trying to get done...

Chris

On 04/07/22 20:03, Dan Cross wrote:
> 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.
>

Far too much of an academic attitude. It's an imperfect world and
in real life, systems get designed and built within the constraints
of available tech of the day. Usually too much risk in working at
the bleeding edge of tech, especially with unproven tools. Someone
has to do that and be pathfinder though. Most of it sinks like a
stone, but the best and most useful becomes part of the
mainstream. Natural selection at work, but we all progress by
standing on the shoulders of giants...

>> 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 11:59 AM, chris 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.

No.

Bad developers go for DIY methods and tools.

Good developers stand on the shoulders of giants.

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

What works does rarely change.

But what is optimal changes over time.

As new technologies become available and the price
of various types of resources changes then what
is the optimal choice change.

Classic example is that like 50 years ago it
may have made perfect sense to hand code stuff
in assembler to save a few KB of memory and
a some instructions executed. Today cost of memory
and CPU power has dropped several orders of
magnitude compared to developer hours and
compiler have become must better at optimizing.
It is not worth it.

Arne

On 4/7/2022 5:50 PM, chris wrote:
> On 04/07/22 19:59, Dan Cross wrote:
>> In article<t2n1o9$1fjb$1@gioia.aioe.org>,
>> chris<chris-nospam@tridac.net>  wrote:
>>> 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.
>
> There you are again, another dig at others suggest insecurity, but
> I digress. Fortunately, people like you don't get to decide who
> works in the business and who doesn't.

"And why beholdest thou the mote that is in thy brother's eye, but
considerest not the beam that is in thine own eye?"

> That's decided by project
> managers and engineers who look for the right kind of experience
> and attitude for the work they are trying to get done...

Hopefully project managers are never involved in making
decisions about tech stack as it is not a project management
matter.

Decisions about tech stack is an architecture matter and
architects should be the primary decision makers. They
can solicit input from software engineering to verify
that would should work actually does work in practice.

Arne

On 4/7/2022 12:19 PM, chris wrote:
> 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.
>
> 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.

C language is pretty well standardized

The standard C library is very small, but that is just a choice.

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

C is a tricky language.

It is an observable fact that buffer overruns and
memory leaks flourish in C programs and would not
happen in many other languages.

It is an observable fact that many likely most C
programs only work as intended with some compilers/platforms
combination, but are not guaranteed to work on any
compliant C compiler due to all the undefined behavior
and implementation specific behavior in the C standard.

Arne

On 4/7/2022 12:27 PM, Dan Cross wrote:
> In article <t2n2u6$3jv$1@gioia.aioe.org>,
> chris <chris-nospam@tridac.net> 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

That is a rather unusual definition of close to HW.

A way more common definition is that the language can
actually directly access HW.

Work with memory mapped devices etc.. And C typical
does that great. C pointers can for good or worse
point anywhere. Totally platform specific code,
but it does it on Linux, Windows, VMS etc..

Additionally close to HW may imply that not too
much is happening under the hood.

Arne

On 4/7/2022 8:31 AM, Simon Clubley wrote:
> On 2022-04-06, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/6/2022 6:51 PM, VAXman-@SendSpamHere.ORG wrote:
>>> Rust as a high school language? I believe schools should be concentrating on
>>> reading, writing and mathematics with special emphasis on the mathematics. I
>>> can not believe that colleges need to offer remedial mathematics such as basic
>>> algebra to their incoming freshmen. Writing should be a close second. Writing
>>> as if "texting" friends is not composition.

>> The idea about teaching programming in secondary or primary school
>> come up frequently.
>>
>> Mostly from people that don't know programming.
>>
>> I don't think it make any sense. The available time will be
>> so small and the level taught so low that it will not be
>> useful. It does not provide the IT industry with something
>> they can use. And it does not provide any valuable skills to
>> the students.
>
> Back when I was in secondary school (early 1980s) programming classes
> _were_ along the subjects offered. Basic was the language in use but
> I also came across this new language called Fortran and started doing
> the assignments in that language as well as in Basic just for fun. :-)
>
> And you are wrong Arne in an important way. You don't get any direct
> skills that you can use in industry but it exposes students to what
> is involved in writing programs and the mindset required.
>
> It became obvious to me very quickly that this was something I _really_
> liked and made me consider it as my possible future (which obviously
> turned into reality).

It may work as a recruiting mechanism for IT relevant tertiary
educations.

But what is learnt in that context is something that eventually
has to be unlearned to actually become good at software development.

Software development has very little to do with typing in
lines of code.

Arne

On 4/7/2022 10:26 AM, Bill Gunshannon wrote:
> On 4/7/22 10:02, Dave Froble wrote:
>> Instructing a dumb (but very fast) computer how to accomplish some
>> task requires some special ways of approaching the job.  Some people
>> "get it", some people don't, and early exposure to the techniques can
>> be helpful.
>
> My experience in academia doesn't agree. We have had students come in
> with "experience" and "Computer Science Education" prior to the start
> of their college courses. (and many of them started with BASIC, usually
> on an Apple)  They have a higher likelihood of failing and dropping
> out.  Usually because they come in thinking they already know all about
> it when in fact that never had the basics  one should learn before they
> write that first program.  All this current craze for "coding" for
> everyone down to pre-school does not bode well for the industry.

The lessons learned in such early programming is that:
- software development is about typing in lines of code
- software development is pretty easy
and that is really worse than nothing.

They would do way better if they had taken math at a higher
level. That would have learned them the right way of thinking.
And then they could learn software development later.

Arne

On 4/7/2022 2:58 PM, Dave Froble wrote:
> On 4/7/2022 1:39 PM, Simon Clubley wrote:
>> 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.
>
> 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.

True.

But not particular relevant.

Too many cases to test.

If your program take 1 KB of input then there are
2**8192 possible inputs. That is a pretty big number.

But it is what it takes to prove that this
program is correct by test.

Of course you can probably pick a couple of handful
careful designed test cases and if they work, then you
are somewhat optimistic that the program will work in
general. But that is different from proving.

Arne

On 4/7/2022 11:46 AM, 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. 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...

No tool or language can solve all problems.

But one like to automate what can be automated.

More safe languages and code analysis tools are
cost efficient ways to improve software quality
compared to manual code review.

If the tools find a large part of the problems
then the reviews does not drown in issues.

If the language like Rust (and C# even though
almost never used) sort of flag the code sections
where it makes sense to focus on reviews in the
form of unsafe blocks, then it again help
the reviews.

Arne

On 4/7/2022 11:38 AM, Dan Cross wrote:
> Have the likes of Robert
> C Martin ever actually delivered a large program?

He developed software in the Telecom business for
many years before starting to focus on writing and
training.

Arne

On 4/7/2022 8:01 PM, Arne Vajhøj wrote:

> Bad developers go for DIY methods and tools.

Let me ask, just where do you think good methods and tools come from?

> Good developers stand on the shoulders of giants.

Where do you think the giants come from?

Hint, it is NOT academia!

--
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 8:36 PM, Arne Vajhøj wrote:
> On 4/7/2022 2:58 PM, Dave Froble wrote:
>> On 4/7/2022 1:39 PM, Simon Clubley wrote:
>>> 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.
>>
>> 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.
>
> True.
>
> But not particular relevant.
>
> Too many cases to test.
>
> If your program take 1 KB of input then there are
> 2**8192 possible inputs. That is a pretty big number.
>
> But it is what it takes to prove that this
> program is correct by test.
>
> Of course you can probably pick a couple of handful
> careful designed test cases and if they work, then you
> are somewhat optimistic that the program will work in
> general. But that is different from proving.

I was not discussing data or testing. I was discussing program design.

As a simple example, I've seen code that invokes a system service and them maybe
tests the service completion. Never takes into consideration that there is a
completion status of invoking the service. Would it not be relevant to know
that the QIO did not fail, it was the queuing of the QIO that failed.

Such stuff, including my favorite "that never happens".

--
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 <t2nk1q$1p31$1@gioia.aioe.org>,
chris <chris-nospam@tridac.net> wrote:
>On 04/07/22 19:42, Dan Cross wrote:
>> 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?

I reiterate the question.

>>> 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.
>
>Fixated on compilers ?, looks like projection to me :-).

Well, you've brought up GCC and looking at the listings, but
haven't touched on the standard. That indicates a tendancy to
look at what a _compiler_ does instead of what the _langauge_
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.
>
>Now you are arm waving and can't resist sly ad hom, suggesting
>you have nothing valid to say and possibly insecure about the
>merits of you favourite solution.

I'll admit that the cowboy quip could be interpreted poorly, so
I apologize for that. But the rest of your interpretation is
just wrong. I don't have a "favorite solution"; I keep abreast
of developments and adopt what I perceive to be the most
appropriate solution for a given problem domain at the time when
I need it; this is always a tradeoff, and "most appropriate"
means a combination of technology, maturity, industry knowledge,
etc.

>We are all different. You seem interested in language design,
>whereas a compiler is just a tool in the box and part of a
>much larger system framewwork for me. It either produces the code
>I expect it to, or it fails. If you like rust, go for it, but
>I see no value for the work done here and I don't feel the
>need to knock it, as C has a rich history going back decades
>and is a proven solution for a wide variety of different work...

Where we seem to differ is that I concede that the set of most
appropriate tools changes over time as the industry as a whole
advances, and that tools (such as languages) that allow me to
express programs more safely and provide me with more expressive
power tend to yield better programs than those that do not.

I've given citations to why, e.g., C may be falling from favor,
and why some of the participants in this conversation may be
wrong in their perceptions of that language. The response has
mostly been assertions without supporting evidence, and
statements implying that safer languages somehow limit the
programmer; usually these are made by people with no or very
limited experience in the languages in question.

- Dan C.