

What features of Java have been dropped in Scala? - kioub
http://www.javacodegeeks.com/2011/08/what-features-of-java-have-been-dropped.html

======
qw
_"Why do we have a special syntax for arrays in the language while collections
are implemented in on top of the language? And isn't a bit irritating to
convert them from one to another all the time?"_

Perhaps it's just me, but I do not convert collections to arrays "all the
time". I can't remember the last time I did so. It seems that the author has
some bad experiences with certain libraries, but he shouldn't assume that it
is part of the standard java experience.

I also don't see why this:

    
    
        for(int idx = 0; idx < names.length; ++idx)
           System.out.println(names[idx] + ": " + ages[idx]);
        }
    

is "surprisingly tough to implement cleanly" compared to:

    
    
        names zip ages foreach {p => println(p._1 + ": " + p._2)}
    

The second syntax may be clear to Scala programmers, but I think the Java
version can be understood by most programmers

~~~
timrod
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]

~~~
jules
How does Scala figure out the precedence on that? And in general what does
`word1 word2 ... wordN` mean?

~~~
jmreardon
It goes something like:

    
    
      a b c d e f g
    

becomes:

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

~~~
tincholio
I've never tried Scala so I'm speaking from ignorance here, but that looks
awfully hard to parse for a human reader. I much prefer Haskell's:

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

------
Tichy
I like break and continue. Do we really have to jump through hoops to avoid
them just because some grandfather stated "goto considered harmful" sometime
in the last century?

~~~
pnathan
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...](https://secure.wikimedia.org/wikipedia/en/wiki/Edsger_W._Dijkstra)

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

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

------
archgoon
Odd. I typically prefer the

    
    
      foreach(x in list)
        if(unusual_condition(x))
            continue
        x2=perform_data_transformation(x);
        x3=perform_data_transformation(x2);
    

to

    
    
      foreach(x in list)
        if(!unusual_condition(x))
           x2=perform_data_transformation(x);
           x3=perform_data_transformation(x2);
    

Because

1) reduced nesting in the first,

2) makes it more clear that unusual condition should simply be skipped.

Is this a personal style thing, or should is it generally preferred to do the
second option?

~~~
DanielRibeiro
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...](http://metaphysicaldeveloper.wordpress.com/2009/05/02/closures-
collections-and-some-functional-programming/)

------
eeperson
Scala does have 'break' just not 'continue'.

<http://www.scala-lang.org/node/257>

I think this makes sense. Both encourage bad habits but continue is very easy
to emulate and break is not always easy to emulate.

edit - clarity

------
Radim
Stopped reading after the silly break&continue rant.

This guy cannot be a good programmer.

~~~
ZoFreX
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!

------
daniel_solano
To me, the odd thing is that it doesn't mention the one thing Scala drops for
which I haven't a workaround: static final fields. Now, from a pure coding
standpoint, I don't actually need a static final field. However, Android
requires such creatures if you want to create a new Parcelable, Android's
lightweight alternative to Serializable.

------
SeanLuke
Wait, Scala doesn't have switch? So every collection of nested if-statements
has to be an O(n) rather than O(1) decision?

------
flocial
How does Scala drop these from the JVM?

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

