Presentation Objects and functions, conflict without a cause?

Object-oriented has been the standard paradigm in programming for a long time, but it was not always like this. This talk will go back to the early history of OOP and explain why it became popular. It will then draw parallels to the current rise of functional programming. Even though FP has been around "forever" in computer terms it is only now gaining serious traction, and I will explore some of the reasons for this. Functional and object-oriented programming are today often seen as opposites - you do one or the other. I will argue that this is a false dichotomy, and that OOP and FP can indeed be perfect complements, once we shift a little bit our viewpoint of what the core characteristics of objects are.

Speakers


PDF: slides.pdf

Slides

Objects and Functions

Objects and Functions Conflict Without a Cause? Martin Odersky @odersky

In this talk

In this talk 1. Some history: • How objects became mainstream • Why functional programming is about to become mainstream now 2. OOP vs FP do we have to choose one? 3

My involvement

My involvement 1984 – 1989: Pascal, Modula-2, Oberon, student of Niklaus Wirth 1990 – 1995: Research in functional programming: Haskell, λcalculus 1995: Former boss at IBM told me: “You should get out of your field: The language wars are over. C++ has won. There’s nothing left to do. 1995 – 2000: JBuilder, Pizza, GJ, Java generics, javac ( “make Java better” ) 2001 – now: A third way that encompasses FP + OOP: Scala 4 (“ k b tt J ”)

Why the title?

Why the title? (at the time, the controversy was about Eiffel vs type theory). 5

How OOP got started

How OOP got started ■ First popular OOP language: Simula-67, for simulations ■ Second popular OOP language: Smalltalk, for GUIs 6

Why did OOP become popular?

Why did OOP become popular? Encapsulation? 7

Why did OOP become popular?

Why did OOP become popular? Encapsulation? Code Re-use? No 8

Why did OOP become popular?

Why did OOP become popular? Encapsulation? Code Re-use? Dynamic binding? No Don’t think so 9

Why did OOP become popular?

Why did OOP become popular? Encapsulation? Code Re-use? Dynamic binding? Dependency inversion? No Don’t think so Not directly 10

Why did OOP become popular?

Why did OOP become popular? Encapsulation? Code Re-use? Dynamic binding? Dependency inversion? Liskov substition principle? Open-closed principle? No Don’t think so Not directly Came much later 11

Why did OOP become popular?

Why did OOP become popular? Encapsulation? Code Re-use? Dynamic binding? Dependency inversion? Liskov substition principle? Open-closed principle? No Don’t think so Not directly Came much later You gotta be kidding It’s because of the things you could do with OOP. 12

How OOP got started

How OOP got started Traditional approach: Linked List Two cases: Empty, NonEmpty Unbounded number of operations: map reverse print get elem insert ... 13

How OOP got started

How OOP got started New challenge: Simulation Fixed number of operations: nextStep toString aggregate Unbounded number of implementations: Car, Road, Molecule, Cell, Person, Building, City, ... 14

How OOP got started

How OOP got started New challenge: GUI widgets Fixed number of operations: redraw boundingRectangle move Unbounded number of implementations: Window, Menu, Letter, Shape, Curve, Image, Video, ... 15

What Simulation & GUIs have in common

What Simulation & GUIs have in common Both need a way to execute a fixed API with an unknown implementation. It’s possible to do this in a procedural language such as C. But it’s too cumbersome, so people wanted object-oriented languages 16

What does this have to do with FP?

What does this have to do with FP? ■ Just like OOP did then, FP has lots of methodological advantages: ■ Fewer errors ■ Better modularity ■ Higher-level abstractions ■ Shorter code ■ Increased developer productivity ■ But these alone are not enough for mainstream adoption (after all FP has been around for 50 years) ■ Need a catalyzer, something that sparks initial adoption until the other advantages become clear to everyone. 17

A Catalyzer

A Catalyzer  Two forces driving software complexity: • Multicore (= parallel programming) • Cloud computing (= distributed programming)  Current languages and frameworks have trouble keeping up (locks/threads don’t scale)  Need better tools with the right level of abstraction 20

Concurrency and Parallelism

