What features of Java have been dropped in Scala? (javacodegeeks.com)

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.

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.

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

       // lines of code here
   }

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

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

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

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

I agree regarding the rant. I want an explanation of why I no longer need those constructs in Scala, not just a hand-wavy "they're bad, stop using them". Currently I need them, telling me that I do not is not going to sway me to your cause!

Yes, his silly "hands up if you find this more readable" breaks down if you now have two checks at the beginning, and the "rest()" part carries on for more than one line. Then you're carrying around two extra levels of indentation and cognitive context, for what exactly?

I'd write the scala example as

  names zip ages foreach { (name, age) =>
    println(name + ": " + age)
  }

which, imho, is a little easier on the eyes.

[edit: fix syntax]

  a b c d e f g

  a.b(c).d(e).f(g)

     zipWith (\x y->  x ++ " : " ++ show y) names ages

The devil's advocate argument is that it isn't readily apparent that you're using the ages array until you look deep inside the loop. With the scala code, especially with the functional syntax, you know what elements you're working with right up front.

Java and the JVM are not the same thing. Java is a programming language. The JVM is a stack-based virtual machine that executes Java bytecode. Java bytecode is what Java compiles into (ie. the contents of .class files).

As it happens, the JVM can't tell if a .class file was generated from compiling Java code, or handwritten, or generated from another programming language altogether. As long as the class file is valid, the JVM will run it. In the case of Scala, "continue" isn't in the language, so bytecode that performs the operation is never generated by scalac. In fact, "break" and "continue" don't even have any meaning at the JVM level. Java bytecode works at the level of gotos and conditional branches.

I usually prefer:

  foreach(x in list.reject(unusual_condition(_)))
    x2=perform_data_transformation(x);
    x3=perform_data_transformation(x2);

I find collections and their functional methods are great for clear expression of intent[1]

[1] http://metaphysicaldeveloper.wordpress.com/2009/05/02/closur...

I do the same; it more clearly shows intent IMO. I think your second example is more ubiquitous because of the teaching that "jumps" are bad; break, continue, goto... all of them bad. Don't do that. Etc.

Where I use this pattern a lot is argument validation on the tops of method bodies. And sometimes, "avoid the impossible conditions early" rule

    if (something_bad)
        return

    do_good_stuff()
    ...