Right and wrong: ten choices in language design(arxiv.org)
arxiv.org
Right and wrong: ten choices in language design
https://arxiv.org/abs/2211.16597
15 comments
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
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.
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.
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.
> 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.
He doesn't seem to have had a job in industry though? Which seems a bit suspicious to me. On the other hand implementing Eiffel should be somewhat like having to write real code I imagine.
He doesn't seem to have had a job in industry though? Which seems a bit suspicious to me. On the other hand implementing Eiffel should be somewhat like having to write real code I imagine.
For other readers:
Elixir has a special syntax for what is early return, namely guard statements.
Elixir has a special syntax for what is early return, namely guard statements.
Misunderstanding Dijkstra is, of course, easy if you first encountered that infamous piece after the 80s or so, where the lessons of structured programming have been thoroughly learned, every major non-assembly language has its gotos crippled to be barely capable of writing the sort of spaghetti Dijkstra railed agaisnt, and the average programmer does not work in an environment where that kind of spaghetti—mainly a product of it being easier to append and overwrite than to insert—was easy to write.
Seeing this drivel come from Bertrand Meyer is bizarre and frankly lowers my estimation of everything he's ever touched.
Seeing this drivel come from Bertrand Meyer is bizarre and frankly lowers my estimation of everything he's ever touched.
It definitely explains why the author's preferred language is not common in industry, though.
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.
> 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.
Author is Bertrand Meyer https://en.wikipedia.org/wiki/Bertrand_Meyer
And he created the Eiffel language, so...
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.
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.