A guide to modern languages and interesting concepts for the busy Java programmer

1. A guide to modern languagesand interesting conceptsfor the busy Java programmer Cedric Beust Google Jazoon 2008, Zurich

2. 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

3. 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:

4. What is the Next Big Language?

5. Why I am doing this • I love programming languages • … especially Java • Java is here to stay

6. Menu 1) Languages • Ruby • Scala • Groovy • Erlang 2) Java • Typing (dynamic, static, duck)

7. Ruby (Yukihiro "Matz" Matsumoto) zippedFiles = Dir.new(dir) .entries .sort .reverse .delete_if { |x| ! (x =~ /gz$/) }

8. Ruby: why you should care • Fully OO • Pleasant and regular syntax • Intuitive closure support • Ruby on Rails

9. Ruby: why you shouldn't care too much • Not statically typed • Slow • Open classes • Monkey patching

10. Scala (Martin Odersky) • A very interesting mix of Java and functional programming • Very solid type system • Here is a selection of noteworthy features

11. 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) { // ...}

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

13. Scala: what I don't like Implicits Pro: clever way to implement open classes (automatic conversions, type safe) Con: next slide…

14. 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> speak Hello world

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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.

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

22. 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)

23. 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...)

24. 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)

25. Back to Java Let’s talk about types!

26. 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

27. Types in practice Java: public void f(Person employee) { employee.promote(); } Ruby: def f(employee) { employee promote }

28. Dynamic typing Pros: • Fast prototyping • Usually more concise than static typing

29. 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.

30. 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)

31. Let's make something very clear Most automatic refactorings are impossible to achieve with dynamic languages. Repeat: impossible

32. One more personal thing about dynamic typing It makes me afraid to change code.

33. 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.

34. Duck typing refactoring def trace(o) log(o.id + ":" + o.to_xml) end

35. Structural typing def test( f: { def toXml(): String } ) { log(f.toXml()) }

36. 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()); }

37. 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...

38. 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.

39. 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

40. 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

41. 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

42. That’s it Any questions? (French okay!)