4 ms·

>Early adopters are disenchanted with Scala. Since everyone else seems to disagree, I'll explain why I agree: -- Scala advocates a completely different style

by quacker 13y ago

>Early adopters are disenchanted with Scala. Since everyone else seems to disagree, I'll explain why I agree: -- Scala advocates a completely different style of programming. You have to rethink how you code to match Scala's functional style. This is not a trivial thing if you have a bunch of Java developers you need to convert. -- I find the Scala documentation is less readable than Java's docs. They are cluttered with type conversion functions and unreadable operator overloads (the filtering helps a bit here, but it's extra work). Documentation is also split between the object/class/trait pages. -- There's a whole class of immutable data structures whose performance characteristics I need to learn, since I'm supposed to be using them. -- I'm not convinced that the overhead of copying immutable data doesn't outweigh the benefits of the ability to trivially parallelize the code. -- I'm not convinced that a project preferring only immutable data is easier to maintain. -- Programs seem to take longer to compile (sbt is especially slow). Now that I think about it, Scala in relation to Java is a lot like C++ in relation to C. Scala sits on top of Java, so you need to know Java, and then you need to know all of Scala's features as well. However, (as someone who knows Java) I think C++ adds useful abstractions that are non-existant in C (templating, inheritance), whereas most of Scala's features are just syntactical changes of what already exists in Java.

dragonwriter 13y ago
> Scala sits on top of Java That's not true. Scala sits on the JVM, and has some accommodations to facilitate interoperation with code written in Java, but it does not "sit on top of Java" as a language. You don't need to know Java to write Scala.
- quacker 13y ago
  Forgive my imprecision. >You don't need to know Java to write Scala Is this actually true in practice? Are there tutorials or books that don't assume knowledge of Java? In any case, if you want to use anything in the Java standard library (I assume they haven't converted the entire thing to Scala), then you'll still need to understand Java documentation which requires some knowledge of Java.
  - dragonwriter 13y ago
    > Is this actually true in practice? Seems to be. > Are there tutorials or books that don't assume knowledge of Java? Tutorials, books, and a Coursera course taught by Martin Odersky. Among other things. > In any case, if you want to use anything in the Java standard library (I assume they haven't converted the entire thing to Scala), then you'll still need to understand Java documentation which requires some knowledge of Java Sure, if you want to use something in a Java library (standard library or not) for which no one has written Scala-focussed documentation, its likely you'll need to understand Javadocs; that's not a "need to know to use Scala", that's a "need to know to effectively interface with existing Java library code", which applies just as much when leveraging Java libraries from any other language. OTOH, the structure of Scala makes this fairly straightforward, and its probably a lower barrier if you know Scala but not Java than almost any other non-Java language from which you might call Java.
  - anonymoushn 13y ago
    If you want to use Scala without ever calling or being called from Java, you probably picked the wrong FP language. If you want to use Scala to call and be called by Java, you will need to know Java to debug anything.
mark242 13y ago
-- I'm not convinced that the overhead of copying immutable data doesn't outweigh the benefits of the ability to trivially parallelize the code. Let me introduce you to my friend, Mister ConcurrentModificationException. He's a wily fellow-- he rarely pops up when you're doing local development, but he has this nasty habit of showing up in production whenever you start hitting a decent load. He's like Keyser Soze. You see him, then you try to debug the place he shows up, and poof he's gone, back into the shadows from whence he came, only to reappear when you try to iterate over that singleton java.util.ArrayList once more. Now, let me introduce you to my other friend, Miss scala.collection.immutable.List. She's a superheroine. You can run code using her on one thread, or ten threads, or ten thousand threads, she doesn't care, you're always going to get the same iterator back when you call List.foreach. For the very small price of a little bit of garbage (which Mister ParallelGC takes care of very readily), Miss immutable.List will return that filtered list the exact same way, every single time you run the filter method with those parameters you set. You can run code with her in development, staging, production, she's always ready to go, and you'll never run into Mister ConcurrentModificationException when you're dealing with Miss immutable.List. -- I'm not convinced that a project What do you mean? All I read was "I'm not convinced that a project". Someone else must have come by and edited your post before I was able to read it.
- quacker 13y ago
  singleton java.util.ArrayList So...don't use data structures that are not thread-safe in threaded environments? Wrap it with Collections.synchronizedCollection. Or make copies, if you prefer. For the very small price of a little bit of garbage... What small price? If I have millions of things stored in an immutable data structure, do I not have to copy the entire structure (or at least some portion of it) when I want to modify anything inside of it?
  - coopdog 13y ago
    It's actually all just pointers to data, so when you change something it makes a new node and copies a few new pointers so the new tree is still correct. All of the old data and pointers that aren't changed stay exactly where they are.
