However, all the Scala positions I've found are looking for engineers with experience using Scala in production. How can I make that jump? Are there any opportunities out there for junior engineers who are proficient in Scala?
C# is a bit more advanced in Java (they have lambdas), and in someways better than Scala (reified generics). But the best thing about C# is that...it forces you to to settle on less elegant but functional designs in a "worse is better" style. I found myself obsessing over my Scala code to come up with perfect solutions because...I could...while in C# perfect solutions obviously don't exist. C# relieves the burden of choice, which is an interesting trade off to keep in mind when designing PLs.
[1] http://bling.codeplex.com/
[2] http://research.microsoft.com/apps/pubs/default.aspx?id=1898...
def f1:Option[Int] = Some(1)
def f2(a: Int):Option[Int] = Some(a + 1)
val r = for {
a <- f1
b <- f2(a)
c = a * b
} yield c
r.getOrElse("generic error")
def f1:Option[Int] = Some(1)
def f2(a: Int):Option[Int] = Some(a + 1)
val r: Validation[String, Int] = for {
a <- f1.toSuccess(e = "f1 failed")
b <- f2(a).toSuccess(e = "f2 failed")
c = a * b
} yield c
r.fold(e => s"error: $e", r => s"result: $r")The problem really stands that no one knows how to build decent data-flow debuggers. Haskell programmers prefer static safety over debugging just as much as because their debuggers suck as the type system is so powerful. In Scala, you have the option to write crash-early strict code: do it, you will make your life so much easier as a result.
I suppose that conceptually, I consider returning None inside a chain of flatmapped options as the equivalent of terminating early. It's not hard to pass along an object describing the error instead of None, which gets you the equivalent of a thrown exception.
Also: can you point me towards any examples of this antipattern? I 'd like to see it in action, if only so I can avoid it in my own code.
For simple programs that do not need to be debugged, laziness is great, you can write some very concise code. Once you are debugging however, you want to expose as much control flow as possible to break and step through. I say this from writing 10s of thousands of Scala code in a fairly complicated context (Scala compiler + Eclipse) with non-trivial control flow (mostly event driven).