On 2022-04-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/8/2022 3:20 PM, Simon Clubley wrote:
>> On 2022-04-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>>
>>> Could you perhaps provide a citation to one of these articles?
>>>
>>
>> Interesting question. I obviously can't remember the locations of
>> the articles I found in the past, so I looked at a small sample of
>> articles returned by Google to see if I had problems with them.
>>
>> Comments below.
>>
>> https://dev.to/katholder/pros-and-cons-of-rust-language-313i
>>
>> Obviously a gushing user type writeup with non of the serious
>> analysis and flaws such as unsafe code you would expect to see.
>
> That article is pretty bad. 99% filler.
>

Yes, it is. I included it because it was one of the first articles
Google returned to me when I did a search for Rust language articles.

>> https://codilime.com/blog/why-is-rust-programming-language-so-popular/
>>
>> Mentions briefly unsafe mode
>
> There are 3 sections about it.
>
>> but doesn't make it clear that you can
>> invalidate _all_ the unique features and guarantees in Rust when you
>> use it.
>
> It doesn't because that is not the case.
>
> It disable some features but not all - among other things it does
> not disable memory ownership.
>

To go back to one of the examples I posted recently (which I picked at
random from a list of Rust CVEs):

https://rustsec.org/advisories/RUSTSEC-2020-0148.html

|Affected versions of this crate have the following issues:
| |Ptr implements Send and Sync for all types, this can lead to data races by
|sending non-thread safe types across threads.
|

Avoiding data races is advertised as a core feature of Rust and this
library managed to violate that rule.

|Ptr::get violates mutable alias rules by returning multiple mutable
|references to the same object.
|

_This_ violates the core feature of Rust which is the borrow checker.

|Ptr::write uses non-atomic writes to the underlying pointer. This means
|that when used across threads it can lead to data races.

Another data races problem.

>
>> Based on the complete bypassing of Rust's unique features seen in the
>> CVEs when running in unsafe mode,
>
> Your assumption about unsafe bypassing everything is simply wrong.
>

I'd call the above examples of the complete bypassing of Rust's unique
features. And it doesn't even matter how they did it. What matters is
that they did.

>> the following is either wrong or at
>> least misleading depending on how you look at it:
>>
>> |Rust lets you live dangerously if you need to, to a point. Rust's safeties
>> |can be partly suspended where you need to manipulate memory directly, such
>> |as dereferencing a raw pointer a la C/C++. The key word is partly, because
>> |Rust's memory safety operations can never be completely disabled. Even
>> |then, you almost never have to take off the seatbelts for common use cases,
>> |so the end result is software that's safer by default.
>>
>> Can never be fully disabled ? There are a set of CVEs that say otherwise.
>
> No.
>
> Some memory safety can be disabled by unsafe. And the CVE's are
> example of that.
>
> The CVE does not show all memory safety disabled.
>
> That is your imagination.
>

Just this one CVE shows the borrow checker being bypassed and the
eliminating data races feature of Rust also being bypassed.

I also posted another example of a traditional buffer overflow issue.

I would call this all memory safety being disabled, so no, it's not
my imagination.

>>
>> https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html
>>
>> Not the first time I have seen that type of mistake elsewhere. Interesting
>> that Rust can have the same problem and that it wasn't detected until now.
>
> There are still plenty of opportunities for problems in Rust.
>

Would be nice if those articles pointed that out instead of gushing
over Rust in the same way as people did over Java in the early days.

Simon.

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

On Friday, April 8, 2022 at 2:14:33 PM UTC-7, Simon Clubley wrote:
> On 2022-04-08, Arne Vajhøj <ar...@vajhoej.dk> wrote:

> Just this one CVE shows the borrow checker being bypassed and the
> eliminating data races feature of Rust also being bypassed.
>
> I also posted another example of a traditional buffer overflow issue.
>
> I would call this all memory safety being disabled, so no, it's not
> my imagination.

The point, of course, is that while you can make this kind of error within an unsafe block (?) section (? I don't actually know much about rust), outside of these explicitly marked unsafe sections of code you are prevented from accidentally making these errors.

Discounting this as being worthless is well ... uhhh ... I can't really think of any thing polite to say so I'll just sit here shaking my head.

On Friday, April 8, 2022 at 10:13:21 AM UTC-7, Arne Vajhøj wrote:
> On 4/7/2022 2:46 PM, Dan Cross wrote:
> > In article <t2navi$sdf$2...@dont-email.me>,
> > Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> >> 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.
>
> Pascal has it.
>
> :-)
>
> $ type ar.pas
> program ar(input,output);
>
> type
> r = 1..3;
> a = array[r] of integer;

