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

[Dan Cross]

In article <t2nmc0$kp7$1 at gioia.aioe.org>,
chris  <chris-nospam at tridac.net> wrote:
>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 ?.

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.

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

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?

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

Yes, but the critical point is that the "current technology"
changes.

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

Of course those techniques still have value, but no one ever
disputed that.  But I disagree that things haven't changed, or
perhaps more precisely to the extent that they haven't that's a
bit of a problem.

See, for example, this:

http://cliffle.com/blog/on-hubris-and-humility/

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

You seem to be taking what I say rather personally.  Perhaps
don't?

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

Which is kind of hard to square with what you write above.

	- Dan C.