anonymoushn 13y ago
I am also posting to disagree. In general, I have been pretty rough on Scala, but the long and short of it is something like this: Scala trades being a usable FP language for being good at Java interop. Everything you could want to do in Java (except for enums) is possible and usually significantly easier and more succinct in Scala. Everything you would want to do in OCaml, Haskell, or Scheme, is possible and usually extraordinarily difficult in Scala. > -- Scala advocates a completely different style of programming. You have to rethink how you code to match Scala's functional style. This is not a trivial thing if you have a bunch of Java developers you need to convert. Imperative Scala is both performant and readable. For the application I work on, in many places it is the only style that is sufficiently performant. > -- I find the Scala documentation is less readable than Java's docs. They are cluttered with type conversion functions and unreadable operator overloads (the filtering helps a bit here, but it's extra work). Documentation is also split between the object/class/trait pages. This is pretty much true. Good IDE support and #scala@freenode help. > -- There's a whole class of immutable data structures whose performance characteristics I need to learn, since I'm supposed to be using them. You can use whatever data structures you want, including the ones in java.util. If immutable data structures are appropriate for your application (for instance, because you want nondeterminism based on Scala's delimited continuations, and repeated invocations of the same continuation should of course see the same data, or because you want to pass a lasting view of the current state of your collection to another thread), then you can use them. > -- I'm not convinced that the overhead of copying immutable data doesn't outweigh the benefits of the ability to trivially parallelize the code. This is an objection to a particular way of structuring applications, rather than to a language. > -- I'm not convinced that a project preferring only immutable data is easier to maintain. This is also not a Scala thing. My insignificant industry experience indicates that it is true. More importantly, John Carmack seems to think so: https://news.ycombinator.com/item?id=6278047 https://news.ycombinator.com/item?id=6278047 > -- Programs seem to take longer to compile (sbt is especially slow). Yeah. I would be okay with this if I got the GLORIOUS TYPE SAFETY from it, but Scala does not really deliver on this front. > then you need to know all of Scala's features as well. This is a big burden, to be sure, and Scala introduces some unreasonable gotcha's along the way. Having already learned Scala, though, there's no reason I would sit down and write Java. Unless I wanted an enum.

by quacker 13y ago

dragonwriter 13y ago

> Scala sits on top of Java That's not true. Scala sits on the JVM, and has some accommodations to facilitate interoperation with code written in Java, but it does not "sit on top of Java" as a language. You don't need to know Java to write Scala.

quacker 13y ago
Forgive my imprecision. >You don't need to know Java to write Scala Is this actually true in practice? Are there tutorials or books that don't assume knowledge of Java? In any case, if you want to use anything in the Java standard library (I assume they haven't converted the entire thing to Scala), then you'll still need to understand Java documentation which requires some knowledge of Java.
- dragonwriter 13y ago
  > Is this actually true in practice? Seems to be. > Are there tutorials or books that don't assume knowledge of Java? Tutorials, books, and a Coursera course taught by Martin Odersky. Among other things. > In any case, if you want to use anything in the Java standard library (I assume they haven't converted the entire thing to Scala), then you'll still need to understand Java documentation which requires some knowledge of Java Sure, if you want to use something in a Java library (standard library or not) for which no one has written Scala-focussed documentation, its likely you'll need to understand Javadocs; that's not a "need to know to use Scala", that's a "need to know to effectively interface with existing Java library code", which applies just as much when leveraging Java libraries from any other language. OTOH, the structure of Scala makes this fairly straightforward, and its probably a lower barrier if you know Scala but not Java than almost any other non-Java language from which you might call Java.
