Hacker News Reader

Comment by Animats | Hacker News Reader

It was controversial at the time.

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.)

View on HN

I had always heard that the "single exit" focus on "break" and "continue" was a misunderstanding. When wild GOTOs roamed the earth, with was common for a subroutine to end by jumping to a new part of the code, with the jump location being different depending on conditionals within the code. The "single exit" commandment was that a subroutine should always exit back into the routine that had called it. That makes it less an injunction against a function having early returns and more a rejection of continuation passing style.

"Break" and "continue" have been (accurately) described as "structured goto". They are, at heart, goto. But they are constrained to operate in ways the make sense within the structured programming approach.

> Single exit, though, means no "break", or "continue" for loops, and no early returns from functions.

Sounds like pretty standard functional programming a la Standard ML or Haskell, or am I missing something?

> a rather convoluted style

It may be standard for them, but it's why functional languages are niche while C, C++, C#, Java, JavaScript and Python dominate.

That's a bold claim, do you have any evidence to back that up with?

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 don't, I just have the feelings and impressions of various programmers, which is anecdata.

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?

> you can get the best features of Haskell in Python

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.

To add to the anecdata of programmer impressions: Haskell can be extremely performant compared to Python. In terms of developer experience, it almost causes me physical pain to use some of the poorly designed Python libraries out there.

Rust is a quite functional language, C# has been incorporating (aka stealing from F# :)) functional features for years starting with LINQ and ending with advanced forms like pattern matching on sequences (list patterns).

I believe all kinds of Python frameworks too like to incorporate FP into their APIs, and of course, there are list comprehensions.

LINQ is arguably stolen from Haskell, not F#. It is closer to ‘do’ notation than Computation Expressions (which has more features).

The fact that Eric Meijer was very active in the Haskell community, I think, pretty much confirms that.

Guard clauses are considered good practice in many languages, as opposed to nested if's.

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

Dijkstra came up with "guard". Well, "guarded command" as a formal part of the logic of correct programs: https://en.wikipedia.org/wiki/Guarded_Command_Language

> 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.

Was there not the workaround (at least by the time Pascal arrived), of intra-function gotos, and being able to assign the return value from anywhere? In effect, the "return" keyword of other languages.

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;

The single exit style works great in a language with TCO, nested functions and no looping primitive at all. No such language is widely available. But the style works really well and can be simulated in languages like scala if you ignore the while keyword and express all loops as tail recursive functions. This style does not work well in c (particularly due to the lack of nested functions) and similar languages.

It is a different way of thinking though and it takes a while before your mind stops reaching for while loops.

> The single exit style works great in a language with TCO, nested functions and no looping primitive at all. No such language is widely available.

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.

Well, anybody that completely redefines an area of knowledge is doomed to get one or two details wrong on the first try.

The key point of structured programming is that you don't need any control structures other than sequential composition, a conditional construct, and a (typically while) loop construct.

Reply on news.ycombinator.com