The Artima Developer Community
Sponsored Link

Java Community News
The JavaPosse Interviews Scala Creator Martin Odersky

1 reply on 1 page. Most recent reply: Dec 21, 2007 10:35 AM by Daniel Jimenez

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 1 reply on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

The JavaPosse Interviews Scala Creator Martin Odersky Posted: Dec 20, 2007 7:09 PM
Reply to this message Reply
Summary
Following his talk at last week's JavaPolis conference, Martin Odersky, creator of the Scala language, sat down with the JavaPosse to discuss how Scala came about, whether Scala is suitable as a general-purpose programming language, practical approaches to functional programming, and why immutable objects lead to more scalable systems.
Advertisement

Martin Odersky gave a talk on the Scala programming language at last week's JavaPolis '07 conference. Following the talk, the JavaPosse interviewed Odersky about various aspects of his work on Scala and functional programming.

In the interview, Odersky talks about the origins of Scala in the Java compiler, javac, and the Java generics that he worked on for Sun in the late 90s:

Doing the [Java generics] work, I got somewhat frustrated. Java is a very nice language, but it does impose a lot of constraints when you want to want to add new stuff...

To do a good job, we really needed to integrate functional and object-oriented programming further. We [realized] we should drop some baggage. And that was the Scala project, where we said we wanted to keep bytecode and full library interoperability, but we wouldn't be completely compatible with Java source code. A lot of things are similar [to Java], but it's not the same [language].

The JavaPosse asked Odersky if he thought Scala could become a general-purpose language and even a replacement for Java:

Yes, most emphatically, yes, it can [replace Java]. If you're a competent programmer, you should have no problems getting into Scala. It should increase your productivity very quickly...

The main different between Java and Scala is that Java has a lot more boiler plate. Boiler plate is a nuisance for competent programmers, but it can be a big help for newbies because if you're a newbie, [boiler plate tells you that] you have to write this, then this, and then this, and there is not a lot of thinking you have to do.

Odersky also talks about why Scala is a practical approach to functional programming:

Some people say that Scala should have been a nice purely functional language, like Haskell... and that it was watered down to play in the Java pound. But I don't agree with that. Scala tries to be something different [from pure functional languages]... What we tried is to find this fusion of functional and object-oriented programming.

One of the key tenets of functional programming is that functions hold very little state: instead, of they operate on some input, and return an output value. The JavaPosse asked Odersky why he thought immutable objects were important:

First of all, objects in Scala can be plain, mutable objects, like in Java. There is no problem with that at all. But we recommend that if you can make [objects] immutable, that's good, and you should try to find out where you can make objects immutable.

The first reason [why we recommend that] has to do with parallelism and multi-core. If you have an immutable object, you don't have to lock access to that object. It doesn't need to be synchronized because ... it doesn't change. So everybody can access the same object. The more immutable objects you have, the better your application will parallelize. That's true whether you do it with threads, with actors, or with software transactions, that's the underlying thing that always holds true. The more state you have, the more trouble you have when you parallelize things. State, mutable objects, become more and more an efficiency bottleneck.

[Stateful objects] used to be a shortcut for efficiency. You couldn't create new copies of objects because that was too expensive. But it actually has turned around, even for single-threaded code. If you change an object, modern garbage collectors have to do a thing called card marking, which is incredibly expensive. The more you change fields, particularly of old objects, your performance is going to suffer. So it turns out that it's actually better to have immutable objects.

What do you think about Odersky's observations on Scala?


Daniel Jimenez

Posts: 40
Nickname: djimenez
Registered: Dec, 2004

Re: The JavaPosse Interviews Scala Creator Martin Odersky Posted: Dec 21, 2007 10:35 AM
Reply to this message Reply
That last bit, about card marking, caught my attention. I've tried to keep up with the broad outlines of garbage collection, but it was new to me that modifying existing objects causes additional memory tracking (this article - http://www.ibm.com/developerworks/java/library/j-jtp11253/ - explains how obvious it should have been in retrospect).

I have long been a fan of immutable objects in Java; I remember reading long ago, on JavaWorld, about blank finals, and have since tried to use them as much as possible, as a notational step towards immutability. Learning about card marking provides me new ammunition when showing others why I do that.

Flat View: This topic has 1 reply on 1 page
Topic: Werner Vogels on Being Eventually Consistent Previous Topic   Next Topic Topic: JetBrains Releases Groovy, Ruby Plug-ins for IntelliJ


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us