[HN Gopher] Right and wrong: ten choices in language design
       ___________________________________________________________________
        
       Right and wrong: ten choices in language design
        
       Author : muth02446
       Score  : 31 points
       Date   : 2022-12-05 13:15 UTC (9 hours ago)
        
 (HTM) web link (arxiv.org)
 (TXT) w3m dump (arxiv.org)
        
       | jcheng wrote:
       | Author is Bertrand Meyer
       | https://en.wikipedia.org/wiki/Bertrand_Meyer
        
       | Verdex wrote:
       | This is a paper that talks about why OO as generally implemented
       | in mainstream languages is bad, and how Eiffel does it correctly.
       | 
       | In general I'm uncertain about these types of explorations
       | because inevitably they define some calculus such that their
       | favorite language just happens to be the best.
       | 
       | Regardless it's approximately 60 pages so if anyone else is
       | interested in reading through the whole thing and finds it useful
       | then please let the rest of us know.
        
         | kjeetgill wrote:
         | From the Abstract:
         | 
         | > and explanation of the thinking behind Eiffel's corresponding
         | mechanisms.
         | 
         | Eiffel is the author's language so naturally it's going to
         | conform to his ideas for what's correct or not. This is a
         | defense of his language design choices, not about "deriving"
         | the perfect language from some first principles or "calculus"
         | and accidentally discovering it's Eiffel.
        
         | bigfoot675 wrote:
         | Yeah this paper takes a heavily biased stance, even to the
         | point of vilifying generally accepted and genuinely useful
         | concepts like `return` statements. Not sure how the author can
         | pretend that they are presenting any sort of analysis on the
         | broad set of languages when they've already presupposed that
         | everything besides their own language is wrong
        
           | msla wrote:
           | Abstract: This text may as well be titled "Why Eiffel Is Not
           | My Favorite Programming Language" but the author is incapable
           | of seeing it.
           | 
           | Wow:
           | 
           | > Today, having some programming experience is no longer a
           | rare skill. Increasingly, pre-university curricula include
           | some programming. Many people have even encountered an OO
           | language; they include most students starting a university
           | computer science program. Language exposure is not by itself
           | the problem; the trouble is that together with the language
           | they were taught bogus principles, such as "multiple
           | inheritance is bad" (often just "inheritance is bad"), or
           | "you should make fields private and write getter functions to
           | provide access to them", or "you can return from anywhere in
           | a function", or "writing interfaces helps OO design" or "you
           | should use defensive programming" and other atrocities
           | apparently entered into young minds at the same time and with
           | the same authority as the information that the earth revolves
           | around the sun.
           | 
           | Being morally opposed to return statements is one of those
           | stances which makes me wonder whether the author has ever
           | written nontrivial code. It's beyond mere pedantry and on
           | into the realm of nonsensical pronouncements from on high. Of
           | course, the author expands their delusion:
           | 
           | > Before continuing with object-oriented abstraction
           | mechanisms we briefly stop with a plague that should have
           | been eradicated by our grandparents but still affects us. It
           | is a common myth that "Python (like almost every programming
           | language today) supports structured programming which
           | controls flow using if/then/else, loop and subroutines" (from
           | a comment in a Stack Overflow discussion at bit.ly/3ErsDPZ).
           | "Myth" is a polite way to say "lie": all major imperative
           | programming languages today other than Eiffel have an
           | essentially full-fledged goto, and programmers use it
           | generously. It is not expressed as a "goto" but takes the
           | form of:
           | 
           | > * Instructions to break out of a loop: break and continue.
           | 
           | > * Worse yet, the "return" instruction in routines.
           | 
           | Of course, that's in a section titled "Dijkstra Was Right"
           | proving that this author (to use the least offensive term
           | which still technically applies) doesn't understand
           | Dijkstra's whole thesis.
           | 
           | Just below that, we see (mirabile dictu!) what the author
           | actually thinks _should_ be done:
           | 
           | > Eiffel applies a strict OEOE policy; there is no goto of
           | any kind or disguise. The matter of defining return values of
           | functions is handled in a simple fashion: functions may use
           | the predefined local variable Result, initialized to the
           | default value of the function's return type (0 for integers,
           | false for booleans and so on). Whatever value Result has on
           | the (single) point of routine exit is the value returned by
           | the function. This convention avoids the need to check that a
           | function's result is always defined (as required with goto-
           | style "return" instructions).
           | 
           | [OEOE is one-entry-one-exit]
           | 
           | This proves that the author hasn't ever written nontrivial
           | code in any non-Eiffel language, and further doesn't
           | understand the point of checking return values. Giving every
           | function a default return value, which is blithely passed up
           | the call stack unless the programmer remembers to set a magic
           | variable to something else, is a footgun waiting to go off.
           | On the other hand, modern, sane languages ensure return
           | values are always defined by checking that return statements
           | always include a value form in every function which returns a
           | value, forcing the programmer to think about what to return,
           | instead of simply going with a default which may be wrong or,
           | worse, right completely by accident.
           | 
           | The author goes on to both endorse the kind of flag-heavy
           | code which invariably results from a Foogol not having a way
           | to break out of loops, and blithely assert that one can
           | always modularize code to make it clearer. Again, this person
           | has their head so far up Eiffel they can't even imagine
           | wanting what Eiffel doesn't give them.
        
             | wizofaus wrote:
             | A Foogol?
        
               | msla wrote:
               | > A Foogol?
               | 
               | A programming language with a syntax and semantics
               | (mostly) derived from Algol, such as Eiffel, C++/Java, or
               | Python.
        
               | wizofaus wrote:
               | Never heard that, nor did Google return anything obvious,
               | so there you go!
        
             | ad404b8a372f2b9 wrote:
             | This is hyperbolic. The author isn't some kind of bumbling
             | fool who can't program, as you seem to be suggesting, he's
             | an accomplished computer scientist. And foregoing the
             | return instruction doesn't prevent you from writing
             | "nontrivial" code, you only have to look at the entire
             | Elixir ecosystem if you need a proof.
        
           | twblalock wrote:
           | It definitely explains why the author's preferred language is
           | not common in industry, though.
        
       ___________________________________________________________________
       (page generated 2022-12-05 23:02 UTC)