Summary
In his latest post, Sun blogger A. Sundararajan compares language features of Java and Scala, giving Java developers a flavor of the statically typed, functional language that runs on the JVM and is completely compatible with Java class files.
Advertisement
Sun blogger A. Sundararajan starts his latest post with a question:
There are many languages that target ... the Java Virtual Machine (JVM)—not just the scripting and dynamically typed ones. How about learning another statically typed language that is compiled [for the] JVM and seamlessly integrates [with] the Java platform? The latest mantra is "One Great VM, Many Languages", Right?
The statically typed language Sundararajan has in mind is Scala, "a functional, object-oriented and concurrent language that runs on the Java platform."
In the blog post, Scala for Java programmers, Sundararajan systematically compares Java language constructs with their Scala equivalents, and points out features available in one language but not present in the other. Sundararajan notes that his comparison is merely to give Java developers a flavor of Scala code, and is not an evaluation of whether one language is better than the other for a specific purpose.
With much recent excitement about dynamic language support on the JVM, do you think there is room for another statically typed language to capture developers' imagination as well? Scala sports many features that Ruby, Python, and other dynamic language enthusiasts favor—such as first-order functions—but provides that in a type-safe environment. And Scala code, while not compatible with Java source code, is completely compatible with Java class files, thus giving Scala developers the advantage of being able to benefit from the vast world of Java libraries.
What do you think of Scala's chances of emerging as the next "big" language on the JVM?
Scala is a nice language but frankly, as a Java developer, if I need to do scripting I'd rather use Groovy. It's a familiar syntax and has the same features these other languages do while providing superior compatibility and interactivity with Java. Ruby falls into the same bucket as Scala does for the same reason.
I don't like equivocating interfaces to traits. Interfaces don't allow programmers to enforce symmetric design principles. Traits partially accomplish this task. They are seem to be a step in the right direction, but it's not even entirely clear if "interfaces with symmetry" are even desirable outside of Ivory Towers.
I don't think Scala's "marketed" as a scripting language. Looking over the linked-to article, the only features Java has that Scala doesn't are (1) static methods (but Scala provides built-in singletons for the same semantic effect), and (2) abstract methods (but Scala offers traits that have the same semantic effect as both interfaces and abstract methods, if I'm understanding things correctly). Everything else is syntax.
Scala is not meant to add to Java the way Groovy or Nice do; Scala's meant to replace Java. What about all those usefule Java libraries? Scala lets you use them. And Scala compiles to byte code, so it *should* run on any JVM, regardless of platform.
Please note, I am not *currently* a Scala programmer. I think about it here and there, but I haven't even written a Hello World program in Scala.
Still, why would I use Scala for an incremental language improvement especially if I'm going to need to use Java libraries anyway? There's just not much of a logical argument for this language other than mental masturbation and the whole new car smell. It has zero chance of getting any real footing .
> Still, why would I use Scala for an incremental language > improvement especially if I'm going to need to use Java > libraries anyway? There's just not much of a logical > argument for this language other than mental masturbation > and the whole new car smell. It has zero chance of > getting any real footing .
I think calling it an incremental improvement is a completely incorrect characterization of Scala. It's a very different language than Java. Aside from the curly-braces around blocks, it's got very little in common with Java.
I'm very comfortable with Java and writing code in Scala is a like being on an alien planet. Even things that look the same at first, such as the for-loop, are completely different.
The biggest flaw that I see with Scala is that it uses erasure for generics. This is done because of some technical limitations coming from Java integration but it's still a disappointment.
If you want to get a quick overview of Scala, check out this page. In the frame on the left is a list of notable features. I don't know why but I can never seem to find this page from the main page:
Likewise, I'm not a Scala programmer, but a Java programmer who's keeping tabs on the future. Scala's close enough to Java to start writing code quickly, but to really appreciate it you need to start enter the (scary) world of functional programming, which requires a different mindset. It's the same sort of feel I had when I went from C to Java, where a lot of effort went into the simplest of things while I was acclimatizing to a different way of thinking.
The nice thing about Groovy is that it doesn't feel like you're being stretched. It feels like Java made easier, with a load of other goodies like closures thrown in, so your thinking processes carry on pretty much as before.
Scala seems like a different beast entirely. I guess a large part of its success/failure will depend on whether functional programming is seen as the way to the future, and whether Scala can ease the way in that direction.
Interesting to see how much traction it gets--I just saw there is an early-access plugin for Scala in IDEA (I believe only for the EAP IDEA). Plugins should help people try it out.
I think there's also a possibility that someone will write apps or libraries in Scala--faster? less code? easier to maintain? more stable under concurrent access? That makes more sense to me--finding (a) good use(s) for the language--rather than just comparing it to Java. What's it good for? What are people doing with it?
For my taste, the syntax (and presentation in the docs) has a somewhat academic taste, which I find off-putting in programming languages. I like what I've seen of the Nice programming language for this reason.
I'm looking forward to having some time once there's a plugin where I can easily browse code, compile things, etc. to take Scala for a run.
> Still, why would I use Scala for an incremental language improvement
Since Java's garbage collected already, going from Java to Scala isn't as big a leap as going from C++ to OCaml (another jump I've looked at, but failed to actually take, yet); but it is a considerable leap. Some people will take it; others won't.
Currently, the repeated logic is:
* Lisp, OCaml, and functional languages traditionally use a copying garbage collector, so data "never changes, but changes all the time" ("The lucky kids of JavaSchools are never going ... to get their head around how, in a purely functional program, the value of a variable never changes, and yet, it changes all the time! A paradox!" http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html )
* A runtime with a copying collector generally makes for easily parallelized programs ("[Google's] MapReduce is, in retrospect, obvious to anyone who remembers from their 6.001-equivalent programming class that purely functional programs have no side effects and are thus trivially parallelizable.", same link)
* Therefore all good multithreaded/parallelized programming will be in functional languages.
For the record, I think this argument is bunk and suffers from serious logical errors. But I also think that functional programming offers much more than potentially easier-to-write multithreaded programming styles. I'm more likely to write "higher order" Perl ( http://hop.perl.plover.com/ ) than OOP Perl, both because functional programming solves more problems than Java-style (or Perl-style, or CLOS-style) OOP does (although it generally solves different problems) and because nowadays I find myself thinking in terms of Perl's version of map and grep.
Having both OOP and functional programming styles available in a language other than Perl is on my wish list, so long as the syntax isn't too weird. Yes, I know with CLOS and SCOOPS (Scheme's version of CLOS), I've got both in Lisp/Scheme. And, so far, efforts to become a Lisp programmer have been less-than-satisfying. But I am working on it.
> * Therefore all good multithreaded/parallelized > programming will be in functional languages. > > For the record, I think this argument is bunk and suffers > from serious logical errors. But I also think that > functional programming offers much more than potentially > easier-to-write multithreaded programming styles.
Kay Schluehr posted this on another thread recently. Not sure if you saw it. It challenges the notion that parallelism 'comes for free' in functional languages.
Quick read. Worth a look. I agree though that functional approaches are much more conducive to parallelism. But then again, isn't the argument of people like Joel Spolsky that the difficulty makes it better? "These Lisp kids, they've never had to deal with a deadlock or race condition!"
There are other functional programming languages which (do now or will soon) compile to JVM class files. So, the question is rather, "is Scala the next big functional programming language?"
My answer is a definitive no. It is a far easier thing to alter a compiler so that it makes JVM class files than it is to "get the language right". Functional language communities have been working on the latter problem for years, and Scala makes no significant contributions to the solution.
Flat View: This topic has 19 replies
on 2 pages
[
12
|
»
]
Previous Topic
