A guide to modern languagesand interesting concepts
for the busy Java programmer
Cedric Beust
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!)