From: david.brown@hesbynett.no   
      
   On 27/10/2025 23:33, Waldek Hebisch wrote:   
   > David Brown  wrote:   
   >> On 26/10/2025 16:12, bart wrote:   
   >>> On 25/10/2025 16:18, David Brown wrote:   
   >>>> On 25/10/2025 14:51, bart wrote:   
   >>>>   
   >>>>> This is another matter. The CDECL docs talk about C and C++ type   
   >>>>> declarations being 'gibberish'.   
   >>>>>   
   >>>>> What do you feel about that, and the *need* for such a substantial   
   >>>>> tool to help understand or write such declarations?   
   >>>>>   
   >>>>> I would rather have put some effort into fixing the syntax so that   
   >>>>> such tools are not necessary!   
   >>>   
   >>>> And I'd love to hear your plan for "fixing" the syntax of C - noting   
   >>>> that changing the syntax of C means getting the C standards committee   
   >>>> to accept your suggestions, getting at least all major C compilers to   
   >>>> support them, and getting the millions of C programmers to use them.   
   >>>   
   >>> I have posted such proposals in the past (probably before 2010).   
   >>>   
   >>   
   >> No, you have not.   
   >>   
   >> What you have proposed is a different way to write types in   
   >> declarations, in a different language.  That's fine if you are making a   
   >> different language.  (For the record, I like some of your suggestions,   
   >> and dislike others - my own choice for an "ideal" syntax would be   
   >> different from both your syntax and C's.)   
   >>   
   >> I asked you if you had a plan for /fixing/ the syntax of /C/.  You don't.   
   >>   
   >> As an analogy, suppose I invited you - as an architect and builder - to   
   >> see my house, and you said you didn't like the layout of the rooms, the   
   >> kitchen was too small, and you thought the cellar was pointless   
   >> complexity.  I ask you if you can give me a plan to fix it, and you   
   >> respond by telling me your own house is nicer.   
   >   
   > Sorry, "proof by analogy" is usually wrong.   
      
   I agree - I wasn't trying to "prove" anything.  Analogies can be   
   illustrative.  Bart had claimed to have a "plan to fix C", without   
   understanding what that could mean, and I was trying to find a way to   
   show him how absurd that was.  (That is, his claim to have a plan to fix   
   C was absurd, not necessarily his alternative syntaxes for declarations.)   
      
   > If you insist on   
   > analogies the right one would be function prototypes: old style   
   > function declarations where inherently unsafe and it was fixed   
   > by adding new syntax for function declarations and definitions,   
   > in parallel to old syntax.  Now old style declarations are   
   > officially retired.  Bart proposed new syntax for all   
   > declarations to be used in parallel with old ones, that is   
   > exaclty the same fix as used to solve unsafety of old   
   > function declarations.   
   >   
      
   The function prototype syntax was an enhancement to the existing syntax,   
   and could be used happily in parallel with it.  And it was developed   
   within the community of the C language developers and implementers (it   
   was before ANSI/ISO standardisation).  Bart's suggestion turns existing   
   C syntax upside down, is incompatible with everything - in particular,   
   incompatible with the philosophy and intention behind C's syntax - and   
   is the product of one person whose motivation seems to be hating C and   
   whining about it.  So it is a very different situation.   
      
   > IMO the worst C problem is standard process.  Basically, once   
   > a large vendor manages to subvert the language it gets   
   > legitimized and part of the standard.  OTOH old warts are   
   > preserved for long time.  Worse, new warts are introduced.   
   >   
      
   Backwards compatibility is simultaneously the best part of C, and the   
   worst part of C.   
      
   > As an example, VMT-s were big opportunity to make array access   
   > safer.  But version which is in the standard skilfully   
   > sabotages potential compiler attempts to increase safety.   
   >   
   > If you look carefuly, there is several places in the standard   
   > that effectively forbid static or dynamic error checks.  Once   
   > you add extra safety checks your implementation is   
   > noncompilant.   
   >   
      
   I certainly have no problem finding countless things in C that I would   
   have preferred to be done differently.  I don't know any serious C   
   programmer who could not do the same - but they would all come up with   
   different points (with plenty of overlap).   
      
   > It is likely that any standarized language is eventually   
   > doomed to failure.  This is pretty visible with Cobol,   
   > but C seem to be on similar trajectory (but in much earlier   
   > stage).   
   >   
      
   It takes a /very/ broad definition of "failure" to encompass C!   
      
   But I think Stroustrup was spot-on with his comment "There are two kinds   
   of programming languages - the ones everyone complains about, and the   
   ones nobody uses".   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)