// The type of 'unsafe' is Option[String]
var unsafe = Option("some string")
unsafe = null
unsafe map println
Is complete contrived nonsense, var? Seriously, quit trolling, in Scala (immutable) val is king.
Next:
def unsafeFunction(x: Option[String]): Option[String] = {
x orElse null
}
Oh yeah, that's brilliant, let's just try our hardest to come up with scenarios that never occur in the "real" world (unless we try really hard to create nullthing out of nonething).
I'm not trolling. I genuinely want to like Scala, which is why I'm disappointed by some of its design choices.
Yes, in Scala val should be king (unfortunately, it's not -- if you've taken the two Coursera courses by Odersky you'll see some use of var in the exercises, refuting your claim). But it's true val is more common, and the use of var was accidental to my point anyway (mutation wasn't the issue), hence my clarification and second example. Yes, it's pretty obvious where I introduced the mistake, I said as much. In the real world, the mistake might be harder to spot, which is why the type system shouldn't allow it.
If I understand your position correctly, it seems to boil down to "programmers will code correctly, therefore this static check (that Option must not be null) isn't needed". Which is pretty much what dynamic typing proponents have been saying all along. A pretty untenable position if you want to stay on the side of Scala...
I'd much prefer if Option were more like Haskell's Mabye, but then again, I side with static typing. I understand why, given Scala's requirements, this wasn't possible. It's just disappointing.
There's no need to be disappointed in Scala's Option, if used sensibly (i.e. not intentionally trying to break it) Option will work as advertised.
val is indeed king, var is used sparingly, look under the hood of any prominent Scala library and you'll see val-ue of immutability put into practice. Locally scoped vars can be useful, but beyond that dangers waits (not unlike Haskell's unsafePerformIO).
In terms of disappointment, I could say similar things about Haskell: I'm deeply disappointed with the eternal compile times, meaningless stack traces (no line number, heh, nice), non-existent tooling (read: null IDE), etc.
Scala lives on the JVM and has seemless interop with Java; concessions have been made, the type system will never rival that of Haskell, but then again, outside of Haskell no other mainstream language's type system rivals that of Scala.
Fair enough. I don't believe Option is only broken when "intentionally trying to break it". Of course, my example is trivial and the null is explicit. But what if it was a call to a Java method that shouldn't return null, but does because of programmer carelessness?
I agree there are pain points with Haskell as well, no language is perfect. But slow compilation... surely you're kidding when you don't see this as a problem with Scala? The compiler is SLOW. And as for IDEs, which one do you recommend? I heard good things about IntelliJ, but please don't recommend Scala IDE because to say it's inadequate would be a huge understatement. I've cursed too many times with its phantom compilation errors.
When calling a Java method assume a null return and wrap it up in an Option just as you'd do with Haskell when interfacing with the "outside" world.
As for Scala compilation speed, Haskell's not gonna win that battle, ghc is to scalac as scalac is to javac, which is to say, the last is first and the first is last in terms of compilation speed. Also, IIRC only Yesod provides incremental builds, no? With SBT incremental builds most code changes incur a < 1 second recompilation hit.
As for the IDE story, the secret to a performant Scala IDE is to turn off automatic builds in Eclipse and let SBT run the show. With the SBT eclipse plugin there's a setting that allows SBT compilation target and Eclipse target to be shared so you never have to clean/build in Eclipse -- this is a huge win, the difference between standard dog slow Eclipse performance, and snappy, oh this is real nice if only the haters knew, joy ;-)
Next:
Oh yeah, that's brilliant, let's just try our hardest to come up with scenarios that never occur in the "real" world (unless we try really hard to create nullthing out of nonething).