On 2 June 2011 16:55, Ricky Clarkson <[email protected]> wrote:
> >> 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. Interestingly, Scala can declare a thrown exception that Java will force you to catch, via the @throws annotation But it'll never force you to catch them at a time that's inconvenient for you. > > 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. Imagine performing an operation in parallel on an array of 100 elements, and 2 of those invocations throw. Checked exceptions state that you *must* catch a checked exception (though we all know that remoting and threads can break this) Unchecked exceptions, you can bundle together in an aggregate, but how could the enforced catch behaviour best be handled? > 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. It's everything. Support for concurrency is a big drive behind Scala, and actively encouraging and easing immutability is a big part of that. Hopefully a future effect system in the language will even be able to enforce it. As Martin also pointed out on StackOverflow ( http://stackoverflow.com/questions/6085576/why-does-scala-choose-to-have-the-types-after-the-variable-names/6086795 ) moving the position of the type is a great help to readability. Compare HashMap<Shape, Pair<String, String>> shapeInfo = makeInfo() to val shapeInfo: HashMap[Shape, (String, String)] = makeInfo() The name of the value is far more apparent in the second case > 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. When used in a generic, Int becomes an Integer in the generated bytecode. Plus, you have the ability to invoke methods on any Int (primitives don't do this) So `2.toString` is a valid Scala operation. > 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. It gets more interesting with larger comprehensions: val tags = for { page <- site.pages tag <- page.tags ucTag = tag.toUpperCase } yield ucTag and that's just a short example, not even using a filter. The difference between <- and : helps indicate that this construct really isn't a loop. > > 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? > > Scala's grammar is approximately 1/3 of Java's. When counting non-whitespace lines from the respective BNF descriptions of the two languages, as taken from the official specifications. > >> 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. > > -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- 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.
