5 ms·

Interesting post, a little random, ultimately it's really hard to 'prove' something like this in a single article. Studies maybe, but there'll always be someone

Interesting post, a little random, ultimately it's really hard to 'prove' something like this in a single article. Studies maybe, but there'll always be someone saying something contrary. I can only really offer my experience, which is architecting and building out a 25kloc app and team to go along with. Mostly, because we avoided the 'clever' scala stuff as much as possible, things went well. Maven instead of sbt. Jetty instead of play. The only scala DSL we used was squeryl. If I was doing it again, I'd probably rethink the use of scala. As helpful as it was, it was also a pain in places. Having to rewrite all our for loops was not cool. Case classes saves on boilerplate, but frankly you only write that stuff once, so it didnt really save us on a lot. Intellij elides most of the junky boilerplate (import statements, generating setters/getters, etc) in Java, so ... Now a days with the advent of Java8, we have access to lambdas, function pointers/interfaces, and the functional stream system, I am interested to see how far one can get in just pure java. Java is the new scala it seems.

kasey_junk 13y ago
Honest question that I haven't taken the time to figure out. Do I still have to have only 1 file per class/interface in Java 8?
- ryanobjc 13y ago
  you've never had to only have 1 class per file. You can only have 1 public class per file however. You can also nest classes in other classes for quick little data types you need locally. So the notion that every single last tiny class has it's own file hasn't ever been true (even if thats the coding style in a lot of code).
  - kasey_junk 13y ago
    But if I have an interface and a couple of implementations I'm back to multiple files right?
    - mason55 13y ago
      Not in scala, no.
- mason55 13y ago
  No, in fact you frequently have more when you start using case classes. Plus you frequently have the companion object that goes with your class that acts as a singleton.
  - kasey_junk 13y ago
    I understand the limitations of Scala with regard to class/trait/objects etc. What I'm asking is if it is still an issue in Java 8? I'm shocked every time I drop back into java land that people haven't revolted against this terrible requirement.
    - edwinnathaniel 13y ago
      Why is this an issue or a big deal? Really.
      - kasey_junk 13y ago
        Because it adds friction between separating implementation and interface. That is one of those things I want to be as seamless as possible. Is it a big deal in the case of 1 interface and 1 class? No not really. But in the case of thousands of them it becomes an issue. It's actually one of the biggest things I notice when I come back to java land.
        edwinnathaniel 13y ago
        I think with modern Java libraries (and testing libraries as well), the days of 1:1 interface=>classes are almost gone. I rarely do that any more these days so hopefully it'll become non-issue in the future for you.
    - mason55 13y ago
      Oh, yes, in Java it's still one class per file
adriaanm 13y ago
James Roper, my colleague, just wrote about Java 8 and Scala better than I could, so allow me to link to his post: http://jazzy.id.au/default/2013/03/28/java_8_lambdas_the_missing_link_to_moving_away_from_java.html http://jazzy.id.au/default/2013/03/28/java_8_lambdas_the_mis...
- peterashford 13y ago
  That's an incredibly arrogant post. Java programmers are just idiots waiting around for the joy of functional to dawn on them? Give me a break.
runT1ME 13y ago
>Having to rewrite all our for loops was not cool. You do realize that Scala doesn't have for loops, right?
- anonymoushn 13y ago
  That is probably why he had to rewrite them as while loops.
  - saryant 13y ago
    Or tail-recursive functions which will be transformed into loops by the compiler: http://stackoverflow.com/questions/1677419/does-scala-support-tail-recursion-optimization http://stackoverflow.com/questions/1677419/does-scala-suppor...
    - anonymoushn 13y ago
      This works until he wants something other than a single loop in his function's body, yes. It's probably best to use the @tailrec annotation as the second answer does, since if you're writing Scala you're probably targeting a godawful runtime that can't actually do TCO, and you'd be in a pile of trouble if you messed up and your compiler ended up not doing it either.
      - bad_user 13y ago
        If you need loops within loops, nothing stops you to have tailrec functions called within other tailrec functions. Any loop can be rewritten as a tailrec function and I prefer tailrec functions because it's easier to me to guard against invariants changing or to reason about branches or exit conditions. Plus with algebraic data-types, the compiler can warn you that you missed a branch. Etc... Also, the compiler does optimize plain for-loops on ranges. You can even have a macro that rewrites your nice looking for loop into a while expression. On mutually recursive tail calls, yes, the runtime doesn't have support. Because it misses support for TCO, you're ready to call the JVM "godawful"? Might consider that .NET's tailrec support was basically a guideline that didn't work on 64bits .NET up until .NET 4.0 [1] and it's still not optimized, having a rather significant performance hit versus normal function calls. For the JVM, a prototype for optimized tail recursive calls is in the works and given the attention that invokeDynamic received lately, I have no doubt it will be implemented for JDK 9 [2], especially given that people like Guy Steele are calling for it [3]. Either way, it's not so bad to implement mutually tail recursive calls by means of trampolines in Scala, especially given that you have an expressive type system at your disposal [4]. > you'd be in a pile of trouble if you messed up and your compiler ended up not doing it either TCO is considered an optimization, not a guarantee, so if you want it to do a TCO by contract, then an annotation makes sense, no? [1] http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11/tail-call-improvements-in-net-framework-4.aspx http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11... [2] http://openjdk.java.net/projects/mlvm/subprojects.html http://openjdk.java.net/projects/mlvm/subprojects.html [3] http://i.imgur.com/5X3VwOy.png http://i.imgur.com/5X3VwOy.png [4] http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and-trampolines.html http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and...