Yes, ADA took the idea from Pascal.

The Oregon Software Pascal-2 compiler leveraged this to reduce checking (when checking was enabled) and that worked reasonably well if the programmer was careful about declaring ranges when it made sense to do so.

On 2022-04-08, Don Baccus <dhogaza@gmail.com> wrote:
> On Friday, April 8, 2022 at 2:14:33 PM UTC-7, Simon Clubley wrote:
>> On 2022-04-08, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
>> Just this one CVE shows the borrow checker being bypassed and the
>> eliminating data races feature of Rust also being bypassed.
>>
>> I also posted another example of a traditional buffer overflow issue.
>>
>> I would call this all memory safety being disabled, so no, it's not
>> my imagination.
>
> The point, of course, is that while you can make this kind of error within an unsafe block (?) section (? I don't actually know much about rust), outside of these explicitly marked unsafe sections of code you are prevented from accidentally making these errors.
>
> Discounting this as being worthless is well ... uhhh ... I can't really think of any thing polite to say so I'll just sit here shaking my head.

At no point have I called the features Rust offers in safe mode worthless.

I'm just taking issue with the claims in the articles I quoted, about
still been somewhat protected in unsafe mode, by pointing to actual
CVEs that violated the basic core features of Rust (the borrow checker
and the data races protection) that its advocates say make Rust unique.

Simon.

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

On 04/08/22 13:30, Dan Cross wrote:
> In article<t2nn0k$rns$1@gioia.aioe.org>,
> chris<chris-nospam@tridac.net> wrote:
>> Far too much of an academic attitude.
>
> Sounds like one of those "ad hominem on the sly" things you
> were talking about.

Not an insult. We need the academics to do the research, but it's
the engineers who have to translate the theory into usable product,
where possible.

>
>> 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.
>
> Static typing is not an "unproven tool".
>
> - Dan C.
>

Don't remember discussing static typing at all...

Chris

On 04/08/22 01:07, Arne Vajhøj wrote:
> 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
>

In companies i've worked for, many of them, only the tech /
team leaders have enough of a grip on a project to know what
skills are required for the task and the sort of personality
that would fit into the team. In the UK, it's usually someone
at senior tech level that runs the interview, never HR.
HR may run the background checks, but are rarely qualified
to ask the right questions from a tech point of view.

Might be different in the US though...

Chris

On 04/08/22 13:26, Dan Cross wrote:

>
> I was responding to the culmination of three things that you
> 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."

>
> And then,
>
> "[...] 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."
>
> And finally, an allusion to, "often hard won experience in
> product delivery".
>
> So in the first quote, you seem to be asserting that safer
> languages are for the lazy who just don't want to put in the
> work, while in the second, you refer to "what works and what
> doesn't and what is fluff", but without acknowledging that new
> techniques and tools are introduced all the time.

If you intentionally misrepresent in joining the dots,
expect to reach the wrong conclusions.

>
> And finally you allude to your "hard won experience" while
> simultaneously discounting others who disagree with you.

Remind me, where did I discount others ?.

>
> Taken together, this seems to indicate an attitude of, "if it
> ain't broke, don't fix it" and aversion to incorporating change,
> which seems strange. Truly, is the way you develop software
> _now_ the same as how you developed software 25 years ago?

In a lot of ways, yes and true of many companies i've done work
for in the past. Don't know where you have been, but most
companies prefer proven methods over fashion, because it reduces
risk and cost overruns. Sure, keep an eye on new ideas, but
stick to core to get the job done and meet targets. The tools change,
but the overall process remains largely the same.

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

Now we have it: Perhaps you are pre conditioned by the idea
that vms is a dinosaur that has no place in "modern
computing" ?. Far from it, may have had a difficult time with
HP, but a robust os still in wide use and under active
development.

>>
>> 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.
>
> Yes, but the critical point is that the "current technology"
> changes.

Repeating the obvious gets tiresome after a while.

>

>>>
>>> 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...
>
> You seem to be taking what I say rather personally. Perhaps
> don't?

Well, "better" is subjective. If you have a system that
produces results, why does it need to be fixed ?. Use a wide
variety of tools for clients, various ide's scripting and more,
but still wedded to an ancient editor and makefile environment
for my own work.

You seem to be suggesting that those who value proven but
not leading edge development methods are somehow deficient. If so,
expect a response.Rants about Head in sand attitudes don't
help either.

If you want to be an evangelist for rust, good for you, but
sorry, just suspicious of salesman of any kind, however good
the product. Far from mainstream and proven so far, even
though it's been around for (what did you say ?) 10+ years,
suggests it's not a great hit anywhere.

>
> On the other hand, you write the following about those of us who
> choose to use safer tools:
>
> "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."
>

Some sections of society these days seem to think rewarding failure
a good idea, but not everyone would agree. Good programming is not
about language or tools, but an attitude of mind, like all professional
work. That's what I was trying to get across...

Chris

On Friday, April 8, 2022 at 6:03:09 PM UTC-7, chris wrote:
> On 04/08/22 13:26, Dan Cross wrote:
>
> >
> > I was responding to the culmination of three things that you
> > 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."
>
> >
> > And then,
> >
> > "[...] 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."
> >
> > And finally, an allusion to, "often hard won experience in
> > product delivery".
> >
> > So in the first quote, you seem to be asserting that safer
> > languages are for the lazy who just don't want to put in the
> > work, while in the second, you refer to "what works and what
> > doesn't and what is fluff", but without acknowledging that new
> > techniques and tools are introduced all the time.
>
> If you intentionally misrepresent in joining the dots,
> expect to reach the wrong conclusions.
>
> >
> > And finally you allude to your "hard won experience" while
> > simultaneously discounting others who disagree with you.
>
> Remind me, where did I discount others ?.
>
> >
> > Taken together, this seems to indicate an attitude of, "if it
> > ain't broke, don't fix it" and aversion to incorporating change,
> > which seems strange. Truly, is the way you develop software
> > _now_ the same as how you developed software 25 years ago?
>
> In a lot of ways, yes and true of many companies i've done work
> for in the past. Don't know where you have been, but most
> companies prefer proven methods over fashion, because it reduces
> risk and cost overruns. Sure, keep an eye on new ideas, but
> stick to core to get the job done and meet targets. The tools change,
> but the overall process remains largely the same.
>
> >
> >>> 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.
>
> Now we have it: Perhaps you are pre conditioned by the idea
> that vms is a dinosaur that has no place in "modern
> computing" ?. Far from it, may have had a difficult time with
> HP, but a robust os still in wide use and under active
> development.
>
> >>
> >> 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.
> >
> > Yes, but the critical point is that the "current technology"
> > changes.
>
> Repeating the obvious gets tiresome after a while.
> >
>
> >>>
> >>> 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...
> >
> > You seem to be taking what I say rather personally. Perhaps
> > don't?
>
> Well, "better" is subjective. If you have a system that
> produces results, why does it need to be fixed ?. Use a wide
> variety of tools for clients, various ide's scripting and more,
> but still wedded to an ancient editor and makefile environment
> for my own work.
>
> You seem to be suggesting that those who value proven but
> not leading edge development methods are somehow deficient. If so,
> expect a response.Rants about Head in sand attitudes don't
> help either.
>
> If you want to be an evangelist for rust, good for you, but
> sorry, just suspicious of salesman of any kind, however good
> the product. Far from mainstream and proven so far, even
> though it's been around for (what did you say ?) 10+ years,
> suggests it's not a great hit anywhere.
>
> >
> > On the other hand, you write the following about those of us who
> > choose to use safer tools:
> >
> > "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."
> >
>
> Some sections of society these days seem to think rewarding failure
> a good idea, but not everyone would agree. Good programming is not
> about language or tools, but an attitude of mind, like all professional
> work. That's what I was trying to get across...
>
> Chris

"Good programming is not about language or tools, but an attitude of mind"

Remind me why you stopped doing all of your work in assembler again?

On 4/8/2022 4:59 PM, Arne Vajhøj wrote:
> And it pulled a lot of new concepts into mainstream
> software development - the concepts were not necessarily
> invented in the Java world, but the Java world
> was where they had their first success driving their
> adaptation elsewhere:
>
> focus on interface inheritance over implementation inheritance
> reflection
> garbage collection
> JIT compilation
> ORM (entity beans with CMP)

DI (Spring)

> logging frameworks (log4j)
> unit testing (JUnit)
> etc.

Arne

On 4/8/2022 9:16 PM, Don Baccus wrote:
> On Friday, April 8, 2022 at 6:03:09 PM UTC-7, chris wrote:
>> On 04/08/22 13:26, Dan Cross wrote:
>>
>>>
>>> I was responding to the culmination of three things that you
>>> 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."
>>
>>>
>>> And then,
>>>
>>> "[...] 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."
>>>
>>> And finally, an allusion to, "often hard won experience in
>>> product delivery".
>>>
>>> So in the first quote, you seem to be asserting that safer
>>> languages are for the lazy who just don't want to put in the
>>> work, while in the second, you refer to "what works and what
>>> doesn't and what is fluff", but without acknowledging that new
>>> techniques and tools are introduced all the time.
>>
>> If you intentionally misrepresent in joining the dots,
>> expect to reach the wrong conclusions.
>>
>>>
>>> And finally you allude to your "hard won experience" while
>>> simultaneously discounting others who disagree with you.
>>
>> Remind me, where did I discount others ?.
>>
>>>
>>> Taken together, this seems to indicate an attitude of, "if it
>>> ain't broke, don't fix it" and aversion to incorporating change,
>>> which seems strange. Truly, is the way you develop software
>>> _now_ the same as how you developed software 25 years ago?
>>
>> In a lot of ways, yes and true of many companies i've done work
>> for in the past. Don't know where you have been, but most
>> companies prefer proven methods over fashion, because it reduces
>> risk and cost overruns. Sure, keep an eye on new ideas, but
>> stick to core to get the job done and meet targets. The tools change,
>> but the overall process remains largely the same.
>>
>>>
>>>>> 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.
>>
>> Now we have it: Perhaps you are pre conditioned by the idea
>> that vms is a dinosaur that has no place in "modern
>> computing" ?. Far from it, may have had a difficult time with
>> HP, but a robust os still in wide use and under active
>> development.
>>
>>>>
>>>> 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.
>>>
>>> Yes, but the critical point is that the "current technology"
>>> changes.
>>
>> Repeating the obvious gets tiresome after a while.
>>>
>>
>>>>>
>>>>> 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...
>>>
>>> You seem to be taking what I say rather personally. Perhaps
>>> don't?
>>
>> Well, "better" is subjective. If you have a system that
>> produces results, why does it need to be fixed ?. Use a wide
>> variety of tools for clients, various ide's scripting and more,
>> but still wedded to an ancient editor and makefile environment
>> for my own work.
>>
>> You seem to be suggesting that those who value proven but
>> not leading edge development methods are somehow deficient. If so,
>> expect a response.Rants about Head in sand attitudes don't
>> help either.
>>
>> If you want to be an evangelist for rust, good for you, but
>> sorry, just suspicious of salesman of any kind, however good
>> the product. Far from mainstream and proven so far, even
>> though it's been around for (what did you say ?) 10+ years,
>> suggests it's not a great hit anywhere.
>>
>>>
>>> On the other hand, you write the following about those of us who
>>> choose to use safer tools:
>>>
>>> "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."
>>>
>>
>> Some sections of society these days seem to think rewarding failure
>> a good idea, but not everyone would agree. Good programming is not
>> about language or tools, but an attitude of mind, like all professional
>> work. That's what I was trying to get across...
>>
>> Chris
>
> "Good programming is not about language or tools, but an attitude of mind"
>
> Remind me why you stopped doing all of your work in assembler again?
>

I would suggest that the need to do so has decreased.

I doubt that many, if any, choose assembler because they like it. At times it
is the best choice. That appears to have decreased.

--
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/8/2022 7:51 PM, chris wrote:
> On 04/08/22 13:30, Dan Cross wrote:
>> In article<t2nn0k$rns$1@gioia.aioe.org>,
>> chris<chris-nospam@tridac.net> wrote:
>>> Far too much of an academic attitude.
>>
>> Sounds like one of those "ad hominem on the sly" things you
>> were talking about.
>
> Not an insult. We need the academics to do the research, but it's
> the engineers who have to translate the theory into usable product,
> where possible.
>
>>
>>> 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.
>>
>> Static typing is not an "unproven tool".
>>
>> - Dan C.
>>
>
> Don't remember discussing static typing at all...
>
> Chris
>

That was maybe me. This conversation has been all over the place. I'm thinking
most that can be said has been said, and now we're just beating it to death.
Perhaps move on?

--
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/09/22 02:16, Don Baccus wrote:
> On Friday, April 8, 2022 at 6:03:09 PM UTC-7, chris wrote:

>
> "Good programming is not about language or tools, but an attitude of mind"
>
> Remind me why you stopped doing all of your work in assembler again?
>

That's a different issue. The point is that a good programmer can get
athe job done using less than optimum tools, even using assembler.
Someone at DEC wrote piece about what it means to be a professional
engineer years ago. Don't have a reference, but it's worth looking at
from time to time...

Chris

On 04/08/22 01:07, Arne Vajhøj wrote:
> 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
>

Nit picking semantics there. The project manager / team leader
is usually at least as technically aware and switched on as
the rest of the team. Also, "tech stack" may be initiated by
one of two people, but that is usually discussed and often
changed once it reaches peer group review. Shared responsibility
and many eyes helps build better product...

Chris

On 04/08/22 01:27, Arne Vajhøj wrote:
> 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
>

Yes. Any fool can write a two or three page utility and make it
work, but analysing and building even medium sized sysems requires a
different approach. The actual coding is just a small part of that...

Chris

On 04/08/22 01:36, 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.

Good design range checks all input against the limits
that the code can handle. Anything else is sloppy, but is
seen everywhere these days. No excuse for design errors
like that, as it's so easy to avoid.

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

For work here, tend to write a test harness for every
module as part of the build process, with data designed
to stress test the code well outside expected limits,
as well as with valid data.

Of course, that doesn't prove that the overall system
design is correct and that is often where the real
testing problems arise...

Chris

>

On 04/08/22 14:20, Arne Vajhøj wrote:
> On 4/8/2022 8:57 AM, Dan Cross wrote:
>> In article <624f89b3$0$694$14726298@news.sunsite.dk>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> 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.
>>
>> That doesn't actually answer my question. :-)
>>
>> Most of his publicly available experience seems like it was more
>> in the development management space, less actually writing code.
>
> There are not much detail available.
>
> But I find it hard to believe that he walked directly from
> his graduation to a managerial role in the 1970's telco world.
>
> Arne

If anything, telco took the most disciplined approach to software
engineering, with ideas like state driven design coming from their
long experience in hardware design..

State driven programming is a very elegant sdesign technique, as it's
easy to make anything other than valid data an error...

Chris

On 04/09/22 05:33, Dave Froble wrote:
> On 4/8/2022 7:51 PM, chris wrote:
>> On 04/08/22 13:30, Dan Cross wrote:
>>> In article<t2nn0k$rns$1@gioia.aioe.org>,
>>> chris<chris-nospam@tridac.net> wrote:
>>>> Far too much of an academic attitude.
>>>
>>> Sounds like one of those "ad hominem on the sly" things you
>>> were talking about.
>>
>> Not an insult. We need the academics to do the research, but it's
>> the engineers who have to translate the theory into usable product,
>> where possible.
>>
>>>
>>>> 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.
>>>
>>> Static typing is not an "unproven tool".
>>>
>>> - Dan C.
>>>
>>
>> Don't remember discussing static typing at all...
>>
>> Chris
>>
>
> That was maybe me. This conversation has been all over the place. I'm
> thinking most that can be said has been said, and now we're just beating
> it to death. Perhaps move on?
>

In comp.os.vms, things can take a life of their own, so perhaps you are
right. I think we all would like to see higher standards in software
engineering. Some seem to want to constrain freedom to get there. Others
think it's more about personal responsibility and doing it right for
it's own sake. Same in mainstream politics I guess...

Chris.

On 2022-04-08 22:21, Arne Vajhøj wrote:
> On 4/8/2022 4:12 PM, Bill Gunshannon wrote:
>> On 4/8/22 13:23, Arne Vajhøj wrote:
>>> On 4/8/2022 1:13 PM, Bill Gunshannon wrote:
>>>> As I stated elsewhere, the change to ANSI C from K&R broke
>>>> everything.  You can not compile K&R with an ANSI C Compiler
>>>> and vice versa.  What better time to fix it all?
>>>
>>> Not everything.
>>
>> If you can't compile K&R with an ANSI C compiler and you can't
>> compile ANSI C with a K&R compiler what exactly didn't get broken?
>
> I believe the breaking change was the function prototyping.

Hum. I don't know what the two of you are going on about. :-)

As far as I know, you can still compile a program that don't have
function prototypes in current C, and you can definitely do it in C89.

So K&R style code is still compilable. Obviously, "modern" C won't pass
the K&R compiler, but that's more expected.

But there might be something in old K&R code that is not acceptable in
newer compilers. I can't think of anything now, but that might just be me.

But array bounds checking is never going to be possible in C, since
arrays are mostly syntactic sugar to start with.

Johnny

On 4/9/22 00:31, Dave Froble wrote:
>
>
> I doubt that many, if any, choose assembler because they like it.  At
> times it is the best choice.  That appears to have decreased.
>

I always like assembler. Have done some recently and expect to more
in the near future. I know the assembler for at least 10 processors.
But then, I am a dinosaur.

bill

On Saturday, April 9, 2022 at 5:11:23 AM UTC-7, Bill Gunshannon wrote:
> On 4/9/22 00:31, Dave Froble wrote:
> >
> >
> > I doubt that many, if any, choose assembler because they like it. At
> > times it is the best choice. That appears to have decreased.
> >
> I always like assembler. Have done some recently and expect to more
> in the near future. I know the assembler for at least 10 processors.
> But then, I am a dinosaur.
>
> bill

My point is that since Chris seems to reject language design decisions that restrict his "freedom" to screw up, why isn't he still writing assembly code?

On Saturday, April 9, 2022 at 1:52:43 AM UTC-7, chris wrote:
> On 04/09/22 05:33, Dave Froble wrote:
> > On 4/8/2022 7:51 PM, chris wrote:
> >> On 04/08/22 13:30, Dan Cross wrote:
> >>> In article<t2nn0k$rns$1...@gioia.aioe.org>,
> >>> chris<chris-...@tridac.net> wrote:
> >>>> Far too much of an academic attitude.
> >>>
> >>> Sounds like one of those "ad hominem on the sly" things you
> >>> were talking about.
> >>
> >> Not an insult. We need the academics to do the research, but it's
> >> the engineers who have to translate the theory into usable product,
> >> where possible.
> >>
> >>>
> >>>> 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.
> >>>
> >>> Static typing is not an "unproven tool".
> >>>
> >>> - Dan C.
> >>>
> >>
> >> Don't remember discussing static typing at all...
> >>
> >> Chris
> >>
> >
> > That was maybe me. This conversation has been all over the place. I'm
> > thinking most that can be said has been said, and now we're just beating
> > it to death. Perhaps move on?
> >
> In comp.os.vms, things can take a life of their own, so perhaps you are
> right. I think we all would like to see higher standards in software
> engineering. Some seem to want to constrain freedom to get there. Others
> think it's more about personal responsibility and doing it right for
> it's own sake. Same in mainstream politics I guess...
>
> Chris.

"Some seem to want to constrain freedom to get there."

This and your other politically-driven comments are the stupidest things I've ever seen a self-described software engineer make.

You know what language designers who work towards making safer languages want?

To lower engineering costs. And, yes, this means often limiting degrees of freedom but not in the political sense. The "freedom" to write:

int foo[10];
int *bar=foo;
....
bar[11];

is simply the "freedom" to break your program.

On 04/09/22 13:22, Don Baccus wrote:
> On Saturday, April 9, 2022 at 5:11:23 AM UTC-7, Bill Gunshannon wrote:
>> On 4/9/22 00:31, Dave Froble wrote:
>>>
>>>
>>> I doubt that many, if any, choose assembler because they like it. At
>>> times it is the best choice. That appears to have decreased.
>>>
>> I always like assembler. Have done some recently and expect to more
>> in the near future. I know the assembler for at least 10 processors.
>> But then, I am a dinosaur.
>>
>> bill
>
> My point is that since Chris seems to reject language design decisions that restrict his "freedom" to screw up, why isn't he still writing assembly code?

Perhaps I can answer that myself.

It's essential to have complete transparency and audit trail
from source code right down to the bare metal where necessary.
Any language using dynamic memory allocation makes that far more
difficult to show fully deterministic behaviour. That is the
reason I don't do much work in C++, for example, though some of
ideas in C++ are quite elegant and quite usable in C. Fully
deterministic behaviour is often mandatory for real time systems
and can make any code more robust.

Still happy programming in assembler where necessary, but can be hard
work building even moderately sized systems using it. Also, it makes
maintenance difficult, since few now are really fluent in even
a single machine assembler. Since maintenance can account for
the majority of ongoing development costs, try to write systems to
be maintainable, even though it means added work. Finally, it's
far easier to express abstract concepts in a higher level language
and C is just high level enough to do that, without added features
that I don't need. As I said, the swiss army knife of programming...

Chris

On 04/09/22 13:29, Don Baccus wrote:
> On Saturday, April 9, 2022 at 1:52:43 AM UTC-7, chris wrote:
>> On 04/09/22 05:33, Dave Froble wrote:
>>> On 4/8/2022 7:51 PM, chris wrote:
>>>> On 04/08/22 13:30, Dan Cross wrote:
>>>>> In article<t2nn0k$rns$1...@gioia.aioe.org>,
>>>>> chris<chris-...@tridac.net> wrote:
>>>>>> Far too much of an academic attitude.
>>>>>
>>>>> Sounds like one of those "ad hominem on the sly" things you
>>>>> were talking about.
>>>>
>>>> Not an insult. We need the academics to do the research, but it's
>>>> the engineers who have to translate the theory into usable product,
>>>> where possible.
>>>>
>>>>>
>>>>>> 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.
>>>>>
>>>>> Static typing is not an "unproven tool".
>>>>>
>>>>> - Dan C.
>>>>>
>>>>
>>>> Don't remember discussing static typing at all...
>>>>
>>>> Chris
>>>>
>>>
>>> That was maybe me. This conversation has been all over the place. I'm
>>> thinking most that can be said has been said, and now we're just beating
>>> it to death. Perhaps move on?
>>>
>> In comp.os.vms, things can take a life of their own, so perhaps you are
>> right. I think we all would like to see higher standards in software
>> engineering. Some seem to want to constrain freedom to get there. Others
>> think it's more about personal responsibility and doing it right for
>> it's own sake. Same in mainstream politics I guess...
>>
>> Chris.
>
> "Some seem to want to constrain freedom to get there."
>
> This and your other politically-driven comments are the stupidest
things I've ever seen a self-described software engineer make.
>
> You know what language designers who work towards making safer languages want?
>
> To lower engineering costs.

and I suppose we should all be grateful ?.

And, yes, this means often limiting degrees

of freedom but not in the political sense. The "freedom" to write:

Well ymmv, but everything in life where humanity interacts
is political. We have always had evangelists, this and that,
those who think they know what's best for us all and want to
bestow their version of perfection onto humanity, but they are
so often intolerant under the skin and push come to
shove, are quite happy to impose it onto others by any means
possible. That's not democracy as I see it.

Taking a more generous view, perhaps some are idealists
with good ideas, but natural selection rules, in that if
an idea is that good, it sells itself and will be taken
up, given enough time...

>
> int foo[10];
> int *bar=foo;
> ...
> bar[11];
>
> is simply the "freedom" to break your program.
>

If you are stupid enough to write that sort of code and ignore
good practice, you deserve what you get :-)...

