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

[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