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

[Dave Froble]

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 at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486