kasey_junk 13y ago

Honest question that I haven't taken the time to figure out. Do I still have to have only 1 file per class/interface in Java 8?

ryanobjc 13y ago
you've never had to only have 1 class per file. You can only have 1 public class per file however. You can also nest classes in other classes for quick little data types you need locally. So the notion that every single last tiny class has it's own file hasn't ever been true (even if thats the coding style in a lot of code).
- kasey_junk 13y ago
  But if I have an interface and a couple of implementations I'm back to multiple files right?
  - mason55 13y ago
    Not in scala, no.
mason55 13y ago
No, in fact you frequently have more when you start using case classes. Plus you frequently have the companion object that goes with your class that acts as a singleton.
- kasey_junk 13y ago
  I understand the limitations of Scala with regard to class/trait/objects etc. What I'm asking is if it is still an issue in Java 8? I'm shocked every time I drop back into java land that people haven't revolted against this terrible requirement.
  - edwinnathaniel 13y ago
    Why is this an issue or a big deal? Really.
    - kasey_junk 13y ago
      Because it adds friction between separating implementation and interface. That is one of those things I want to be as seamless as possible. Is it a big deal in the case of 1 interface and 1 class? No not really. But in the case of thousands of them it becomes an issue. It's actually one of the biggest things I notice when I come back to java land.
      - edwinnathaniel 13y ago
        I think with modern Java libraries (and testing libraries as well), the days of 1:1 interface=>classes are almost gone. I rarely do that any more these days so hopefully it'll become non-issue in the future for you.
  - mason55 13y ago
    Oh, yes, in Java it's still one class per file

adriaanm 13y ago

James Roper, my colleague, just wrote about Java 8 and Scala better than I could, so allow me to link to his post: http://jazzy.id.au/default/2013/03/28/java_8_lambdas_the_missing_link_to_moving_away_from_java.html http://jazzy.id.au/default/2013/03/28/java_8_lambdas_the_mis...

peterashford 13y ago
That's an incredibly arrogant post. Java programmers are just idiots waiting around for the joy of functional to dawn on them? Give me a break.

runT1ME 13y ago

>Having to rewrite all our for loops was not cool. You do realize that Scala doesn't have for loops, right?

anonymoushn 13y ago
That is probably why he had to rewrite them as while loops.
- saryant 13y ago
  Or tail-recursive functions which will be transformed into loops by the compiler: http://stackoverflow.com/questions/1677419/does-scala-support-tail-recursion-optimization http://stackoverflow.com/questions/1677419/does-scala-suppor...
  - anonymoushn 13y ago
    This works until he wants something other than a single loop in his function's body, yes. It's probably best to use the @tailrec annotation as the second answer does, since if you're writing Scala you're probably targeting a godawful runtime that can't actually do TCO, and you'd be in a pile of trouble if you messed up and your compiler ended up not doing it either.
    - bad_user 13y ago
      If you need loops within loops, nothing stops you to have tailrec functions called within other tailrec functions. Any loop can be rewritten as a tailrec function and I prefer tailrec functions because it's easier to me to guard against invariants changing or to reason about branches or exit conditions. Plus with algebraic data-types, the compiler can warn you that you missed a branch. Etc... Also, the compiler does optimize plain for-loops on ranges. You can even have a macro that rewrites your nice looking for loop into a while expression. On mutually recursive tail calls, yes, the runtime doesn't have support. Because it misses support for TCO, you're ready to call the JVM "godawful"? Might consider that .NET's tailrec support was basically a guideline that didn't work on 64bits .NET up until .NET 4.0 [1] and it's still not optimized, having a rather significant performance hit versus normal function calls. For the JVM, a prototype for optimized tail recursive calls is in the works and given the attention that invokeDynamic received lately, I have no doubt it will be implemented for JDK 9 [2], especially given that people like Guy Steele are calling for it [3]. Either way, it's not so bad to implement mutually tail recursive calls by means of trampolines in Scala, especially given that you have an expressive type system at your disposal [4]. > you'd be in a pile of trouble if you messed up and your compiler ended up not doing it either TCO is considered an optimization, not a guarantee, so if you want it to do a TCO by contract, then an annotation makes sense, no? [1] http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11/tail-call-improvements-in-net-framework-4.aspx http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11... [2] http://openjdk.java.net/projects/mlvm/subprojects.html http://openjdk.java.net/projects/mlvm/subprojects.html [3] http://i.imgur.com/5X3VwOy.png http://i.imgur.com/5X3VwOy.png [4] http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and-trampolines.html http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and...