From: cross@spitfire.i.gajendra.net   
      
   In article <10686pv$24rjd$5@dont-email.me>,   
   Julio Di Egidio   wrote:   
   >On 28/07/2025 17:16, Dan Cross wrote:   
   >> In article <1067o6p$24rjd$2@dont-email.me>,   
   >> Julio Di Egidio   wrote:   
   >>> On 28/07/2025 13:37, Dan Cross wrote:   
   >   
   >>> IOW, the idea that programmers in general need to be baby-seated   
   >>   
   >> I wouldn't phrase it as "babysitting".  Rather, it's   
   >> professionals making conscious choices about their tools to most   
   >> effectively do their jobs.   
   >>   
   >>> instead of given control I find not just self-defeating but really   
   >>> fallacious.   
   >>   
   >> In what way do you feel you have less control (and over what?)   
   >> in Rust than in, say, C?   
   >   
   >To be clear, I have nothing against the institution of a   
   >comp.lang.rust (on the contrary, I'd be tempted to say), nor   
   >against the Rust language itself:   
      
   Sure, that's fair.  This is separate.   
      
   >I am rather commenting on   
   >some questions of principle, and maybe some marketing slogans,   
   >especially on the themes of "safety" on a side and "assisted"   
   >programming on the other.   
      
   I'm not terribly interested in marketing slogans, to be honest.   
      
   "Safety" in this case has a very well-defined meaning, which may   
   not be the same as yours.  As for "assisted", I'm not sure what   
   that's about.  Perhaps you mean the way that the language   
   assists a programmer in writing more robust software?  How is   
   that any different than C assisting a programmer to write more   
   robust software than straight assembly?  Or assembly assisting   
   to write more robust software than programming directly in   
   machine code?   
      
   >Indeed, I am not against a stratification of languages from lower   
   >to higher level either, actually that's quite needed, I am just   
   >of the idea that programmers should not be "protected" by anybody   
   >but more competent programmers: but of course with that goes a   
   >quite different idea of what *software development* means, and   
   >to me it does not primarily mean we buy "solutions" at the shop,   
   >the very opposite of that.   
      
   The competence argument is ancient: as I alluded to above, when   
   assemblers began to replace direct machine-language coding   
   (often in octal!), being both less error prone and more   
   expressive, they were decried as hopelessly inefficient (read:   
   wasteful of very expensive computer time!) and their users   
   simply lacking in some abstract definition of skill.  When   
   high-level languages began to emerge 70-ish years ago, and   
   people noted that defect rates went down when programming them   
   relative to assembler, many macro assembly language programmers   
   made similar arguments, perhaps having forgotten that they   
   themselves had been the object of that same criticism only a few   
   short years before.   
      
   Bluntly, the argument has never really held up in the face of   
   actual evidence.  The best C programmers in the world have   
   written code with memory safety bugs: I've personally seen such   
   bugs in programs written by the man who designed the language   
   and implemented its first compilers.  I've seen similar things   
   from folks on the language standards committee.  In other cases,   
   programs have _appeared_ to work flawlessly for decades until a   
   new point release of a compiler came out, and it turned out the   
   program actually exhibited some kind of undefined behavior that   
   the new compiler used to justify changing some crucial behavior   
   in an unexpected way and the program "broke."   
      
   If the best programmers in the world make these mistakes, then   
   it's not a competence or skill issue.   
      
   >Instead we get an inversion of the chain of control and of   
   >responsibility that is rather one of the key ingredients, the   
   >other being the denial of the very state of the art, of the   
   >disaster that the whole industry has been made into across   
   >the last ~30 years...   
   >   
   >...and the self-fulfilling prophecies, since average is the data,   
   >averaging are and have been the policies, average are the results,   
   >and the circle is closed: with the triumph of the levelling down   
   >to ineptitude and consumeristic dependence.   
      
   I started programming professionally about 30 years ago, and at   
   the time, people were making the exact same arguments, about how   
   the industry had been ruined over the previous 30 years, that we   
   were spoiled by bitmapped graphics (what was wrong with a 80x24   
   VT-series terminal?  Or even a teletype?), cheap RAM, cheaper   
   disk, and ever-increasing CPU speeds, and how much we had lost   
   by moving away from systems written by truly competent   
   programmers in assembler, to high(er)-level languages that let   
   you get away with not really understanding the machine, being   
   inefficient, and that inevitably led to "toys" like Unix because   
   people no longer had the discipline required to have any sort of   
   idea what they were _actually_ doing.   
      
   This was always a non-sequitor.  The industry may be a disaster   
   (I agree with that), but that doesn't mean that choosing to use   
   a tool has better memory safety properties is a cause or symptom   
   of that.   
      
   Interestingly, with Rust, the language famously has a very steep   
   learning curve (a former colleague once called it, "near   
   vertical"), and is not known as a language for amateurs, so   
   would seem to be a counter example against the kind of   
   mediocrity you described.   
      
   Similarly, one could make a strong case that arguing against   
   memory safe langauges is a denial of the state of the art,   
   which has largely moved on from e.g. C, C++, Java, COBOL, PL/I,   
   RPG-2, Macro assemblers, and so on.  Even Fortran is no longer   
   really the state of the art for numerical programming.   
      
   >Here is rather an analogy: go tell a race car driver that it is   
   >"unsafe" for them to touch their breaks in a turn, and that you   
   >actually have a "solution" in mind that will automatically disable   
   >the breaks in a turn (and punish the driver for it)... or something   
   >along that line.   
      
   That's a bad analogy.  A better one is the race car driver   
   telling you that they don't need a 5-point restraint harness or   
   flash-resistent outer suit because they already know how to   
   drive and won't get into a wreck, and that those things are only   
   for less competent drivers.  And yet, just like we've seen the   
   best programmers in the world introduce bugs in e.g. C code, we   
   have seen the best racers in the world get into horrific   
   crashes.   
      
   The guy who tells you he doesn't need that stuff is going to end   
   up dead in a crash that another, I would argue more competent,   
   driver can walk away from precisely because competence means   
   that the latter understands the value of and uses that kind of   
   safety equipment correctly, without cutting corners.   
      
   >Here is not an analogy: only a competent programmer knows the   
   >discipline, the principles, the practices, and in fact how to   
   >organise not only a production unit that delivers excellent   
   >products, but also that continually grows in the level of   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)