5 ms·

Right and wrong: ten choices in language design

40 points by muth02446 4y ago

jcheng 4y ago
Author is Bertrand Meyer https://en.wikipedia.org/wiki/Bertrand_Meyer https://en.wikipedia.org/wiki/Bertrand_Meyer
- yurodivuie 4y ago
  And he created the Eiffel language, so...
Verdex 4y ago
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.
- bigfoot675 4y ago
  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
  - twblalock 4y ago
    It definitely explains why the author's preferred language is not common in industry, though.
  - msla 4y ago
    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.
- kjeetgill 4y ago
  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.
Perenti 4y ago
I don't believe this is a fair comparison of choices in language design, as it almost ignores Smalltalk and relatives. Almost all the "issues" of language design listed don't exist in Smalltalk (and others), and when he discusses Class methods he says it works but __seems__ heavy handed. That is not analysis, it's opinion.

40 points by muth02446 4y ago

jcheng 4y ago

Author is Bertrand Meyer https://en.wikipedia.org/wiki/Bertrand_Meyer https://en.wikipedia.org/wiki/Bertrand_Meyer

yurodivuie 4y ago
And he created the Eiffel language, so...

Verdex 4y ago

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.

bigfoot675 4y ago
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
- twblalock 4y ago
  It definitely explains why the author's preferred language is not common in industry, though.
- msla 4y ago
  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.
kjeetgill 4y ago
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.

Perenti 4y ago

I don't believe this is a fair comparison of choices in language design, as it almost ignores Smalltalk and relatives. Almost all the "issues" of language design listed don't exist in Smalltalk (and others), and when he discusses Class methods he says it works but __seems__ heavy handed. That is not analysis, it's opinion.