Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Part I: Why should you care?

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

● 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:

Slide 5

Slide 5 text

These guys think you should

Slide 6

Slide 6 text

These guys think you should

Slide 7

Slide 7 text

These guys think you should

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

We are going to talk about: ● Ruby ● Io ● Prolog ● Scala ● Erlang ● Clojure ● Haskell

Slide 12

Slide 12 text

● 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

Slide 13

Slide 13 text

We are going to talk about: ● Ruby ● Io ● Clojure ● Scala ● Erlang ● Prolog ● Haskell Support for OOP Support for FP

Slide 14

Slide 14 text

Part 2: A brief view of each language

Slide 15

Slide 15 text

● 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 ;)

Slide 16

Slide 16 text

● Open classes

Slide 17

Slide 17 text

● With great powers, come great responsibilities ● You can monkey-patch anything.

Slide 18

Slide 18 text

● 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

Slide 19

Slide 19 text

● You can do some crazy stuff... Because who cares about scoping!

Slide 20

Slide 20 text

● Futures, coroutines and actors are built in to the language

Slide 21

Slide 21 text

● 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

Slide 22

Slide 22 text

● Much less verbose and much more expressive than plain ol' java.

Slide 23

Slide 23 text

● Has a strong focus on concurrency

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

● Erlang: – Offers a somewhat different form of pattern matching:

Slide 28

Slide 28 text

● Example: ultra-simple process monitoring –

Slide 29

Slide 29 text

● 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)

Slide 30

Slide 30 text

● 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) –

Slide 31

Slide 31 text

● Clojure: – Offers the CLOS long forgotten multiple-dispatch:

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

● Haskell: – Currying, partial application and all that nice jazz.

Slide 34

Slide 34 text

● Haskell: – Algebraic data types (or-types): –

Slide 35

Slide 35 text

● Haskell: – Makes it impossible to use mutable state – But allows you to simulate it with Monads –

Slide 36

Slide 36 text

Part 3: An analysis of what I learned reading this book

Slide 37

Slide 37 text

● 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

Slide 38

Slide 38 text

● Also important: – Meta-programming and extensibility models – Concurrency models – Library distribution – Community (of course!)

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

● 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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

● 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

Slide 43

Slide 43 text

● Pattern matching – Is composed of destructuring + binding – Takes various forms – You can simulate algebraic data types in dynamic languages (and that was mind blowing!

Slide 44

Slide 44 text

● Constraint logic programming – Exists – I actually didn't pay much attention to it. Sorry.

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Thank you.