Right and wrong: ten choices in language design

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.