[Info-vax] Rust as a HS language, was: Re: Quiet?

[chris]

On 04/07/22 19:59, Dan Cross wrote:
> In article<t2n1o9$1fjb$1 at gioia.aioe.org>,
> chris<chris-nospam at tridac.net>  wrote:
>> On 04/07/22 15:59, Dan Cross wrote:
>>> In article<t2l9jp$b8i$1 at gioia.aioe.org>,
>>> chris<chris-nospam at 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