Chris

On 04/08/22 13:02, Dan Cross wrote:
> 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.
>

I think it must be the practical engineer in me, where the goal
is to design the most elegant and often least complex solution to a
given problem It's about efficiency and transparency and also
wary because the early C compilers were often not very good at
all. Still quite wary of anything where the
internal workings are not fully transparent. Modern compilers are
very good in general, but still like to look at the entrails
to see what sort of code is being generated. Trust, but verify
etc.

Maybe rust will be significant, time and the global community
will decide, but there will always be a place for less safe
languages, just as we still need assembler from time to time...

Chris

In article <t2pn8f$r5q$1@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
>On 2022-04-08 14:45, Dan Cross wrote:
>> In article <624f803d$0$698$14726298@news.sunsite.dk>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> 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.
>>
>> Does it, though? How well-defined are the semantics around, say
>> `volatile`?
>
>volatile is simple enough. Every reference have to stay, and be kept in
>the same order, and order also kept in relation to other volatile
>variables, and the value cannot be "cached" or placed in a register, or
>whatever. Memory barriers all around.

The last time this came up where I was involved, the murky stuff
revolved around precise semantics of generated loads and stores.
What you wrote above is true, but suppose I'm doing multiple
stores into aligned buffers; can the compiler lower into stores
into a larger datum, or must they be kept distinct? That is,
suppose I'm writing a bunch of uint16_t's from an aligned source
into an aligned destination; can the compiler turn that into
corresponding loads/stores of uint32_t? Can it write to the
same byte twice? And how do I work with volatile byte buffers
without memcpy?

>There are other parts that are much more devious in C these days.

Can't argue with that. :-)

- Dan C.