INTL 3:770/1 3:770/3   
   REPLYADDR bnl@nowhere.com   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  f6ae9425   
   REPLY:  ac2d3573   
   PID: SoupGate-Win32 v1.05   
   On 2023-12-28 13:07, The Natural Philosopher wrote:   
   > Yes, but in fact a whole swathe of NEW errors become possible, instead :-)   
      
   Interinsting - what new error do you have in mind?   
      
      
   > I am very dubious about languages that claim to solve coding problems.   
      
   If you refer to Ada/Spark, then they do not claim they solve cding problems.   
   What they do is they provide tools to write a program with   
   higher probability to be correct, according to spec.   
      
   If you have no spec, then of course nothing or everything is correct.   
      
   It is not about the fool-proof language. It is about   
   to *make it easy to do it right*   
      
   It should be easy to do it right. It should be hard to do it wrong.   
      
   These tools/languagees helps extremly much to make it right.   
   Once the code passes the compiler - the hard part - then it usually   
   works as intended. Of ourse not always, but mots of the times.   
   I've never had that feeling with other languaes. Ever.   
   They compile, and bail out on SIGSEGV of SIGABORT or even worse,   
   they rather thrashes that crashes.   
      
   > I am sure they will find ways   
   > to fuck anything up.   
      
   of course. But it should be hard to fuck up.   
      
   > The problem with Microsoft   
      
   Where did MS come into the picture?   
      
      
   > Compared with - say - the avionics industry there is zero quality   
   > control, in the ISO 9000 meaning of the word.   
      
   Ok, It thought DO178-B was that   
      
   Most military or avionics guys talks about that   
      
      
   >   
   > It's perfectly *possible* to write bug free programs in C.   
      
   Yes - but hard. Had you written it in Spark, your journey would have   
   been shorter - If you's be proficient in spark.   
      
      
   > As the help I   
   > got here with my daemons memory leak demonstrated.  Provided you test   
   > the code and analyse the problems that result.   
      
   >   
   > Writing in some 'foolproof' language  is no substitute for a proper   
   > testing and modification feedback loop to consistently test and improve   
   > the product, and the danger is that people will think that it is.   
   >   
      
   Of course. no-one said that these languages are a substitute for   
   testing. But testing WLL be shorter, because most bugs will be caught at   
   compile time.   
      
   And the 'many-eyes' mantra is no good either - as Heart Bleed   
   demonstrated. The faulty code was there for years without being detected.   
      
      
   --   
   /Björn   
      
   --- SoupGate-Win32 v1.05   
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)   
   SEEN-BY: 15/0 90/1 105/81 106/201 128/260 129/305 135/225 153/757   
   SEEN-BY: 153/7715 218/700 840 220/70 221/1 6 242 360 226/17 30 100   
   SEEN-BY: 227/114 229/110 112 113 200 206 307 317 400 426 428 452 470   
   SEEN-BY: 229/550 616 664 700 230/0 266/512 267/800 280/5003 282/1038   
   SEEN-BY: 291/111 292/854 8125 301/1 310/31 320/219 322/757 335/364   
   SEEN-BY: 341/66 342/200 396/45 410/9 423/81 460/58 633/280 712/848   
   SEEN-BY: 770/1 3 100 330 340 772/210 220 230 5020/400 5058/104 5075/35   
   PATH: 770/3 1 218/840 221/6 1 292/854 229/426