>> Very limited type inference. Not all Scala's fault, it's partly >> because of the interop with Java. > > True, H-M just can't be used in the face of subclassing
Another part of the problem is separate compilation. There's a lot of type inference that could be done if you could guarantee that the code you're compiling now is not going to be used with other code, or other versions of the code you're compiling now. > I'm not starting again on how many ways checked exceptions are wrong, it's > an old argument. Sure, but if you rely on it currently in Java, it is something you'll notice that's missing from Scala. > We'll doubtless start to see the problems really happen once Java gets > closures and parallel arrays. I know nothing about parallel arrays, but Neal Gafter did manage to identify and solve all the problems exceptions gave in the BGGA proposal. Logically it's not much more complicated than return types. > This difference is a feature. If you're making mutability easier by default > then you have some nast problems with thread safety and concurrency in your > future. It's not that much of a feature, and in any case I don't think not requiring 'var' hobbles the language. > But they aren't the same. Int in Scala and int in Java compile to the same thing almost all of the time. The difference I know of is in generics, where List<int> doesn't compile in Java and List[Int] does in Scala. > It also breaks consistency with the pattern that class names > start with an uppercase letter. That convention is less consistent in Scala already. Consider package objects, for instance. > and > val x = "Hello World" > becomes > x = "Hello World" > I suppose? No, final x = "Hello World" >> for (x -> 1 to 5) >> becomes >> for (x: 1 to 5) > > This beaks a convention that : is used to specify types. I already broke that in the above, by changing x: String to String x, so at this point I'm free to use the : for something else. > There's a running pattern here, that Scala places a far higher premium on > internal consistency than Java does. This is a Good Thing There are measures of this stuff. Smalltalk, Forth and Lisp (so, Clojure) all have wildly more consistent syntax than Java or Scala, and that's both to their advantage and disadvantage. Is Scala's grammar actually smaller or larger than Java's? >> How are Google backing Scala? > > Today and tomorrow, they're sponsoring > ScalaDays: http://days2011.scala-lang.org/ Cool, I didn't know. > It's faster in cases where it's easier to take advantage of parallelism, But you could do all those things in Java, just with more difficulty. You need to change just one variable at a time in your experiments. > where generic types can avoid boxing/unboxing costs via specialization > (http://www.scala-lang.org/sid/9) That one's interesting. Practically people use the more irritating byte[] in Java instead of, say, List<Byte> because of that, so if List[Byte] is actually faster than List<Byte> that's a pretty big win. >> Perhaps multi-process architecture, like Chrome, is a good natural >> step there, without having to switch languages. Also, Scala doesn't >> enforce anything that helps in concurrency. It only provides useful >> libraries. There's not even a good way of looking for unsafe code >> like there is with Haskell (literally, look for the word unsafe). > > Haskell rocks, but I was specifically limiting this discussion to the Java > platform. > Jaskell exists, but doesn't seem mature yet. The point wasn't that one should use Haskell, just that something Scala could benefit from is clarity regarding side effects. Haskell is merely an example of a language that has that. > I hope not. Biology has shown time and time again that Monocultures are > risky and fragile things. It's a beautiful thing that Java works across so > many operating systems. But not the one in your pocket and not in your web browser (applets exist, GWT exists, but you know what I mean). -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
