Jazoon-2008.ppt
Upcoming SlideShare
Loading in...5
×
 

Jazoon-2008.ppt

on

  • 911 views

 

Statistics

Views

Total Views
911
Views on SlideShare
910
Embed Views
1

Actions

Likes
0
Downloads
6
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Jazoon-2008.ppt Jazoon-2008.ppt Presentation Transcript

    • A guide to modern languages and 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 Next
      • Big
      • 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> speak
      • Hello 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: something
      • 4> 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
      • &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)
      • 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
      • &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)
    • 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 + &quot;:&quot; + 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!)
    •