Honestly, the exact example they criticise is a common device I use to make code less complex. Yes, you can horribly mis-use it, and you can horribly mis-use goto, but I don't want someone to tell me I can't use something just because I might not use it properly. There's an interesting discussion on goto's use in the Linux kernel here: http://kerneltrap.org/node/553/2131 (the final example, stack-style rewind, is NOT pretty in Java).

You mean Dijkstra [1]? The guy who figured out shortest-path-first routing algorithm, semaphores, reverse polish notation?

The reason GOTO considered harmful (read the paper) was to assist in formally verifying the semantics of programs. Essentially, GOTO constructs fork environments in the formal analysis, and make things really difficult to work with.

They also make informal reasoning more difficult unless you apply restrictions on how you structure your program.

Know your history before you insult the people who came up with principles.

https://secure.wikimedia.org/wikipedia/en/wiki/Edsger_W._Dij...

The article suggests as a replacement for break "but generally extracting a loop to a separate method/function (or at least putting it at the end of existing method) and using return instead will do the trick"

return (from anywhere but the end of a function) is just as damaging to formal verifiability as continue, break or goto.

Ehhh.

Continue, break, return at least are well-formed with respect to the local environment.

GOTO has no such restrictions (well, in older languages allowing arbitrary GOTOs)... that's why its considered harmful.

The single-return principle is used for flowcharts & formal analysis ease.

It'd be mildly interesting to do a retrospective of compilation & static analysis algorithms to see what more current research turns up with respect to the single-return rule's use.

Didn't know it was Dijkstra and didn't actually mean to insult anybody. I thought the 'GOTO' thing was just a community opinion that emerged sometime in the last century.

Anyway, I still think break and continue are OK. Maybe they are not as bad as GOTO, and also I never run into problems with verification of my code.

I agree. There are cases were break and continue are much more succinct and easier to understand, just as there are with goto (error handling in C for example, see linux kernel). To get rid of them just because someone considers it harmful is stupid. I'd guess the reason Scala got rid of them is not because they're harmful but because they're not very useful in a functional language where you usually don't deal with imperative loops.

I could probably live without "break", but "continue" is very useful.

   for(Person p: persons) {
       if(p.getAge() < 18)
           continue;

       // lines of code here
   }

The alternative is to have a if-else instead, and that hurts readability even if you don't usually have much code inside a for-loop. You could probably also solve it by writing a filter function that generates a new list with those you want to process, but I find having lots of "magic" functions scattered around the code to be just as annoying. And it will also hurt performance / memory usage for large datasets

In scala you would use a for-comprehension to get the same effect:

  for (p <- persons; if p.getAge >= 18) {
    println(p);
  }

Actually, the functional alternative in scala is this:

persons.filter(_.age >= 18).foreach(p => { (code here) });

That is way, way more readable, imho.

How is this any more readable than:

   for(Person p: persons) {
       if(p.getAge() >= 18)
           // lines of code here
   }

If anything, I would argue that this version is clearer since it makes the context of execution more explicit.

Unless you have multiple of these conditional checks when the indention level gets unholy.

Continue in loop is like early return from a function. Some say we should not use it. But other find it really painful to work without 'continue'. I remember moving whole body of a loop into a function call only to get "continue" support in Lua though early return.

Why would this cause indention level to get bad? Couldn't you simply chain these conditions in a single if statement?

Not if you need to pre calculate before some conditional checks, do something if some conditions are meet and you want to save state.

Basically it all comes down to organizing code. Removing 'continue' removes one's ability to organize code in a good way, as some see it.

You can break in Scala by encapsulating a code block within a 'breakable {...}' scope. The break throws an exception caught by breakable; the break literal though is not a keyword. Odersky explains (section 7.6) that because Scala leans toward a functional rather than imperative paradigm, it was necessary to give up traditional break & continue in order to incorporate other functional language facilities. He poses: what would 'continue' mean within a function literal? Reading Odersky's book now... it's interesting stuff.

No, if goto is really important to you, you can keep using Java (which was made sometime in the last century). You'd only use Scala if you thought that the language was created by smart people who have made the correct decisions with their language's feature set.