What exactly is the alternative?
If there's any problem here it's automatic coercion.
most languages have some screwed-uppedness about collections, both intrinsic to the language and that gets introduced by people who make APIs that aren't well designed. for instance, arrays and Lists are often not quite perfectly uniform (and it's often a thoughtless arbitrary choice if people decide to return you one or the other) Scala introduces it's own collections that provide more confusion when you're working with Java. The .NET framework has a great implementation of generics (makes Java and Scala look like a joke) but there are still many legacy APIs in the .NET framework that use non-generic collections.
One result is that it's not always obvious what the right way to test for "empty" is. One of the worst of them is that pretty frequently APIs will give you a null when they ought to be sending you an empty collection, so you need to check for null.
Either the types that are returned are scala collections, or they're java collections. If you want to treat java collections like scala collections you can always `import JavaConversions._` and huzzah, shallow conversions and collection uniformity.
Finally, if something has the possibility of being null, you can use the option construct, e.g.
if (Option(someListThatMightBeNull).getOrElse(List()).isEmpty) { ... }
Option(someListThatMightBeNull) match {
case Some(list) => // do something...
case None => // do something else...
}
I want something like NOT NULL in SQL. Can't static typing make it completely impossible that I'll get a null in a situation where it should be completely impossible?
For instance if something is typed as a collection, I'd like to never see null, I'd rather always get an empty collection. If I have to test for None, I'm just adding more bulky code where errors can hide, particularly when the type inference system in Scala is always doing strange things behind my back.
In my mind, automatic conversions make the problem worse in Scala, not better. Code "just works" for the programmer in certain situations no matter how inconsistent people are in the types they use.
The trouble I see is that Scala programmers seem to be pretty random if they're going return an Array, a java.util.List or a scala.util.List. This is really a pain in the ass when I'm trying to access some Scala objects from Java and I don't have automatic conversion available. I'm also sure that these different choices have all kinds of effects when you consider inheritance, variance, type inference and all that. It adds to the problem of spooky action at a distance in Scala.
In ruby, everything except false and nil is true. Easy.
Unless you override the == method of course. With great power...
For instance, 0 == false isn't too crazy, it's like C. But automatic coercion of string values to ints makes "0" == false which is sometimes what you want and sometimes not.
Practically this burns people in form validation code because often you want to test if a field is an empty string and if you do the obvious thing you can end up kicking out "0".
When I write PHP I have my own "PHP on nails" library that has functions that smooth out most of the things that are wrong with the language, and one of them is a comparison operator that is somewhere between "==" and "===" that most frequently does what you want it to do.