> > > ... Erlang gets to run in its own environment, where things like > hot-deployment
of modules and parallelism is baked in from the get-go ... Scala, on the other hand, gets > compiled to bytecode that's run on a standard JVM with high degree of > interoperability with Java and other bytecode-based libraries. In my > mind, this presents a limitation as to how much of those Erlang-like > features Scala can implement. This isn't language stuff. This is > implementation, runtime stuff. .... In a sense then, both Java and > Scala programmers have to step outside their language's native > constructs and talk to these libraries their way in order to achieve > these runtime benefits. > > The only real benefit of the Erlang VM is green threads. The JVM works with Native (O/S) threads. As O/S threads are much more heavyweight, Scala offers the 'reactor' pattern, in which a thread pool is use, and the stack is discarded after each 'reaction' This essentially duplicates that particular feature of the Erlang VM As for hot-deployment. We have OSGi, and JRebel. Many things are possible :) In all other respects, the JVM is better optimised and is available on a wider range of processors. > Object-Oriented is no different. You can write OO in C by putting > function > > pointers in structs and calling them objects. > > It may not be elegant, but it works, and it's the basis for programming > > against Microsoft's COM. > > And Perl's OO. :) Then touting Scala's functional attributes is primarily about syntax. > There's nothing particularly wrong with that, but if one were to > compare Java to Scala, we then have to compare functional style > expressed in Java (perhaps using a variety of approaches, since there > is no single standard way as of yet) to Scala's, and then maybe > imperative style expressed in both languages as well. If it's not the > FP itself that solves problems, but rather the style that may adhere > better to some problems, then we should be ready to say: Scala's > functional style is better for solving X than Java's functional style; > as opposed to saying, "Look how elegant this functional bit is written > in Scala and look how ugly this imperative/OO style is in Java doing > the same thing!" Functional is a way of thinking. You hit the nail on the head by saying "functional STYLE", because a "style" is exactly what it is. A language is Functional if it supports/encourages that paradigm (primarily by making functions into first-class values) There you go. Let's compare actor use in Java and Scala. I'm sure > Scala's way is cleaner, but I haven't tried this myself yet. Take a look at Akka, seriously. See for yourself! If there are some insanely complex type system > features in Scala (I'm just shooting from the hip here, not from > firsthand experience) and only 5% of people know how to author API > with them, and maybe 30% understand how to consume those API, then > what good is it? And how do you measure this kind of complexity at a > stage where we still don't fully know how wide the audience for the > language is going to end up being? The collections library in Scala uses some of those "insanely" complicated features. They allow for e.g. `sum` to exist as a method on the List type: If you have a List[Double], it'll return a Double If you have a List[Int], it'll return an Int If you have a List[BigInt], it'll return a BigInt If you have a List[String], it'll throw a compile-time error This is not a difficult API to consume If you're interested in looking deeper, a lot of the "high-wizardy" type system stuff is inspired by Haskel's typeclasses. For the real bleeding-edge work in this area, take a look at Scalaz: http://code.google.com/p/scalaz/ (disclaimer: scalaz *is* complicated, nobody's denying it, and I wouldn't expect to the the library in "typical" programs) > Just look at joda-time, and google-collections, both are very obviously > > written in an FP style. > > Right, and as I mentioned above, we can use them in Java without > turning Java into a FP language. Or can we? Does it even matter? > I'd much rather talk about programming style than language style at > this point. To me, the JVM is the platform and can be the basis for > different languages to interoperate and allow one piece to be written > in one style and then another piece in another style -- whatever suits > the specific problem at hand. If we can come to that point with > relatively seamless integration of libraries and modules written in > different languages, that's just perfect. Then we don't need to argue > which language is better overall. We can just pick and choose; > literally the right tool for the job. Totally, and this is part of the reason that Scala concentrates on interop so heavily. I can easily imagine writing an app with a JavaFX gui and a Scala back-end ... part of me wonders if a virtual > machine that is geared specifically to FP style of code and API would > be better at optimizing FP-styled managed code. Possibly... there are planned JVM features (such as tail-call optimisation) that would definitely benefit a functional style in any JVM language. But, at some point, all functional languages get converted to imperative code that will target the underlying physical architecture. Many of the JVM's optimisations operate on this level and are valid regardless of the style used. > Looked at the examples. Haven't had a chance to read the discussion > yet. To me, the Java snippet is completely subpar. It's simply not a > good example. > > At first glance, one can clearly see that Scala is much more readable > and expressive of the intent. > ... I do think the two versions were > written by different people, likely at different times. This is > interesting to look at, but I can't take this as a fare contrast of > languages at face value. By the same person. The Java version came first. This shows quite nicely how exposure to Scala is helping make him a better programmer! -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- 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.