Concurrency and Parallelism Parallel programming Execute programs faster on parallel hardware. Concurrent programming Manage concurrent execution threads explicitly. Both are too hard! 21

The Root of The Problem

The Root of The Problem Non-determinism caused by var x = 0 concurrent threads accessing async { x = x + 1 } shared mutable state. async { x = x * 2 } It helps to encapsulate state in actors or transactions, but the fundamental // can give 0, 1, 2 problem stays the same. So, non-determinism = parallel processing + mutable state To get deterministic processing, avoid the mutable state! Avoiding mutable state means programming functionally. 22

Space vs Time

Space vs Time Space (functional/parallel) Time (imperative/concurrent) 23

The Essence of Functional Programming

The Essence of Functional Programming Concentrate on transformations of immutable values instead of stepwise modifications of mutable state. 24

Let’s see an example. A class ...

Let’s see an example. A class ... class Developer { public final String name; public final List commits; Developer(String name, List commits) { this.name = name; this.commits = commits; }} class Developer(val name: String,  val commits: Seq[Commit])

... and its usage

... and its usage ArrayList devs; ArrayList> longestCommits =  new ArrayList>(); for (Developer dev: devs) { Commit longestCommit = null int max = ‐1; for (Commit comm: dev.commits) { if (comm.length() > max) { max = comm.length(); longestCommit = comm; } } longestCommits.add(new Pair(dev, longestCommit)); } return longestCommits;

... and its usage

... and its usage ArrayList devs; ArrayList> longestCommits =  new ArrayList>(); for (Developer dev: devs) { Commit longestCommit = null int max = ‐1; for (Commit comm: dev.commits) { if (comm.length() > max) { max = comm.length(); longestCommit = comm; } } longestCommits.add(new Pair(dev, longestCommit)); } return longestCommits; val devs: Seq[Developer] devs map { dev =>  (dev, dev.commits.maxBy(_.length)) }

Simplify with for-expressions

Simplify with for-expressions ArrayList devs; ArrayList> longestCommits =  new ArrayList>(); for (Developer dev: devs) { Commit longestCommit = null int max = ‐1; for (Commit comm: dev.commits) { if (comm.length() > max) { max = comm.length(); longestCommit = comm; } } longestCommits.add(new Pair(dev, longestCommit)); } return longestCommits; val devs: Seq[Developer] for (dev <‐ devs) yield (dev, dev.commits.maxBy(_.length))

Going Parallel

Going Parallel ? val devs: Seq[Developer] for (dev <‐ devs.par) yield (dev, dev.commits.maxBy(_.length))

Another example: reactive programming

Another example: reactive programming Typical scenario: (blocking) 30

Another example: reactive programming

Another example: reactive programming Typical scenario: (blocking) 31

Another example: reactive programming

Another example: reactive programming Typical scenario: (non-blocking) 32

Another example: reactive programming

Another example: reactive programming Typical scenario: (non-blocking) 33

Another example: reactive programming

Another example: reactive programming Typical scenario: (parallel) 34

But what about Objects?

But what about Objects?  So, should we forget OO and all program in functional programming languages?  No!  Objects are about modularization.  Central question: What goes where?  In the end, need to put things somewhere, or risk unmanageable global namespace.  I still have to find a module system that’s as good as the best OO architectures. 35

Can Objects and Functions be Combined?

Can Objects and Functions be Combined? OOP FP How many OOP How many FP people see FP people see OOP Lot’s of misunderstandings in both communities 36

Would prefer it to be like this:

Would prefer it to be like this: But need to get rid of some baggage first 37

New Objects

New Objects Previously: “Objects are characterized by state, identity, and behavior.” (Booch) Now: Eliminate or reduce mutable state. Structural equality instead of reference identity. Concentrate on functionality (behavior) 38

Scala is a Unifier

Scala is a Unifier Agile, with lightweight syntax Object-Oriented Functional Safe and performant, with strong static typing

To find out more:

To find out more: ■ Tonight at 20.00: BoF of the Scala user group, auditorium ■ Tomorrow at 18.05: Gullaume Bort and Sadek Drobi: Web-Oriented Architecture in 50 minutes. ■ Starting this week: 2nd iteration of Coursera class. 40

To find out more:

To find out more: 41