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

Jazoon-2008.ppt

on

  • 923 views

 

Statistics

Views

Total Views
923
Views on SlideShare
922
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!)
  •