When used at the start of a block, as first checks made, they act like preconditions, so it's good.
When used in the middle of the block, with some code around, they act like hidden traps, so it's bad.
The question is confusing, as C and C++ are languages, while JVM is a virtual machine and .Net is a platform. Scala could be implemented in C or C++, and it could generate machine code instead of bytecode for a virtual machine.
Answering the question that was asked:
Scala was not implemented in C or C++ because Scala, the language in which it is actually implemented, is a much better language.
Why is it better? Well, go read about Odersky's goals for the Scala language.
Answering the question that may have been intended:
Scala generates primarily JVM bytecode because that provides great portability as well as features such as a reliable and efficient garbage collector, run-time optimizations and just-in-time compilation by the JVM.
Let me repeat that last thing: JVM will compile to machine code hot spots in the code it is running. That's compile just like C and C++ compilers do.
There are other virtual machines available, but Odersky, Scala's creator, was already very familiar with JVM. He intended to have CLR as an alternative, but the effort to get that going hasn't achieved success yet.
Answering the question that could/should have been asked:
Compiling to machine code doesn't provide enough benefits over compiling to JVM bytecode.
It is certainly possible to generate microbenchmarks in C or C++ that beat JVM-equivalents. It is also true that extremely optimized code in C or C++ will beat extremely optimized code in Java or Scala. The difference isn't all that great, however, for long-running program.
Note that Scala isn't a particularly good scripting language precisely because the overhead for short-running programs is too big.
However, in most cases the speed of development and ease of maintenance are more important than the speed of execution. In those cases, where people are more concerned in writing very high level code that is easily understand and change, the run-time optimizations provided by the JVM may easily beat compile-time optimizations made by C or C++ compilers, making JVM (and CLR) the target that will actually execute faster.
So, no matter whether the question was about Scala compiler being a machine code executable, or Scala programs being machine code, the potential speed gains do not, necessarily, translate into real speed gains.
And, by the way,
I'll give you a counter-example: Haskell. Haskell generates machine code, and, yet, Haskell programs fare worse on Debian's shootout than Scala's. Given that, can anyone be sure Scala programs would be faster if compiled directly to machine code?
Best Answer
Break and Continue:
In a talk about Scala, Martin Odersky gave 3 reasons not to include break or continue on slide 22:
And he then says, "We can support them purely in the libraries." On slide 23, he gives code that implements
break
. Although I don't quite know Scala well enough to be certain, it looks like the short snippet on that slide is all that's needed to implementbreak
, and thatcontinue
could be implemented in code that is similarly short.Being able to implement stuff like this in libraries simplifies the core language.
In 'Programming in Scala, Second Edition', by Martin Odersky, Lex Spoon, and Bill Venners, the following explanation is given:
Return:
Returns could be considered a bit imperative in style, since return is a verb, a command to do something. But they can also be seen in a purely functional/declarative way: they define what the return value of the function is (even if, in a function with multiple returns, they only each give a partial definition).
In the same book, they say the following about
return
:Methods end and return a value, even if a
return
statement isn't used, so there can be no issues with closures, since otherwise closures wouldn't work period.There can also be no problem meshing well with function literals, since the function has to return a value anyway.