- anonymoushn 13y ago
  If you want to use Scala without ever calling or being called from Java, you probably picked the wrong FP language. If you want to use Scala to call and be called by Java, you will need to know Java to debug anything.

mark242 13y ago

-- I'm not convinced that the overhead of copying immutable data doesn't outweigh the benefits of the ability to trivially parallelize the code. Let me introduce you to my friend, Mister ConcurrentModificationException. He's a wily fellow-- he rarely pops up when you're doing local development, but he has this nasty habit of showing up in production whenever you start hitting a decent load. He's like Keyser Soze. You see him, then you try to debug the place he shows up, and poof he's gone, back into the shadows from whence he came, only to reappear when you try to iterate over that singleton java.util.ArrayList once more. Now, let me introduce you to my other friend, Miss scala.collection.immutable.List. She's a superheroine. You can run code using her on one thread, or ten threads, or ten thousand threads, she doesn't care, you're always going to get the same iterator back when you call List.foreach. For the very small price of a little bit of garbage (which Mister ParallelGC takes care of very readily), Miss immutable.List will return that filtered list the exact same way, every single time you run the filter method with those parameters you set. You can run code with her in development, staging, production, she's always ready to go, and you'll never run into Mister ConcurrentModificationException when you're dealing with Miss immutable.List. -- I'm not convinced that a project What do you mean? All I read was "I'm not convinced that a project". Someone else must have come by and edited your post before I was able to read it.

quacker 13y ago
singleton java.util.ArrayList So...don't use data structures that are not thread-safe in threaded environments? Wrap it with Collections.synchronizedCollection. Or make copies, if you prefer. For the very small price of a little bit of garbage... What small price? If I have millions of things stored in an immutable data structure, do I not have to copy the entire structure (or at least some portion of it) when I want to modify anything inside of it?
- coopdog 13y ago
  It's actually all just pointers to data, so when you change something it makes a new node and copies a few new pointers so the new tree is still correct. All of the old data and pointers that aren't changed stay exactly where they are.

anonymoushn 13y ago

I am also posting to disagree. In general, I have been pretty rough on Scala, but the long and short of it is something like this: Scala trades being a usable FP language for being good at Java interop. Everything you could want to do in Java (except for enums) is possible and usually significantly easier and more succinct in Scala. Everything you would want to do in OCaml, Haskell, or Scheme, is possible and usually extraordinarily difficult in Scala. > -- Scala advocates a completely different style of programming. You have to rethink how you code to match Scala's functional style. This is not a trivial thing if you have a bunch of Java developers you need to convert. Imperative Scala is both performant and readable. For the application I work on, in many places it is the only style that is sufficiently performant. > -- I find the Scala documentation is less readable than Java's docs. They are cluttered with type conversion functions and unreadable operator overloads (the filtering helps a bit here, but it's extra work). Documentation is also split between the object/class/trait pages. This is pretty much true. Good IDE support and #scala@freenode help. > -- There's a whole class of immutable data structures whose performance characteristics I need to learn, since I'm supposed to be using them. You can use whatever data structures you want, including the ones in java.util. If immutable data structures are appropriate for your application (for instance, because you want nondeterminism based on Scala's delimited continuations, and repeated invocations of the same continuation should of course see the same data, or because you want to pass a lasting view of the current state of your collection to another thread), then you can use them. > -- I'm not convinced that the overhead of copying immutable data doesn't outweigh the benefits of the ability to trivially parallelize the code. This is an objection to a particular way of structuring applications, rather than to a language. > -- I'm not convinced that a project preferring only immutable data is easier to maintain. This is also not a Scala thing. My insignificant industry experience indicates that it is true. More importantly, John Carmack seems to think so: https://news.ycombinator.com/item?id=6278047 https://news.ycombinator.com/item?id=6278047 > -- Programs seem to take longer to compile (sbt is especially slow). Yeah. I would be okay with this if I got the GLORIOUS TYPE SAFETY from it, but Scala does not really deliver on this front. > then you need to know all of Scala's features as well. This is a big burden, to be sure, and Scala introduces some unreasonable gotcha's along the way. Having already learned Scala, though, there's no reason I would sit down and write Java. Unless I wanted an enum.