Locaweb TechTalks 2015 - Seven languages in Seven weeks

Locaweb TechTalks 2015 - Seven languages in Seven weeks


Renan Ranelli

February 06, 2015


  1. None
  2. Part I: Why should you care?

  3. • First of all.... Why does it matter to learn

    programming languages anyway ?
  4. • First of all.... Why does it matter to learn

    programming languages anyway ? • I think you should learn programming languages. • But my opinion probably will not matter for you, so listen to these guys instead:
  5. These guys think you should

  6. These guys think you should

  7. These guys think you should

  8. None
  9. • Disclaimer: All the languages to be presented are turing

    complete, i.e. you can do everything that can be done with a computer in any of them.
  10. • Disclaimer: All the languages to be presented are turing

    complete, i.e. you can do everything that can be done with a computer in any of them. The book (and this presentation) are by no means an exhaustive exploration of the programming languages. Think of them as food for thought.
  11. We are going to talk about: • Ruby • Io

    • Prolog • Scala • Erlang • Clojure • Haskell
  12. • What I aim to achieve: – I will try

    to explain what composes a language and how the same problem is handled by different languages – I expect to show you that a characterization such as “it is function” or “it is object oriented” is insufficient and most of the times inappropriate – I expect you to be convinced that mutable state can be avoided and that this is key to enabling efficient and sane concurrent programming
  13. We are going to talk about: • Ruby • Io

    • Clojure • Scala • Erlang • Prolog • Haskell Support for OOP Support for FP
  14. Part 2: A brief view of each language

  15. • Ruby: – Object oriented, class based, dynamically typed, strongly

    typed – Extremely meta-programmable – Complex syntax, complex evaluation rules – Reads like a novel – We all know and love it ;)
  16. • Open classes

  17. • With great powers, come great responsibilities • You can

    monkey-patch anything.
  18. • Io: – Object oriented, prototype based, strongly typed –

    Extremely simple and consistent syntax – Heavy emphasis on message passing, not method call. (actually, “method” is a message that returns an object that can receive the message “call”) – Easy to create DSLs – Excellent concurrency primitives – Crazy amount of reflective power
  19. • You can do some crazy stuff... Because who cares

    about scoping!
  20. • Futures, coroutines and actors are built in to the

  21. • Scala – OOP, FP, statically typed, strongly typed –

    Has a powerful type system – Offers advanced FP concepts such as monads and type classes. – You can emulate non-strict evaluation with “call by name” vs “call by value“ paramater passing strategies – Suffers from the Java legacy to a certain extent
  22. • Much less verbose and much more expressive than plain

    ol' java.
  23. • Has a strong focus on concurrency

  24. None
  25. None
  26. • Erlang: – Designed by Ericsson to build telecom software.

    – Alien syntax, derived from Prolog. – Functional, enforces extreme isolation and share- nothing processes. – No threading model. – Amazing support for fault-tolerant, near-real-time distributed application development.
  27. • Erlang: – Offers a somewhat different form of pattern

  28. • Example: ultra-simple process monitoring – <code code/7langs7weeks/erlang/gunloop.erl:9>

  29. • Clojure: – After Fortran, Lisp is the oldest programming

    language still actively used. – FP, supports OOP, strongly typed, dynamically typed. – Lisp on the JVM with modern constructs and libraries. – Allows meta-programming with macros. – Not so Lispy: no custom reader macros and no automatic tail call optimization. (schemers be mad)
  30. • Clojure: – Although clojure is an strict language, you

    can simulate non-strictness using macros. – It's possible to define the language on-the-fly, i.e., the language is internally reprogramable (heavy influence in ruby and smalltalk) – <code @ clojure-koans/src/koans/17_macros.clj:29>
  31. • Clojure: – Offers the CLOS long forgotten multiple-dispatch:

  32. • Haskell: – Functionally pure programming language. – No exceptions

    and no mutable state (at least the way we are used to) – Extremely powerful type system with parametric types, type class, algebraic data types and type inference. – Offers the full pack of FP crazyness: Monads, Monoids, Functors, Applicatives, Foldables are common language for Haskell programmers. – Much more close to Math, simplifying the way we represent abstract and symbolic constructs.
  33. • Haskell: – Currying, partial application and all that nice

  34. • Haskell: – Algebraic data types (or-types): –

  35. • Haskell: – Makes it impossible to use mutable state

    – But allows you to simulate it with Monads – <code @ scheme interpreter>
  36. Part 3: An analysis of what I learned reading this

  37. • What does it actually take to learn a new

    programming language? – Syntax – The programming language's primitives? – Type System (strong or weak? Static or dynamic?) – Evaluation rules (precedence, strictness, etc.) – Idioms – Libraries
  38. • Also important: – Meta-programming and extensibility models – Concurrency

    models – Library distribution – Community (of course!)
  39. • Object oriented programming – You can have OOP with

    no classes. – OOP is about “messages and objects”, not “classes and methods”. – You can dispatch using more than one type. – Class based and prototype based object systems are actually equivalent, and you can represent one in the other.
  40. • Polymorphism – Subtype polymorphism is actually pretty poor. Inheritance

    sucks. – Different paradigms will influence heavily the way you compose the behaviors in your program – Class based OOP lends itself nicely to program organization (one class, one file, internal classes in directories) – There is no such parallel in FP
  41. • Functional purity – Buys you a lot, but also

    takes its toll – With a little bit of effort, you can simulate mutable state where its absolutely necessary. – Functional purity brings referential transparency, lazy evaluation, easy concurrency and makes it easier to reason and compose programs. … but – The density of the languages tend to be higher, and the intellectual load is surely higher too. Not that you can't get used to it, but still...
  42. • Concurrency models – One big part of the book

    – Actually a pretty complex topic to discuss here – There is a lot of ways you can work around mutable state, and each one has its idiosyncrasies – The level of isolation impacts heavily the shape of your program organization and architecture
  43. • Pattern matching – Is composed of destructuring + binding

    – Takes various forms – You can simulate algebraic data types in dynamic languages (and that was mind blowing!
  44. • Constraint logic programming – Exists – I actually didn't

    pay much attention to it. Sorry.
  45. • Meta-programming and extensibility – Plays a big role on

    the practical use of the language. – The more extensible the language is, its more likely that you will encounter better and easier apis in the libraries you work with.
  46. Thank you.