While perhaps less directly impactful on the industry, in computer science teaching and academia, there are few names who loom as large as his.
He has touched so many aspects of computer science that we now consider fundamental.
Dijkstra advocated "single entry, single exit" for each control block. Programs should be composed of such blocks. Makes for very neat flowcharts. Good for entry and exit conditions.
Single entry wasn't that controversial. Single exit, though, means no "break", or "continue" for loops, and no early returns from functions. This forces a rather convoluted style. Try writing a loop of the form "get thing, if done quit, process thing, put thing" in that style. You have to have two calls to "get thing", or extra flags.
Turns out you don't need that for program proofs, once you have machine assistance to make sure all the cases were covered. It makes for cleaner hand proofs, though.
(I never met Dijkstra. Knew people who worked with him.)
Sounds like pretty standard functional programming a la Standard ML or Haskell, or am I missing something?
It may be standard for them, but it's why functional languages are niche while C, C++, C#, Java, JavaScript and Python dominate.
To be clear, I agree that it could be a reason, along with a multitude of others. I think that discerning which is the most substantial reason (if any such exist) is hard if not impossible.
I think the pattern that emerges is that the popular languages I listed are multi-discipline, they can be adapted to whichever paradigm you prefer, even if it's a little cumbersome, and over time they adopt the key features of other languages, while retaining their existing benefits. In other words... you can get the best features of Haskell in Python, but you can't get the best features of Python in Haskell?
Haskell's best features relative to more mainstream languages are HM-style type inference, higher-kinded types, and typeclasses - none of which are possible in a language without real static types.
I believe all kinds of Python frameworks too like to incorporate FP into their APIs, and of course, there are list comprehensions.
The fact that Eric Meijer was very active in the Haskell community, I think, pretty much confirms that.
I'm not saying either approach is generally the right one, but I think it's interesting that best practice can be the polar opposite of his "single exit" recommendation
> The guard is a proposition, which must be true before the statement is executed. At the start of that statement's execution, one may assume the guard to be true. Also, if the guard is false, the statement will not be executed. The use of guarded commands makes it easier to prove the program meets the specification. The statement is often another guarded command.
e.g.
function Foo (Value : integer) : boolean;
label return;
begin
if Value < 0 then
begin
Foo := false;
goto return;
end;
Foo := Bar(Value);
return:
end;It is a different way of thinking though and it takes a while before your mind stops reaching for while loops.
There's Scheme. There may be constructs like DO and WHILE (though I don't remember if these are standard or just common extensions of Scheme), but they're often just macros implemented using inner functions and tail calls.