• Like
Jazoon-2008.ppt
Upcoming SlideShare
Loading in...5
×
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
640
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. A guide to modern languages and interesting concepts for 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
    • &quot;If programmers cannot tell the difference between local and remote calls then it will be impossible to write efficient code.&quot;
    • 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 &quot;A note on distributed computing&quot;, 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
    • &quot;Compile time errors are not that common&quot;
    • ==> True, but this is not the main problem with dynamic typing (tools!).
    • &quot;Smalltalk did it all more than twenty years ago!&quot;
    • ==> 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 + &quot;:&quot; + 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!)
  • 43.