4 ms·

Be careful; once you've been working in Scala, going back to Java is unpleasant. =)

seanmcdirmid 13y ago
I worked with Scala at EPFL during my 2 year post doc (in Martin's group). I later started working for Microsoft, and found the transition to C# to be initially painful but not incredibly so. I'm now a happy C# programmer, though I take a lot of liberties [1] with the system, and I also use C# mostly to build programming systems of my own [2] (though Scala has had an everlasting influence on my own work). 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/ http://bling.codeplex.com/ [2] http://research.microsoft.com/apps/pubs/default.aspx?id=189802 http://research.microsoft.com/apps/pubs/default.aspx?id=1898...
- rybosome 13y ago
  That's actually a very fair point - when it comes to usability with respect to the functional style, sometimes less is more. I think C# is actually a pretty good example of a pragmatic language that offers FP to make your life easier, but doesn't beat you over the head with it. If I could choose between Java and C# purely on the basis of the language, there is no question that I'd choose C#.
- pkinsky 13y ago
  In my (limited) experience, for expressions make for some of the most concise code I've seen. So many problems can be represented as a chain of Options or Futures mixed with standard {val x = expression y} expressions.
  - seanmcdirmid 13y ago
    But why would you want to? Even in Scala? Use Futures only when bothered with async IO, and even then be very careful about it. Options always made debugging more difficult because they defer where you get your NPE.
    - pkinsky 13y ago
      Isn't the point of options to statically rule out the possibility of NPE's? 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") Individual error messages with scalaz's Validations 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")
      - seanmcdirmid 13y ago
        The problem is that on the JVM, you are given a debugger based on control flow, not data flow. Once you go into heavy option code, debugging that code becomes a PITA because your tools are simply wrong. So ya, you can come up with what basically amounts to a printf for data flow code, but you are stuck doing everything on your own at that point. 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.
        pkinsky 13y ago
        Is it realistic to split long chains of Option into subfunctions returning Option? If long chains of Options are hard to effectively reason about, breaking them up could ameliorate the problem. 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.
islon 13y ago
I did that and could't go back to Java, but then I learned Clojure, and now I can't go back to Scala =)

I worked with Scala at EPFL during my 2 year post doc (in Martin's group). I later started working for Microsoft, and found the transition to C# to be initially painful but not incredibly so. I'm now a happy C# programmer, though I take a lot of liberties [1] with the system, and I also use C# mostly to build programming systems of my own [2] (though Scala has had an everlasting influence on my own work). 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/ http://bling.codeplex.com/ [2] http://research.microsoft.com/apps/pubs/default.aspx?id=189802 http://research.microsoft.com/apps/pubs/default.aspx?id=1898...

rybosome 13y ago
That's actually a very fair point - when it comes to usability with respect to the functional style, sometimes less is more. I think C# is actually a pretty good example of a pragmatic language that offers FP to make your life easier, but doesn't beat you over the head with it. If I could choose between Java and C# purely on the basis of the language, there is no question that I'd choose C#.
pkinsky 13y ago
In my (limited) experience, for expressions make for some of the most concise code I've seen. So many problems can be represented as a chain of Options or Futures mixed with standard {val x = expression y} expressions.
- seanmcdirmid 13y ago
  But why would you want to? Even in Scala? Use Futures only when bothered with async IO, and even then be very careful about it. Options always made debugging more difficult because they defer where you get your NPE.
  - pkinsky 13y ago
    Isn't the point of options to statically rule out the possibility of NPE's? 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") Individual error messages with scalaz's Validations 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")
    - seanmcdirmid 13y ago
      The problem is that on the JVM, you are given a debugger based on control flow, not data flow. Once you go into heavy option code, debugging that code becomes a PITA because your tools are simply wrong. So ya, you can come up with what basically amounts to a printf for data flow code, but you are stuck doing everything on your own at that point. 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.
      - pkinsky 13y ago
        Is it realistic to split long chains of Option into subfunctions returning Option? If long chains of Options are hard to effectively reason about, breaking them up could ameliorate the problem. 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.

islon 13y ago

I did that and could't go back to Java, but then I learned Clojure, and now I can't go back to Scala =)