A guide to modern languagesand interesting concepts

for the busy Java programmer

Cedric Beust

Google

Jazoon 2008, Zurich

About me

• Software engineer working at Google on the Android project

• Creator of TestNG

• Co author of "Next Generation Testing in Java" with Hani Suleiman

• Really, really loves programming languages

My goal

"Every programmer should learn at least one new language every year"

• To help you catch up on non-Java languages and innovative concepts...

• … and show you that Java is in pretty good shape.

• Answer the following question:

What is the NextBig

Language?

Why I am doing this

• I love programming languages

• … especially Java

• Java is here to stay

Menu

1) Languages• Ruby• Scala• Groovy• Erlang

2) Java• Typing (dynamic, static, duck)

Ruby (Yukihiro "Matz" Matsumoto)

zippedFiles =

Dir.new(dir)

.entries

.sort

.reverse

.delete_if { |x| ! (x =~ /gz$/) }

Ruby: why you should care

• Fully OO

• Pleasant and regular syntax

• Intuitive closure support

• Ruby on Rails

Ruby: why you shouldn't care too much

• Not statically typed

• Slow

• Open classes

• Monkey patching

Scala (Martin Odersky)

• A very interesting mix of Java and functional programming

• Very solid type system

• Here is a selection of noteworthy features

Scala’s interesting features

• Closures• Pragmatic approach to functional

programming• Universal accessors (no more fields!)• Option type (death to null!)• Generics• Class constructors: class Person(name: String, age: int) {

// ...}

Scala’s case classes

def printTerm(term: Term) { term match { case Var(n) => print(n) � case Fun(x, b) => print("^" + x + “.”)}

Scala: what I don't like

Implicits

Pro: clever way to implement open classes (automatic conversions, type safe)

Con: next slide…

The problem with implicit

scala> def speak (implicit greeting : String) = println(greeting)speak: (implicit String)Unit

scala> speak("Goodbye world")Goodbye world

scala> speak:6: error: no implicit argument matching parameter type String was found.

scala> implicit val hello = "Hello world"hello: java.lang.String = Hello world

scala> speakHello world

Scala: why you should care

• Closures• Flexible operator overloading• Universal accessors (like Ruby and C#

have)• Solid type system• Class constructors• Great integration with the Java platform

Scala: why you shouldn't care too much

• More complex than Java

• Implicits

• Sophisticated generic system (as complex as Java, actually)

• ”Open classes”: clever but contrived

• Case classes

Last words on Scala

• Reconciling functional programming, imperative programming and the Java platform is tough

• Good way to experiment and get familiar with functional programming concepts

• Highly recommended: "Programming in Scala", by Martin Odersky, Lex Spoon, and Bill Venners

• @@ http://www.artima.com/images/scalafrontcover.jpg

Groovy: why you should care

• Implements a lot of great ideas from various languages and concepts

• High level, concise• Great integration with the Java platform• Interesting ideas and frameworks

(expando objects, Grails)• Decent Eclipse support

Groovy: why you shouldn't care too much

• Syntax is messy

• Pell-mell of features added without a vision

• Has a lot of dependencies

• Slow

Erlang (Joe Armstrong et al.)

-module(trivial_process).-export([start/0]).

start() -> spawn(fun() -> loop() end).

loop() -> receive Any -> io:format("~nI got the message:~p~n",[Any]), loop() end.

Erlang

1> c(trivial_process). {ok,trivial_process}2> Pid = trivial_process:start(). <0.38.0>3> Pid ! something. something I got the message: something4> Pid ! [something,else]. [something,else] I got the message: [something,else]

Erlang: why you should care

• No variables, only constants

• Based on exchanging immutable messages, no shared data

• Interesting approach to multiprocess and robustness (messages, supervisors)

Erlang: why you shouldn't care too much

• Feels antiquated: no OO support, reuse is mostly copy/paste (creator has a strong anti-OO bias)

• Very poor tool support• Still takes a lot of manual effort to support

multiprocess and robustness• Declarative syntax (reminiscent of Prolog)• Syntax easy to get wrong (terminators, etc...)

Erlang and remoteness

"If programmers cannot tell the difference between local and remote calls then it will be impossible to write efficient code."

Joe Armstrong (Erlang creator)

Erlang doesn't tell you if a process is remote or local (always assumed remote)

Three possible approaches:

• Hide remoteness (bad idea, see "A note on distributed computing", 1994)

• Explicitly say when a call is local or remote (RMI and Java in general)

• Assume everything is remote (Erlang)

Back to Java

Let’s talk about types!

Different types

• Static typing: the source files are enough to know the type of a variable

• Dynamic typing: need to run the code to find out

• Note: “strongly typed” and “weakly typed” are orthogonal to dynamic/static

Types in practice

Java:public void f(Person employee) { employee.promote();}

Ruby:def f(employee) { employee promote}

Dynamic typing

Pros:

• Fast prototyping

• Usually more concise than static typing

Dynamic typing

Cons:• You need to know how to use a keyboard without

making typos• Tests are mandatory• Very little help from tools (hardly any refactoring,

primitive browsing and auto completion, “code change fear”)

• Best case scenario: you catch a typo with your tests.• Worst case scenario: your customers catch the error

for you.

Dynamic typing is popular

"Compile time errors are not that common"==> True, but this is not the main problem with dynamic typing (tools!).

"Smalltalk did it all more than twenty years ago!" ==> Not really.

“I’m ten times more productive with a dynamic language”==> In the short term, probably. Gain in productivity also comes from features that are not related to dynamic typing (e.g. closures)

Let's make something very clear

Most automatic refactorings are impossible to achieve with dynamic

languages.

Repeat: impossible

One more personal thing about dynamic typing

It makes me afraid

to change code.

Duck typing

def trace(o) log(o.to_xml)end

• Duck typing is like alcohol: It feels great on the moment but causes headaches later.

Duck typing refactoring

def trace(o)

log(o.id + ":" + o.to_xml)

end

Structural typing

def test(

f: { def toXml(): String }

)

{

log(f.toXml())

}

Structural typing

Might as well capture it in a type (or a trait/mixin):

interface IXml { String toXml();}def test(f : IXml) { log (f.toXml());}

So, Java is perfect, right?

public void update(

Map<Integer, String> accounts)

{

Map<Integer, String> a2 = accounts;

Map<Integer, String> a3 = new

HashMap<Integer, String>();

// ...

}

That's a lot of text...

Type inference

public void update( Map<Integer,String> accounts){ def a2 = accounts; def a3 = new HashMap<Integer, String>(); // ...}Best of both worlds: statically typed and concise.

Report card

• Java only supports static typing and no type inference

• Ruby only supports dynamic typing (type inference N/A)

• Scala is statically typed and supports type inference

• Groovy is both dynamically and statically typed and supports type inference

The Next Big Language

• Java’s strength is its ecosystem and its tools

• The next big language will be evolutionary, not revolutionary

• Java has been evolving and adapting fantastically well

Next Big Language

• Strong IDE support

• Stable v1.0

• Extensive documentation

• Evolutionary syntax and features (closures, statically typed, optional dynamic support)

• Close in speed to Java

That’s it

Any questions? (French okay!)