Right and wrong: ten choices in language design

https://arxiv.org/abs/2211.16597

by muth02446 • 4 years ago

40 15 4 years ago

arxiv.org

jcheng• 4 years ago

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

yurodivuie• 4 years ago

And he created the Eiffel language, so...

Verdex• 4 years 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• 4 years 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• 4 years ago

It definitely explains why the author's preferred language is not common in industry, though.

msla2• 4 years 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• 4 years 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• 4 years 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.

Right and wrong: ten choices in language design

Related Stories