Erik Meijer Says Java 8 Lambdas Copy Category Theory, Foresees Monads

Category Theory, The essence of interface-based design - Erik Meijer — FooCafe

FooCafe

Mainstream language designers delayed functional features for decades by avoiding mathematics, only to unconsciously replicate category theory's exponential objects in Java 8 and make monads structurally inevitable.

AI-assisted summary of Category Theory, The essence of interface-based design - Erik Meijer — original source. Check the original for full context.

Source published:

Key ideas

  • Erik Meijer argues that mainstream programming language features mirror mathematical discoveries made decades earlier, noting that Java 8 method references and lambdas precisely recreate the Cartesian closed categories formalized by Joachim Lambek and Alonzo Church. (0:00)
  • Software developers routinely practice category theory through interface-based design and the Curry-Howard isomorphism, where types act as theorems, programs serve as proofs, and category-theoretic objects and morphisms map directly to types and static methods. (8:14)
  • Instance methods do not exist at the fundamental machine or categorical level; as early as 1979 in C++ and in the JVM specification, instance methods are simply static functions where the instance reference 'this' is passed as the implicit first argument. (49:41)
  • Because Java 8 introduced exponential objects via method references (such as 'a::m' yielding a 'Function<B, C>'), it inherently incorporated categorical adjunctions, making monads like the State monad a structural inevitability in mainstream languages. (58:37)

Detailed notes

## Background Published by FooCafe on YouTube on September 10, 2015, this video features a presentation by Erik Meijer at Foo Café in Malmö/Lund. The session explores how category theory serves as the mathematician's interpretation of interface-based design, illustrating how modern object-oriented language features like Java 8 lambdas and method references embody Cartesian closed categories originally formalized decades ago by thinkers like Joachim Lambek.

## TL;DR Erik Meijer urges software developers to overcome their math aversion and actively borrow conceptual tools from category theory to improve their API design and careers. He systematically maps abstract mathematical constructs—categories, objects, morphisms, products, and functors—to everyday programming notions like languages, types, static methods, tuples, and generics. Meijer demonstrates that mainstream object-oriented mechanisms, such as Java 8 method references and instance method dispatch, are practical manifestations of categorical exponential objects and currying. Because exponential objects form adjoint functors, he concludes that the adoption of lambdas makes monads structurally inevitable in the future of mainstream programming languages.

## Atmosphere & style The presentation is lively, irreverent, and thoroughly engaging, driven by Meijer's animated delivery, self-deprecating humor, and sharp wit. Rather than delivering a dry academic lecture, Meijer constantly banters with the audience, cracking jokes about drinking beer, poking fun at purist Haskell programmers, and advising developers to use mathematical jargon to negotiate higher salaries. The atmosphere blends accessible technical intuition with intellectual enthusiasm, making dense categorical diagrams feel practical, approachable, and fun.

## Bulletin - [00:00](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=0s) Erik Meijer argues that mainstream programming language features mirror mathematical discoveries made decades earlier, noting that Java 8 method references and lambdas precisely recreate the Cartesian closed categories formalized by Joachim Lambek and Alonzo Church. - [08:14](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=494s) Software developers routinely practice category theory through interface-based design and the Curry-Howard isomorphism, where types act as theorems, programs serve as proofs, and category-theoretic objects and morphisms map directly to types and static methods. - [49:41](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=2981s) Instance methods do not exist at the fundamental machine or categorical level; as early as 1979 in C++ and in the JVM specification, instance methods are simply static functions where the instance reference 'this' is passed as the implicit first argument. - [58:37](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=3517s) Because Java 8 introduced exponential objects via method references (such as 'a::m' yielding a 'Function<B, C>'), it inherently incorporated categorical adjunctions, making monads like the State monad a structural inevitability in mainstream languages.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=0s) Language designers and developers frequently reinvent theoretical concepts decades late because they neglect deliberate continuous learning and avoid dense mathematical research. - [01:50](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=110s) Leslie Lamport advocates that software developers should embrace mathematics just as civil engineers and chemists do, rather than fearing it. - [04:44](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=284s) Developers are alienated by bottom-up mathematical pedagogy and obscure notation, whereas programming is effectively learned top-down through concrete problem-solving. - [08:14](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=494s) Category theory and interface-based design share the same core abstraction: studying the structural form of systems entirely decoupled from their underlying content. - [08:14](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=494s) Under the Curry-Howard isomorphism, types represent mathematical theorems and programs represent the constructive proofs of those theorems. - [08:14](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=494s) The core primitives of category theory map directly to software: a category corresponds to a programming language, objects correspond to types, and morphisms represent methods or functions. - [14:46](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=886s) Categorical products define compound types (tuples) equipped with projection functions and equational behavioral laws, which typical OOP interfaces fail to enforce. - [19:35](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=1175s) OOP interfaces only specify type signatures, leaving them vulnerable to trivial, broken implementations (such as returning null) that violate behavioral contracts. - [25:03](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=1503s) Alonzo Church formalised tuples in the lambda calculus in 1928 and John McCarthy built them in Lisp in 1960, yet mainstream languages like Java went decades without first-class tuple support. - [28:07](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=1687s) Object-oriented programming does not actually model the physical world; software deals purely with abstract in-memory data representations and mathematical structures. - [31:31](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=1891s) Reflection is an awkward meta-level workaround for treating methods as first-class values, a problem solved cleanly by Smalltalk blocks and category-theoretic exponentials. - [34:43](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=2083s) Categorical exponentials (Z^Y) represent function spaces based on combinatorics, though impure side effects in imperative languages break mathematical function counting. - [41:56](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=2516s) In typed languages, a functor is a generic type constructor equipped with a map operation that preserves identity and function composition. - [49:41](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=2981s) JVM bytecode demonstrates that instance methods are merely static procedures with the 'this' reference stored at local variable index zero. - [53:35](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=3215s) Java 8 method references (a::m) are direct implementations of category-theoretic exponential objects and evaluation morphisms. - [58:37](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=3517s) Currying and uncurrying represent the natural isomorphism between product morphisms Hom(X × Y, Z) and exponential morphisms Hom(X, Z^Y). - [58:37](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=3517s) Because exponential objects form adjoint functors, adopting them in Java 8 structurally guarantees that monads will inevitably become explicit in mainstream OOP languages.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=0s) Celebrating Foo Café and Joachim Lambek

Erik Meijer opens the session celebrating the three-year anniversary of Foo Café alongside a tribute to mathematician Joachim Lambek. Lambek is celebrated among category theorists for establishing the fundamental connection between the lambda calculus and category theory. Meijer jokingly points out the uncanny coincidence in their naming: “funnily his name kind of you know has the same prefix as the lambda calculus, isn't that a coincidence I don't know.”

Framing the evening under the theme of deliberate and continuous learning, Meijer polls the audience on who is running Java 8 versus older releases like Java 6. Seeing the divide, he notes how many years it dragged on before Java introduced lambda expressions. He argues that if programming language designers practiced deliberate and continuous learning, these features would have arrived decades earlier, because researchers like Lambek had already laid down the theoretical foundations. His goal for the talk is practical and mercenary: “tonight I'm going to tell you the tricks how you as a developer can tap into the brains of mathematicians and kind of steal their ideas such that you know you can kind become a better developer and then go to your boss and ask for more money because you're an awesome developer.”

[01:50](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=110s) The Pain of Language Specs and Leslie Lamport's Advice

Meijer confesses to an unusual hobby: reading programming language specifications cover to cover. While other people read novels or newspapers, he collected manuals stretching back through early Lisp 1.0, Pascal, Visual Basic, C#, ECMAScript, Swift, and Dart. Yet, despite his high tolerance for dense specifications, Java 8 broke him: “there's one language specification that even for me was too strong it was impossible to read and that language specification is Java 8.” He jokes that if you suffer from insomnia, opening the Java Language Specification works better than any sleeping pill. The complexity surrounding Java 8's method references, in particular, proved unnecessarily opaque.

When faced with overwhelming engineering complexity, Meijer turns to the philosophy of Turing Award winner Leslie Lamport. Lamport advocates that software developers ought to incorporate more mathematics into their everyday thinking. While mechanical and civil engineers routinely rely on math to build bridges, and chemists lean on it daily, software engineers remain strangely math-averse. Meijer insists developers must shed that fear.

```mermaid flowchart LR accTitle: Lamport's Prescription for Software accDescr: Comparing how traditional engineering fields use math versus computer science. subgraph Traditional["Traditional Engineering"] CE["Civil Engineers\n(Bridges)"] --> M1["Use Mathematics"] CH["Chemists\n(Reactions)"] --> M1 end subgraph Computing["Computer Science"] SE["Software Developers"] -.->|"Fear / Avoid"| M2["Mathematics"] LL["Leslie Lamport's Advice"] ==>|"Prescribes"| SE SE ==>|"Must Embrace"| M2 end ```

[04:44](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=284s) Why Developers Fear Mathematics: The Pedagogy Problem

Meijer breaks down why software engineers are intimidated by mathematics, validating that their reservations stem from real systemic flaws in how math is communicated and taught:

- Math textbooks are notoriously poor; the notation is obscure and “doesn't even type check.” - The jargon and terminology are alienating, quickly dragging the reader down a rabbit hole filled with “Greek symbols and other dirty pictures.” - Math is almost exclusively taught bottom-up: students must digest endless abstract machinery before ever getting to see a concrete application.

By contrast, programming is taught top-down. Polling the audience reveals that only about half hold a formal computer science degree. Those without a degree never started by grinding Big-O notation or Turing machines; they opened an editor, began hacking to solve an immediate problem, and acquired theory on a need-to-know basis as they ran into deeper challenges.

Meijer illustrates this pedagogical failure with linear algebra. Most university courses introduce linear algebra through the mechanical, tedious manipulation and multiplication of matrices for graphics. Yet at its conceptual core, an $m \times n$ matrix is simply the concrete data representation of a linear function mapping a sequence of length $n$ to a sequence of length $m$, and matrix multiplication is nothing other than standard function composition. He laments that students are forced to write the equivalent of raw assembly: “This is completely nonsense that we as humans have to do that if instead they would teach linear algebra as a restricted form of functional programming with some special functions that are linear which means that they have nice properties everything would be easy.” Because mathematicians insist on bottom-up explanations, developers are left scratching their heads wondering why any of it matters.

[08:14](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=494s) Abstract Nonsense, Interface-Based Design, and Curry-Howard

Even professional mathematicians look at category theory and jokingly dismiss it as "abstract nonsense." This label exists because proofs within category theory operate at extreme altitude, described formally as: “the study of the general form of mathematical theories without regard to their content.” In this realm, concrete intuition is deliberately stripped away in favor of skeletal form.

Meijer contends that software developers already practice this exact mindset every day through interface-based design: - When writing code against an abstract interface rather than a concrete implementation class, developers program “without regard to their content.” - The identical calling program works unaltered regardless of which concrete type is supplied underneath. - Software design patterns function in the exact same abstract manner; few people actually read the *Design Patterns* book cover-to-cover because its patterns are completely decoupled from specific business logic, existing instead as general reusable structural templates.

```mermaid flowchart TD accTitle: Correspondence between Math and Programming Concepts accDescr: Mapping abstract category theory concepts directly to everyday object-oriented software practices. subgraph MathTheory["Mathematical Abstraction"] ABS["Study form without content"] THM["Theorems"] PRF["Proofs"] CAT["Category"] end subgraph SoftwarePractice["Software Engineering"] INT["Interfaces & Design Patterns"] TYP["Types"] PRG["Programs / Code"] LAN["Programming Language"] end ABS <-->|"Isomorphism"| INT THM <-->|"Curry-Howard"| TYP PRF <-->|"Curry-Howard"| PRG CAT <-->|"Direct Analogy"| LAN ```

Meijer connects this directly to proof theory via the Curry-Howard isomorphism, which he describes as one of the most elegant concepts in computing: “Curry-Howard isomorphism says that a type is a theorem and the program is the proof for that theorem.” Under this lens, developers writing code are continually constructing proofs of mathematical theorems, meaning developers and mathematicians are engaged in the same discipline—except mathematicians simply program far more slowly, sometimes spending decades to produce a tiny proof.

Moving toward category theory itself, Meijer demystifies its intimidating reputation, stating that the entire system is built upon three remarkably simple building blocks: - A **Category**, which directly corresponds to an entire **Programming Language**. - **Objects**, which directly correspond to the language's **Types** (such as booleans, strings, and lists in Java). - **Morphisms**, which represent the arrows, functions, and transformations connecting those types.

[12:52](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=772s) Morphisms as Static Methods and the Language Bold 3

Erik Meijer clarifies that the mathematical term *morphism* is just an unnecessarily fancy name for a concept everyday programmers already know: “a morphism from A to B is just a static method that takes a argument of type A and returns a value of type B or equivalently you can say it's a property.” A developer might naturally object: if this is meant to model modern object-oriented programming, why restrict the definition to static methods instead of instance methods? Meijer notes that while instance methods will be addressed later, the foundational goal of the talk is to establish precision, pinning down the mathematical machinery so that category-theoretic concepts map directly to concrete language features.

```mermaid flowchart LR accTitle: Category Bold 3 Schema accDescr: Three types A, B, and C with arrows representing functions between them. subgraph Bold3["Category / Language: 3"] A["Type A (e.g. Character)"] B["Type B (e.g. Integer)"] C["Type C (e.g. Boolean)"] C -->|"f"| A A -->|"g"| A end ```

To demonstrate how mathematicians operate, Meijer points out that they resemble exceptionally slow programmers. He presents a toy category known in mathematics as the category **3** (or "bold three"). It represents a tiny programming language consisting of exactly three types—conceptually analogous to characters, integers, and booleans—and a few defined functions running between them, such as a function from booleans to characters, or a function from characters back to characters. For category theorists, a construct as minimal as three types and a couple of arrows is so monumental that they publish papers on it and give it a dedicated name. Meijer jokes that if someone tried to draw the equivalent full graph for all the types and methods in Java, the diagram would spill off the slides, cover all the walls of the venue, and fill the entire city like a massive graffiti art installation. Yet mathematicians take pride in fully understanding their tiny three-type world.

[14:46](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=886s) Tuples, Category-Theoretic Products, and Android Libraries

Once a language has basic types, developers invariably want to combine them into compound types. In modern programming, practically everyone demands tuples. Java itself lacks built-in language support for tuples, forcing developers to rely on third-party libraries. Meijer asks the audience if anyone develops for Android (or perhaps Windows Phone), noting that the standard Android SDK explicitly includes a tuple utility type because tuple pairs are essential even on a mobile phone.

He then displays the standard category-theoretic definition of a product: a formal definition heavy with phrases like "commuting diagrams," "canonical morphisms," and "universal properties." Anticipating the audience's dread, Meijer jokes, “you will ask yourself oh my goodness where's my beer the next beer this looks kind of horrible.” To demystify the intimidating Greek symbols and formal terminology, he breaks the text down clause by clause into ordinary programming concepts: - A category $C$ corresponds to a programming language. - Objects $X_1$ and $X_2$ correspond to types. Meijer specifically prefers the word "types" rather than "objects" to avoid ambiguity, because in object-oriented programming people constantly conflate classes, types, and object instances. - Forming a product $X_1 \times X_2$ corresponds to creating a tuple type `(X1, X2)` or a pair.

```mermaid flowchart TD accTitle: Universal Property of a Category Product accDescr: Commuting diagram showing projections pi 1 and pi 2 from product X to objects X1 and X2, along with morphisms f and g from an arbitrary object C factored through a unique pair morphism. C["Source Object / Type: C"] Prod["Product Type: X (X1 × X2)"] X1["Type: X1"] X2["Type: X2"]

Prod -->|"π₁ (fst / _1)"| X1 Prod -->|"π₂ (snd / _2)"| X2 C -->|"f"| X1 C -->|"g"| X2 C -->|"<f, g>"| Prod ```

In category theory, a product comes equipped with two projection morphisms, $\pi_1$ and $\pi_2$, which extract the first and second elements from the compound type. Meijer quips that mathematicians start their projection indexing at 1 rather than 0 because they have probably never written a line of C code in their lives. Crucially, mathematicians also recognize that a type must have a way to be created: what developers call a constructor or factory function. In the diagram, given any source type $C$ with two functions $f: C \to X_1$ and $g: C \to X_2$, there is a unique mediating morphism (written as $\langle f, g \rangle$) from $C$ into $X_1 \times X_2$. Commutativity simply means that mapping an input through the constructed tuple function and then taking the first projection yields the exact same result as applying $f$ directly.

[19:35](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=1175s) The Incompleteness of OOP Interfaces vs. Mathematical Rigor

Meijer engages an audience member—whom he humorously dubs "Mr. Generic" after struggling to pronounce his name—who already grasps the categorical formalism. For the rest of the audience, Meijer maps the categorical product directly to Scala's tuple implementation: the projection functions $\pi_1$ and $\pi_2$ correspond to Scala's `_1` and `_2` methods. The factory operator takes two functions $f$ and $g$ and yields a function that maps an input value $c$ to a pair `(f(c), g(c))`.

Comparing the mathematical formulation to Scala's standard library `Product2` trait, Meijer argues that the mathematics is actually far cleaner and more concise: - Scala's definition is cluttered with boilerplate: `trait Product2[+T1, +T2] extends Product`, abstract field declarations, and type variance annotations (`+T1`, `+T2`) representing covariance and contravariance, which he waves off as far too complicated for the current point. - Standard Scala lacks the categorical pair-construction combinator at the type level because implementing it directly would require functions to be treated as first-class objects within the category itself—the exact problem Martin Odersky had to navigate and the core subject of the lecture.

Beyond verbosity, Meijer emphasizes a critical difference between an object-oriented interface and a mathematical specification: “the nice thing that they do that we never do is when they Define a type they talk about properties of the type what properties should a product Define have because if you look at this definition in Scala right from here it says nowhere that when you create a topple out of two values and you project from that topple the first value that you actually get the value that you put in there right nothing says this here.”

In Scala or Java, a malicious or lazy programmer could satisfy the compiler by implementing `_1` and `_2` to always return `null`. The code compiles and adheres strictly to the interface signature. Meijer jokingly advises the developers in the room to do just that: implement traits by returning `null`, and when colleagues file bug reports, immediately reject the tickets with the retort that the specification failed to state the required behavioral properties. While they scramble to write better specs, one can take a break, grab a beer, sit in meetings, add the work to a resume, and negotiate a higher salary. In contrast, categorical diagrams enforce behavior through equational laws (such as $\pi_1 \circ \langle f, g \rangle = f$), ensuring that getters actually retrieve what was put in.

[25:03](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=1503s) A Century of Delay: Stealing from Church and McCarthy

Meijer points out that these ideas are far from novel. John McCarthy defined tuples, pairs, and list-processing primitives in Lisp back in 1960. Going even further back, Alonzo Church formalized tuple encodings in the pure lambda calculus in 1928:

```mermaid flowchart LR accTitle: Timeline of Tuple Formalization accDescr: Chronological timeline highlighting Alonzo Church in 1928, John McCarthy in 1960, and Java 8 in 2015 still lacking native tuples. T1["1928: Alonzo Church (Lambda Calculus)"] T2["1960: John McCarthy (Lisp Pairs)"] T3["2015: Java 8 (Still lacks built-in tuples)"]

T1 --> T2 --> T3 ```

Meijer expresses exasperation that despite nearly a century passing between Alonzo Church's 1928 papers and Java 8's release in 2015, mainstream languages like Java still lack first-class, built-in tuple support: “Look this guy here came up with this in 1928 if you read the papers from Church he was doing this kind of toples in Java 8 it's 2015 last time I checked there are still no proper toples in the language.”

He diagnoses the root cause of this lag: mainstream developers and language designers are intimidated by mathematicians and their notation, choosing to ignore them instead of taking advantage of their findings. Showing a portrait of Church, Meijer gestures to the massive forehead and head size, remarking that Church's brain was ten times the size of an average programmer's. Software engineers should overcome their fear, exploit the massive intellectual groundwork category theorists and logicians laid decades ago, and steal their ideas directly into modern programming language design.

[26:29](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=1589s) The Debate Over Lambdas and Staying Humble Before Theory

Erik Meijer points out that developers often take pride in ignoring theory. When C# introduced delegates, the attitude was that formal theory was unnecessary. When C# emerged, a dispute broke out between the C# and Java camps. The Java camp insisted they had no need for lambdas or delegates because they already had virtual methods. Meijer notes that this history teaches an enduring lesson: “Never say never.” Because James Gosling publicly declared that lambdas were unnecessary, Sun and Oracle could not easily reverse course without losing face. Meijer jokes that Gosling first had to retire, move through companies like Google, and work on self-driving cars at Stanford before Java could finally introduce lambdas and method references in Java 8.

Beyond office politics and language rivalries, Meijer cautions developers against arrogance toward theoretical computer science and mathematics. Rather than downplaying mathematics, engineers should remain open to ideas that have already been rigorously explored decades prior.

> “You should always stay humble and hungry. You always always want to learn. If these mathematicians come up with something, you know, but you better have a look at it because maybe it's something that you can use.” — Erik Meijer

[28:07](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=1687s) Debunking the Myth that Objects Model the "Real World"

Meijer tackles the classic object-oriented dogma that objects exist to model real-world concepts like customers and orders. While developers are forced to write such business logic in their day jobs, the core constructs programmers actually enjoy working with are abstract data structures like lists and trees. Meijer observes that real-world trees bear no resemblance to trees in source code, and physical lists on a refrigerator never get garbage collected or completed the way lists in memory do. The belief that object-oriented programming is fundamentally about mirroring the physical world is, in his view, completely unfounded.

To reinforce this, Meijer references Eiffel creator Bertrand Meyer, noting that even an object modeling a person is merely a set of bits in memory, making it at least twice removed from reality. Because real-world modeling is an illusion, code should be treated with the same formal mathematical rigor applied to abstract mathematical objects.

Furthermore, programmers suffer when they fail to formalize types and contracts. Without precise mathematical properties, an uncooperative colleague can write a method that simply returns `null` and claim the interface contract is satisfied because the properties were never formally pinned down.

- Developers spend their day jobs on "boring" domains like customers and orders, but computer science itself centers on formal data structures. - Bertrand Meyer's philosophy underscores that in-memory data representations are inherently disconnected from physical entities. - Without property-based formal definitions on types, implementations can trivially meet type signatures (e.g., returning `null`) while violating operational intent.

[31:31](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=1891s) Reflection, Smalltalk Blocks, and Dijkstra's Zero-Based Indexing

Before category theory provided the foundation for functional interfaces, programming languages attempted to treat methods as objects via reflection. In Java, reflection lets a program inspect class types, retrieve methods, and invoke them dynamically. Meijer remarks that reflection is intellectually fascinating—writing software that can reason about its own behavior is something even human beings struggle to do when acting foolishly after a night out. However, reflection is ultimately an awkward "cop-out" because reflective method representations operate in an artificial meta-level rather than as ordinary, first-class language objects.

This desire to treat methods as values was solved decades earlier. Dave Thomas and the Smalltalk community had already embraced "blocks," which reified methods as first-class objects despite Smalltalk’s heavy emphasis on real-world anthropomorphic messaging. Meijer jokes that he cannot talk too much about Smalltalk because its arrays start at index one, which is unacceptable to any Dutch computer scientist. He cites Edsger W. Dijkstra's argument for zero-based indexing, illustrating how Dijkstra counted his handwritten manuscripts by starting with the state of having zero pages before adding the first.

```mermaid flowchart TD accTitle: Approaches to Reifying Methods as First-Class Objects accDescr: Diagram contrasting reflection as a meta-level cop-out against first-class reifications like Smalltalk blocks and Java 8 lambdas.

subgraph MetaApproach["Meta-Level Approach"] Reflect["Reflection / Class Inspection"] Reflect -->|"indirect invocation"| MetaInvoke["Method.invoke(...)"] end

subgraph DirectApproach["First-Class Value Approach"] Smalltalk["Smalltalk Blocks"] JavaLambda["Java 8 Lambdas / Method References"] MathExp["Category Theory: Exponentials (Z^Y)"] end

Reflect -.->|"criticized as cop-out"| DirectApproach ```

[34:43](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=2083s) Exponentials and Function Counting: Math vs. Java

Turning back to category theory, Meijer explains how category theorists formalize methods as objects using the concept of **exponentials**. When examining academic slides packed with Greek symbols and diagrams, one encounters the notation $Z^Y$ (or $Z$ to the power of $Y$) to denote a function from $Y$ to $Z$. The notation stems from basic combinatorics: given finite sets, the number of distinct mathematical functions from a domain $Y$ to a codomain $Z$ is precisely $|Z|^{|Y|}$.

To make this intuitive, Meijer walks through basic set sizes: - A function from `Unit` (a single-value type, size 1) to `Boolean` (size 2) yields $2^1 = 2$ possible functions: one returning `true`, and one returning `false`. - A function from `Boolean` (size 2) to `Unit` (size 1) yields $1^2 = 1$ possible function: mapping both inputs to `unit`.

Meijer points out that this clean counting argument breaks down completely in languages like Java. A Java method with the signature `Boolean -> void` does not have just one implementation; it can perform arbitrary console logging via `println`, execute network I/O over HTTP, or trigger reflection. In impure imperative languages, hidden contexts and side effects violate the clean semantics of mathematical functions. Meijer spots a smiling Haskell programmer in the audience and contrasts Java's leaky abstraction with pure functional languages where functions truly mirror mathematical mappings.

[39:37](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=2377s) Mr. Haskell and Escaping the Rabbit Hole

Erik Meijer opens with a humorous jab at the functional programming purist, dubbed “Mr. H” (Mr. Haskell), whose code ends up being roughly ten times longer than typical Java code by the time he finishes wiring together all his monads. Having such a colleague can be advantageous, Meijer jokes, because you can learn from him, write practical code implicitly, and move on with your career while he is trapped overcomplicating things:

> “And by the time he has figured out how to compose all these monads you’re already here at Foo Café listening to your next talk that you can put on your resume and you get ahead isn’t that great?”

Turning back to category theory, Meijer strips away the dense mathematical symbols and translates the concepts into plain programming terminology. Assume a programming language $L$ that supports tuples, with types $A$ and $B$. A function $A \to B$ can then be characterized via a factory method derived from a functor. However, explaining this introduces the concept of a functor itself. Meijer warns that checking Wikipedia for a definition usually plunges developers straight down another intimidating rabbit hole of Greek letters and abstract definitions.

[41:56](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=2516s) Functors, Java Generics, and the Laws of Mapping

Decoding the formal mathematics into standard programming language concepts, a functor in a typed language is simply a generic type constructor. In Java, generics were introduced back in Java 5 (which Meijer quips has already been a long time, despite Java generics having irritating limitations, such as only permitting reference types and not primitive types like `int`). A functor associates every type $A$ with a new type $C\langle A\rangle$. For example, `List<T>` is a functor because it can be instantiated with another type, such as `Integer`.

```mermaid flowchart LR accTitle: Functor Mapping Flow accDescr: Diagram showing how a functor maps a function between types A and B to a function between C of A and C of B. subgraph BaseTypes["Underlying Types"] A["Type A (e.g., Integer)"] -->|"f (e.g., toString)"| B["Type B (e.g., String)"] end subgraph FunctorTypes["Functor Types C<T>"] CA["C<A> (e.g., List<Integer>)"] -->|"map(f)"| CB["C<B> (e.g., List<String>)"] end ```

Crucially, a functor must provide a `map` operation. If a function exists from $A \to B$ (such as `toString` converting an integer to a string), `map` lifts that function so it can transform $C\langle A\rangle$ into $C\langle B\rangle$ (converting a `List<Integer>` into a `List<String>`). Beyond just having a `map` method, category theory demands that it obey two strict algebraic laws: 1. **Identity preservation:** Mapping the identity function over a container (doing nothing to each element) must return the original container unchanged. 2. **Composition preservation:** Applying `map(f)` followed by `map(g)` must yield the exact same result as mapping the combined function `map(g. f)`.

Meijer highlights that category theorists are secretly efficiency freaks: this composition law is an optimization trick that fuses pipeline stages, avoiding the creation of wasteful intermediate data structures (such as creating an intermediate list of strings just to measure their lengths).

- While category theorists view `map` as an essential law that must accompany generic types, conventional object-oriented languages neglected this for decades; Java only finally introduced a standard `map` method on `Stream` in Java 8. - From a foundational category theory perspective, a functor maps between two distinct categories (which can be thought of as two distinct programming languages, like adapting between 0-indexed Java arrays and 1-indexed Smalltalk arrays). - An **endofunctor** is simply a functor that maps a category back to itself (staying entirely within a single programming language).

[47:34](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=2854s) Functions as First-Class Objects and Currying

Meijer notes that he had to cheat slightly when defining `map`: the operation inherently requires being able to pass a function as an argument. Prior to Java 8, Java lacked first-class lambdas, making it impossible to define `map` cleanly.

Looking at the formal Cartesian closed category diagrams from mathematicians like Joachim Lambek, one sees an evaluation morphism `eval` and an exponential object representing function spaces. Functional programmers immediately recognize this categorical apparatus:

> “And of course Church or this is Haskell B. Curry will say, ‘Oh, but this is currying in Haskell!’”

While Haskell developers were accustomed to currying and higher-order functions since the late 1980s, the mainstream object-oriented world lagged behind, with many enterprises still running ancient Java versions like Java 6.

[49:41](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=2981s) Why Instance Methods Do Not Exist

Meijer returns to his earlier simplification of treating all methods strictly as static morphisms, citing Bjarne Stroustrup to justify doing away with instance methods entirely. As early as 1979, Stroustrup pointed out that an instance method is merely a static function that takes the `this` pointer as an explicit extra argument tupled with the method's other parameters. Today, even C++ includes lambdas, demonstrating that virtually every mainstream modern programming language has finally adopted first-class functions after decades of resisting mathematical foundations.

To prove this is not just a C++ design quirk, Meijer turns to the official Java Virtual Machine Specification:

> “So if you want to have an even more boring document than the Java Language Specification, you should read the Java Virtual Machine Specification.”

In the JVM specification, when executing any instance method or class method, local variable 0 is always reserved for the reference to the instance (`this`), while user-passed parameters populate subsequent local variables starting at index 1. At the execution level, Java also has no real instance methods—only static procedures whose initial parameter is `this`.

Meijer concludes by acknowledging the elephant in the room that object-oriented programmers often raise: inheritance. While dogmatists preach "favor composition over inheritance" (to which Meijer jokingly advises making those colleagues look bad and getting them fired), inheritance is fundamentally a dirty, pragmatic implementation trick designed for code reuse via virtual tables (v-tables). Formalizing the semantics of inheritance mathematically is notoriously difficult, having formed the basis of entire doctoral dissertations, such as the seminal work by William Cook.

[53:35](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=3215s) Decoding the Greek: Method References as Exponential Objects

Erik Meijer moves past inheritance to continue "decoding the Greek" mathematical formalism of category theory into something programmers can actually grasp. Rather than dwelling on impenetrable notations involving exponential superscripts and abstract lambda binders—which he jokes would put everyone straight to sleep after eating hot dogs and hamburgers—he translates the concept directly into modern object-oriented programming. In Java terms, a function type paired with an `apply` method is defined relative to an arbitrary type `A` and a method `m` that takes an argument of type `B` and yields a return type `C`. Under the hood, defining a method on `A` really means `m` has `A` as its first implicit parameter and `B` as its second.

```mermaid flowchart LR accTitle: Method Reference as Exponential Object accDescr: Diagram illustrating how an instance method corresponds to an exponential object factory returning an apply method. subgraph OO["Object-Oriented View"] direction TB M["Method on A:<br/>a.m(b): C"] end subgraph CT["Exponential Object Translation"] direction TB FR["Factory Method:<br/>a::m returns Function&lt;B, C&gt;"] APP["apply(b)"] FR --> APP end M <-->|"Isomorphic"| FR APP -->|"Evaluates to"| RES["Same as a.m(b)"] ```

From this perspective, a factory method written with the double-colon syntax (`::m`) accepts an instance of `A` and produces a function object of type `Function<B, C>`. That resulting function object exposes an `apply` method such that invoking `apply(b)` produces the exact same result as calling `a.m(b)` directly. Meijer polls the audience to see who uses IntelliJ IDEA and notices how aggressively the IDE prompts developers to refactor lambdas into method references. When an attendee named Paul confirms he frequently accepts this refactoring suggestion, Meijer jokes that Paul can now march into work and demand a substantial raise:

> “So now you can go to your boss and say in Foo Café I learned that I'm freaking using exponential objects from category theory in my coding; I need a raise because that son of a next to me has no clue what they're doing—they're still using whatever virtual methods, but I know exponential objects.”

The deeper revelation for Meijer is that Java's designers ended up building exact categorical structures without realizing it. He asserts that Java language architects likely had zero formal category theory in mind when designing Java 8, yet arrived at the exact same mathematical formulation:

> “I'm 100% sure that the Java language designers had no idea of category theory, but yet they came up with exactly the same solution; that is the amazing thing.”

Because two completely independent groups—pure theorists decades earlier and pragmatic language designers solving developer ergonomics—converged on the identical construct, it signals the existence of an underlying universal truth in computer science.

- Java method reference syntax (`::m`) acts as the constructor/factory for the categorical exponential object. - Calling `(a::m).apply(b)` is strictly equivalent to calling `a.m(b)`. - The convergence of category theory and Java 8 method references reflects foundational mathematical laws emerging naturally in software engineering.

---

[58:37](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=3517s) Hom-sets, Adjunctions, and the Inevitability of Monads

Meijer addresses the elephant in the room: he hasn't yet uttered the notorious "M-word"—monads. Returning to the underlying category theory, he explains the machinery connecting exponential objects to adjunctions and hom-sets. He jokes that a "hom-set" sounds like fish eggs (clarifying in Dutch that "kuit" or "hom" refers to fish roe/caviar), but in reality, $\operatorname{Hom}(A, B)$ simply denotes the set of all morphisms from object $A$ to object $B$.

In categorical terminology, the relationship governing exponential objects states that a morphism from a product $X \times Y \to Z$ is naturally isomorphic to a morphism $X \to Z^Y$. In programming, this is nothing more than currying and uncurrying: transforming a function taking two arguments into a higher-order function taking one argument that returns another function. The method reference conversion is precisely this isomorphism, transforming a lambda expression `b -> a.m(b)` into the curried method reference `a::m`.

Meijer shows executable Scala code to prove this is not merely abstract theory, illustrating how exponential objects form a pair of adjoint functors. Crucially, any pair of adjoint functors canonically gives rise to a monad. Because Java 8 adopted exponential objects via lambdas and method references, it implicitly adopted adjunctions, making full-blown monads structurally inevitable in future versions of the language:

> “Java will have monads because monads are related to adjunctions, and adjunctions come from exponentials.”

He notes that the classic State monad arises directly from this exact product-exponential adjunction, though he defers that full demonstration to a future talk.

- $\operatorname{Hom}(A, B)$ is just mathematical vocabulary for the collection of all functions/morphisms between types $A$ and $B$. - Currying and uncurrying represent the natural isomorphism between $\operatorname{Hom}(X \times Y, Z)$ and $\operatorname{Hom}(X, Z^Y)$. - Every categorical adjunction generates a monad; specifically, the product-exponential adjunction generates the State monad. - Meijer predicts that within 10 to 20 years, mainstream languages like Java will fully embrace explicit monads as a consequence of adopting exponentials.

---

[01:02:22](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=3742s) Commemorating the Theory: Tattoos and Closing Remarks

Wrapping up the evening at Foo Café, Meijer quips that after consuming plenty of beer during the meetup, attendees are properly primed to head out and get permanent ink. He displays two sample tattoo designs on his slides: one rendering the rigorous category theory commutative diagram and its direct correspondence to Java constructs, and a second, lighter alternative for those who find the first option too intimidating.

With a laugh, he tells the audience that he negotiated an exclusive arrangement with a local tattoo shop:

> “I made a special deal with Liz's tattoo parlor where if you show your Foo Café t-shirt, you will get a discount on any of those two tattoos.”

The presentation ends on this humorous high note, met with enthusiastic applause from the audience.

## Notable quotes > [58:37](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=3517s) Java will have monads because monads are related to adjunctions, and adjunctions come from exponentials. — Erik Meijer

> [08:14](https://www.youtube.com/watch?v=JMP6gI5mLHc&t=494s) Curry-Howard isomorphism says that a type is a theorem and the program is the proof for that theorem. — Erik Meijer

## Mentioned Erik Meijer, Joachim Lambek, Leslie Lamport, Alonzo Church, John McCarthy, James Gosling, Bertrand Meyer, Dave Thomas, Edsger W. Dijkstra, Martin Odersky, Haskell B. Curry, Bjarne Stroustrup, William Cook, Foo Café, Java, Java 8, Scala, Smalltalk, Haskell, C#, C++, Lisp, IntelliJ IDEA, Android, JVM Specification, Java Language Specification

## Video description Category Theory is the Mathematicians' interpretation of interface-based design, so whenever you hack together a new API in your favourite OO language, it is always a smart idea to ask the question x -LT "What would x do?" applied to the Category Theorist that worked on your same problem already decades ago. Since lambda expressions are the new hot topic all across programming language land these days, we will invoke our question of conscience with "Joachim Lambek" and learn that Java 8 lambdas and method references are simply a Cartesian Closed Category, proving yet again that interfaces are the OO developers' interpretation of Category Theory.

Foo Café is an independent and physical meeting place for people of all backgrounds and expertise within the IT-industry in the Malmö/Lund region. Foo Café is aimed at those interested in sharing, learning and creating. Join the fun at foocafe.org

[Source](https://www.youtube.com/watch?v=JMP6gI5mLHc)

中文简报

Erik Meijer:Java 8 Lambda 照搬范畴论,预言 Monad 势在必行 主流语言设计者因回避数学而将函数式特性推迟了数十年,却在 Java 8 中无意识地重现了范畴论的指数对象,使 Monad 在结构上成为必然。 Erik Meijer 呼吁软件开发者克服对数学的排斥,积极借用范畴论的概念工具来提升 API 设计水平与职业发展。他将抽象的数学构造(范畴、对象、态射、乘积和函子)系统性地映射到日常编程概念(语言、类型、静态方法、元组和泛型)。Meijer 指出,诸如 Java 8 方法引用和实例方法分派等主流面向对象机制,本质上是范畴论中指数对象和柯里化(currying)的实际体现。由于指数对象构成了伴随函子,他得出结论:Lambda 的引入使 Monad 成为未来主流编程语言中结构上的必然产物。 Erik Meijer 认为主流编程语言的特性映射了数十年前的数学发现,并指出 Java 8 的方法引用和 Lambda 精确重现了 Joachim Lambek 和 Alonzo Church 形式化的笛卡尔闭范畴。 (0:00) 软件开发者日常通过基于接口的设计以及柯里-霍华德同构(Curry-Howard isomorphism)实践着范畴论:其中类型充当定理,程序作为证明,而范畴论中的对象和态射则直接映射到类型和静态方法。 (8:14) 在机器底层或范畴层面并不存在实例方法;早在 1979 年的 C++ 以及 JVM 规范中,实例方法都只不过是将实例引用 'this' 作为隐式第一个参数传入的静态函数。 (49:41) 由于 Java 8 通过方法引用引入了指数对象(例如 'a::m' 生成 'Function<B, C>'),它本质上吸纳了范畴伴随,使得像 State monad 这样的 Monad 在主流语言中成为结构上的必然。 (58:37)

Source quotes

[58:37] Erik Meijer: Java will have monads because monads are related to adjunctions, and adjunctions come from exponentials. [8:14] Erik Meijer: Curry-Howard isomorphism says that a type is a theorem and the program is the proof for that theorem.

Original transcript

[0:00] [Music] [0:04] [Applause] [0:13] what we're going to do uh tonight is to [0:15] celebrate of course the um three-year [0:18] anniversary of [0:20] fuka um and also um we're going to give [0:23] a tribute to uh Yim lbeck um who is a [0:28] kind of category theorist that kind of [0:30] made the connection between uh the [0:32] Lambda calculus and category Theory and [0:35] finnally his name kind of you know has [0:37] the same prefix as a Lambda calculus [0:39] that isn't that a coincidence I don't [0:41] know um but anyway so in just in the [0:45] spirit of deliberate and continuous [0:47] learning um you know like who here uses [0:52] Java [0:53] 8 a few people who here uses Java [0:57] 6 a few people that's well so it has [1:01] taken like many many years before Java 6 [1:05] became Java 8 and added lambdas now if [1:09] the um language designers would have [1:13] practiced deliberate and continuous [1:15] learning it would have happened like you [1:17] know decades ago because all this [1:19] knowledge was already developed by [1:22] people like lumc um and tonight I'm [1:25] going to tell you the tricks how you as [1:28] a developer can tap into the brains of [1:32] mathematicians and kind of steal their [1:34] ideas such that you know you can kind [1:37] become a better developer and then go to [1:39] your boss and ask for more money because [1:42] you're an awesome [1:43] developer all right let's get started [1:48] oops [1:50] um so one of my guilty pleasures is I uh [1:54] read language specification so some of [1:57] you kind of you know might read novels [2:00] or newspapers maybe I read language [2:03] specifications and for a while I was [2:05] collecting them I had a whole bunch of [2:08] you know going all the way back to you [2:10] know the early lisp 1.0 manual Pascal [2:15] everything so and whenever there was a [2:17] new language I would read the language [2:19] manual so I read all of them Visual [2:24] Basic C ecmascript Swift Dart you name [2:28] it but there's one one language [2:32] specification that even for me was too [2:35] strong it was impossible to read and [2:38] that language specification is Java [2:42] 8 um now I don't know anyone has anyone [2:47] here ever looked at the Java language [2:51] specification okay did you fall asleep [2:53] immediately I mean you open up this [2:55] thing and you fall asleep I mean it's [2:56] like yeah try it you know some you know [2:59] you kind of cannot sleep at night your [3:01] kind of mind is wondering just open that [3:03] thing up it will work better than any [3:06] pill um and this one in particular is [3:10] really weird so um when Java 8 came out [3:13] and there's this kind of weird thing [3:14] with method references so I thought I [3:17] really want to understand this so I [3:19] started to read the the the language spe [3:23] but it doesn't my my goodness it's just [3:27] way too complicated so [3:31] what do I do when something is [3:33] complicated I I'm always uh listen to [3:38] this guy this is Leslie Lamport and he [3:41] won the touring award last year okay [3:45] well if you win the touring award well [3:47] that is means something and one of the [3:50] uh kind of advice that Lamport gives us [3:54] is that we should kind of do more math [3:57] we should use more math if you're um [4:00] like a mechanical engineer you build or [4:02] like a civil engineer you build a bridge [4:04] or something you use math okay if you're [4:08] a chemist you use math but we as [4:11] computer scientists seem to be afraid of [4:14] mathematics and what Lamport says and [4:16] what I will tell you is you shouldn't be [4:19] afraid and I think a lot of people here [4:24] um I don't know maybe you know in Sweden [4:27] it's different uh you're not a afraid of [4:30] math you know you instead of language [4:32] specifications you read like books on [4:34] calculus before you go to bed I'm pretty [4:36] sure but typically when I meet [4:39] developers they are kind of um afraid of [4:43] mathematics and I think there are [4:44] several reasons for that and those are [4:47] good reasons um first of all and [4:50] Mathematics most textbooks are really [4:53] bad um the notation is weird it doesn't [4:57] even type check you know if you're [4:58] trying to kind of [5:00] you know look at it it doesn't [5:02] work um the lingo is weird they have all [5:06] their own terms um they often you kind [5:10] of end up in a rabbit hole you know you [5:12] you want to kind of know a little bit [5:13] and before you know it you know you're [5:15] you're kind of you're deep into all kind [5:18] of Greek symbols and other dirty [5:21] pictures um and last not but least often [5:26] mathematics is taught in a bottom up way [5:30] okay so you cannot say I need to solve a [5:33] particular problem and I need a piece of [5:35] mathematics for that no instead they [5:38] start bottom up so you have to first [5:40] know a whole bunch of mathematics before [5:43] finally you can apply it to your problem [5:46] whereas with uh Computing we typically [5:50] teach the other way around um who here [5:53] has a computer science [5:55] degree okay I I would say about half so [5:59] so the other [6:00] people don't have a computer science [6:03] degree they still know how to program [6:05] but they didn't start by studying you [6:08] know Big O they didn't start to study uh [6:12] touring machines no they just opened up [6:15] an editor and started to hack they did [6:18] it top down um and of course at some [6:21] point you will feel that you maybe you [6:23] need a little bit more Theory but [6:25] programming is typically Tau top down so [6:28] you don't start start with all the [6:31] theory but no you start by solving a [6:34] particular problem and then you go down [6:36] let me give you a really good example of [6:39] that linear [6:41] algebra when most people teach linear [6:44] algebra they talk about matrices and [6:46] then you have to multiply matrices and [6:48] then you have to kind of do all kind of [6:50] mechanical stupid [6:52] things and then you use it to do [6:55] Graphics but you know instead of kind of [6:59] you know kn why you do it you're you're [7:01] kind of manipulating this kind of [7:02] lowlevel representation now if you know [7:06] that a matrix an M byn Matrix is really [7:10] the representation of a linear function [7:13] from a sequence of numbers of length n [7:16] to a sequence of numbers of length M and [7:19] matrix multiplication is function [7:21] composition so really when you're doing [7:24] Matrix manipulations you're doing [7:26] Assembly Language programming this is [7:28] completely nonsense that we as humans [7:31] have to do that if instead they would [7:34] teach linear algebra as a restricted [7:37] form of functional programming with some [7:39] special functions that are linear which [7:41] means that they have nice properties [7:44] everything would be easy but these are [7:46] the stupid mathematicians that are too [7:48] smart for their own sake and they teach [7:51] it bottom up okay and then in the end [7:53] you know we scratch our heads I scratch [7:56] my head way too [7:58] often um and then we ask ourselves why [8:01] is this useful all right so linear [8:04] algebra is really easy it's just [8:06] functional programming with linear [8:08] functions matrix multiplication is [8:10] function composition done same is true [8:14] with category theory if you look at [8:16] category Theory it looks scary just like [8:19] linear algebra but it's really easy so [8:22] let's um start looking at that so [8:27] mathematicians often call this is kind [8:29] of weird right mathematicians that give [8:32] us linear algebra they look at category [8:35] Theory and say this is abstract [8:38] nonsense and the reason that they say [8:41] it's abstract nonsense is because in [8:44] category Theory proofs are done in a [8:47] very abstract [8:49] way so it's look at what it says here [8:53] it's the study of the general form of [8:55] mathematical theories without regard to [8:59] their [9:00] content what that [9:02] means is that all intuition is taken [9:05] away and you look at the pure you know [9:09] pure general form well as programmers we [9:14] recognize that because whenever we do [9:17] when whenever we program against an [9:19] interface that's exactly what we're [9:21] doing we're programming against a thing [9:24] without regard to their content we're [9:27] not programming against a concrete time [9:30] we're programming against the abstract [9:32] interface and then there can be many [9:34] concrete types that we can plug in but [9:37] the program is still the [9:39] same the other thing that's interesting [9:43] is that here they talk about proofs so [9:45] you you build your [9:47] proof on these kind of General theories [9:50] well there's a very very interesting um [9:54] thing it's called the curry Howard [9:56] isomorphism people heard about the curry [9:59] Howard isomorphism it's one of the most [10:01] beautiful ideas I've ever seen so Curry [10:04] Howard isomorphism says that a type is a [10:08] theorem and the program is the proof for [10:11] that theorem okay now what means that [10:15] whenever we're kind of writing code [10:17] we're really proving theorems so we are [10:20] like mathematicians or you can say [10:23] mathematicians are really developers [10:25] that program really really slow [10:27] sometimes it takes them like two de pack [10:29] AG to kind of you know write you know [10:32] like a small [10:35] proof okay but this Cory Howard is [10:38] isomorphism is really beautiful I don't [10:40] have time today to um talk about that [10:44] but if you if you take that a little bit [10:46] further that's what I'm going to do here [10:48] is that you know [10:50] you define your theorems in terms of [10:54] these um abstract structures and then [10:56] you write your code in terms of them so [10:58] you do your proofs in terms of them and [11:01] so let's uh continue with that and as I [11:06] said this is really not foreign to uh [11:09] for us developers because we do this all [11:11] the time we do this when we program [11:13] against interfaces we do this when we um [11:16] use design patterns I'm pretty sure that [11:19] most people have that book on their [11:22] bookshelves and I'm also sure that [11:24] nobody has ever read it because when you [11:26] read it you get the feeling what's going [11:29] on this is all kind of you know how did [11:31] the mathematician say this this is [11:33] without regard to any actual content [11:37] because these design patterns are very [11:39] abstract and you can instantiate them [11:41] for specific purposes but that's the [11:43] beauty of design patterns because now [11:45] you can talk about Concepts in a very [11:47] abstract way without kind of you know [11:50] being tied to a very um concrete [11:55] implementation okay so that's [11:58] um all already I give you a couple of [12:00] tricks how to think like a mathematician [12:03] and profit from [12:05] that now what is category Theory well [12:10] category theory is embarrassingly simple [12:13] it has two well three concepts first of [12:17] all there's a notion of a category but a [12:20] category it consists of objects and [12:25] morphisms now as I said mathematicians [12:28] are real people they use strange lingo [12:31] so let's translate this into programming [12:34] terminology so a category is really a [12:37] programming [12:39] language okay and a programming language [12:42] has types okay like in Java there's [12:45] types Boolean strings um lists those are [12:49] the types and then there are morphisms [12:52] well that's just a fancy word for static [12:55] method so morphism from uh A to [13:00] B is just a static method that takes a [13:04] argument of type A and returns a value [13:06] of type B or [13:09] equivalently you can say it's a property [13:13] now you can ask yourself well if you're [13:15] saying that we're doing [13:17] programming why do I use static [13:20] methods because we also have instance [13:22] methods well we we'll come back to that [13:24] later so the whole point of this talk is [13:27] to kind of you know fix fix this and [13:29] make this precise so makes this notion [13:33] precise um that morphisms in a category [13:37] are just static methods now look at this [13:41] this is again mathematicians I I told [13:43] you they're slow programmers so here's [13:45] an example of a programming language [13:48] it's a programming language that has [13:50] three types A B and C so it's like [13:53] characters integers and booleans that's [13:57] it and then well if you have three types [14:00] then you can Define some functions [14:02] between them so for example I can go [14:05] from booleans to characters and I can [14:07] have a function from characters to [14:10] characters now for these mathematicians [14:12] this is so special that they give this [14:16] language a name and it's called bold [14:20] three okay now imagine if you want to [14:24] draw this kind of picture for Java you [14:27] know it wouldn't fit kind of you know [14:29] you would need all the walls here and [14:31] you know maybe the whole city with [14:32] graffiti like this maybe it would look [14:34] quite nice like an art project but this [14:36] is kind of mathematicians so they are [14:38] kind of proud that they understand this [14:41] programming language with three [14:43] types okay [14:46] now of course once you have types you [14:50] can create other types um and [14:54] everybody these days seem to want to [14:57] have topples and Java doesn't have [14:59] topples but there's many libraries that [15:02] provide toes anybody here does Android [15:05] programming a few people no so what are [15:08] you Windows phone [15:11] maybe no but if you do Android [15:13] programming you know you will know and [15:16] even if you don't it might might be [15:18] interesting to know is that in the [15:21] Android Library there is a type for [15:24] topples um that's so important that even [15:27] on your Android phone you need [15:30] topples um and here is some uh category [15:33] theory that defines what topples are in [15:38] mathematicians speak now you will ask [15:41] yourself oh my goodness where's my beer [15:44] the next beer this looks kind of [15:46] horrible okay there's like all kind of [15:49] weird stuff commuting diagrams canonical [15:53] stuff I don't even understand this so [15:56] let's take this um [15:59] Greek and let's try to um translate this [16:04] into a language that we all understand [16:07] okay so here's the um first sentence of [16:11] that uh um definition of topples and it [16:15] says let C be a category with some [16:18] objects X1 and [16:20] X2 um well as I said um a category [16:26] corresponds to a programming language [16:28] and and a object corresponds to a type [16:32] now often people confuse objects and [16:36] instances and whatever um so let's not [16:39] be confused so that's why I call them [16:41] types and types have instances and [16:43] whether you want to call the instances [16:45] objects or the type object I don't care [16:48] so that's why I call them types and also [16:50] then it doesn't clash with the objects [16:52] uh in the [16:54] category okay now what can I do when I [16:57] have two types well I can form a topple [17:03] they don't call it topples they call it [17:05] a product okay so they are going to take [17:09] these two types X1 and X2 they're going [17:12] to create a new Type X which you know [17:15] they can also write as X1 cross X2 and [17:19] then blah blah satisfies a Universal [17:21] Property blah blah blah blah blah do you [17:24] understand this no yes [17:29] good there's one person that understands [17:31] it great what [17:38] you um so let's go and [17:41] um drill down a little bit into this [17:45] because I think this picture um says uh [17:49] said it much better so if I have a [17:52] topple or a product I have two functions [17:56] that I can use to project the values out [18:00] of this toble so I can select the first [18:02] element and I can select the second one [18:05] now you can ask yourself why do they [18:08] start counting at one because we as [18:10] developers always now our index is zero [18:13] but again these are mathematicians they [18:16] don't they probably never done C [18:18] programming or whatever so they can [18:20] start their counting by one anyway so [18:24] this is the kind of thing but then [18:26] there's the all the rest of this [18:29] and what we see here is well how on [18:31] Earth do you get an instance of a topple [18:36] well you need a Constructor or a factory [18:39] function these mathematicians are not [18:41] stupid right they know that when you [18:44] create a type when you have a type you [18:47] you have to have a way to create it we [18:49] call it Constructor well they have here [18:52] some function that kind of you know [18:55] allows you to kind of create a [18:57] topper and then they say well if you [19:00] have such a function which you create [19:04] from two [19:05] morphisms then if you kind of start with [19:08] a value here you apply that to this [19:11] function now you get this guy that must [19:13] be the same as kind of projecting the [19:15] first value or applying this function so [19:19] it all must kind of commute and that's [19:22] looks quite nice in that [19:24] diagram now if you don't like diagram [19:27] then you can translate into equations um [19:31] whatever you find um easier to read [19:35] now except for this gentleman over there [19:38] what's your [19:40] name oh I cannot pronounce that but [19:44] generic [19:47] good Mr generic over [19:50] there he understands [19:53] this but that's gonna you know for the [19:57] rest of us you know whose brains are the [20:00] size of peanuts or smaller let's kind of [20:03] you know continue to um to to put this [20:07] into our language so um if we go on with [20:10] this translation we say that a type a [20:13] comma B is a product of a and b or a [20:15] topple of A and B if it satisfies blah [20:18] blah blah there exist two properties [20:21] underscore one and underscore two that [20:25] return an A and A B respectively and it [20:28] programmers [20:30] here you recognize this yeah look at [20:34] this I see a smile yep so this is a [20:38] Scala you can project the first and [20:40] second element but then there's also if [20:43] you have two methods the factory [20:45] function for this thing takes two [20:47] methods and it gives you a function that [20:49] given a c returns this pair of A and B [20:53] and it does that by kind of applying [20:56] that C to F and G respect [20:59] so this is a little bit different than [21:01] in Scala because the the the Constructor [21:04] function behaves a little bit different [21:06] but we can from this we can create the [21:09] normal Constructor function [21:13] too okay let's go look at this commuting [21:17] diagram and it's kind of the [21:23] same now as I [21:25] said if you look at Scala [21:29] I don't know I think this ma mathematics [21:31] is actually clearer and shorter because [21:34] look at this tra blah blah blah extends [21:37] blah blah blah abstract this abstract [21:40] that Curly open curly close now you see [21:43] why these mathematicians have their [21:45] strange lingo because maybe we have [21:47] editors and we have autocomplete but [21:50] look at how many characters we need to [21:53] write down kind of something simple like [21:55] this okay but here is you see um that [22:01] this is the uh definition in Scala of a [22:04] product um and I think this [22:08] is now you can ask yourself what the [22:10] heck are those pluses there am I going [22:13] to kind you know is this I don't know is [22:15] this un Plus or no no no that's Co and [22:18] Contra variance but that's way too [22:21] complicated but this is actually the way [22:24] that products are defined in Scala but [22:28] what uh Scala doesn't have is this [22:31] operator um to construct uh [22:35] products now the reason why Martin [22:39] cannot do that is because if you would [22:42] do that you would already need the [22:45] notion of functions as objects and that [22:48] was the whole point of of this [22:50] presentation to figure out you know how [22:53] can we make these morphisms into first [22:55] class [22:57] things okay [22:59] um so really you know if we look at this [23:02] simple example where we took the idea of [23:05] topples and we've seen how the [23:07] mathematicians do it and we do it it's [23:10] really the same except that the [23:13] mathematicians apply a little bit more [23:15] rigor they use weird notation but the [23:19] nice thing that they do that we never do [23:22] is when they Define a type they talk [23:24] about properties of the type what [23:27] properties should a product Define uh [23:29] have because if you look at this [23:31] definition in Scala right from here it [23:36] says nowhere that when you create a [23:40] topple out of two values and you project [23:43] from that topple the first value that [23:46] you actually get the value that you put [23:48] in there right nothing says this here [23:52] because it can return null for both [23:55] sides and it's still kind of according [23:57] to this type definition a valid [23:59] implementation of topple of course you [24:00] would not accept that but the the type [24:03] itself doesn't say anything so if you're [24:06] a smart programmer and somebody gives [24:08] you this trait and you have to implement [24:11] it you can just return null in both [24:14] cases nobody can complain if they file a [24:17] bug you immediately file the bug back [24:19] and say you didn't specify this thing [24:22] properly okay this is another tip okay [24:25] you just return null your colleagues [24:27] complain you just say sorry you know [24:31] specify it better and then you can go [24:34] have a drink a beer kind of go to [24:37] another meeting put that on your resume [24:40] get even more money look at this all [24:44] right good so um and here is the um you [24:50] know again the a slightly different [24:54] different um way to do this function I'm [24:57] going to skip this [24:59] um for a lack of time now um Mr generic [25:03] here says oh I knew this already but [25:06] this is old stuff right here is um John [25:09] McCarthy the inventor of of lisp and he [25:13] says well come on I could Define all [25:18] this stuff with topples and so on in [25:21] 1960 and then church Mr Alonso Church [25:25] who invented the Lambda calculus he did [25:27] this all already in [25:30] 1928 now look this guy here came up with [25:36] this in 1928 if you if you read the [25:39] papers from church he was doing this [25:42] kind of [25:43] toles in Java 8 it's 2015 last time I [25:47] checked there are still no proper toles [25:50] in the language look at this I I I I [25:54] don't even know it's like 2015 minus 28 [25:57] that's nearly [25:58] Century okay and we still don't this [26:02] thing still does we are and why is that [26:05] because we are afraid of these [26:07] mathematicians whereas we should steal [26:09] their ideas and profit from them okay [26:12] that's that's really kind of my message [26:14] today these people are smart look at [26:17] look at this size of this brain here you [26:19] know if I put my head next to it it's [26:22] like it's like 10 times the size we [26:24] should leverage [26:26] that but what do we in do [26:29] instead well first of all we are proud [26:33] that you know we don't do Theory so if [26:36] you look at c c has delegates and it's [26:40] like we don't need any of this Theory we [26:43] have delegates but where you know where [26:46] do these delegates come from what are [26:48] their properties we don't know and then [26:50] I don't know if anybody is old enough [26:52] probably most of you were not born yet [26:54] but when C came out the there was a [26:57] little fight between C and Java where [27:00] the Java folks said we don't need any of [27:03] this lambdas or delicate stuff because [27:06] we have virtual [27:07] methods and so this is another lesson [27:10] Never Say Never okay because I think [27:14] because they didn't want to lose face [27:16] for the longest time Java could not add [27:20] lambdas because you know James Gosling [27:23] said in public that lambdas are [27:26] unnecessary so then you're not going to [27:28] kind of turn around and add them oh so [27:30] first of all he had to kind of retire [27:32] kind of join Google join whatever [27:35] company is now at I think he's doing [27:36] self-driving cars at Stanford and [27:39] finally they could put uh uh delegates [27:43] um um lambdas into Java but the other [27:47] thing is also you should not kind of [27:50] downplay and be arrogant and downplay [27:53] Theory okay you should always stay [27:56] humble and hungry you always always want [27:58] to learn if these mathematicians come up [28:01] with something you know but you better [28:04] have a look at it because maybe it's [28:05] something that you can [28:07] use all right but then you can say come [28:10] on Eric what are you talking about [28:14] mathematicians and categories represent [28:17] mathematical objects whereas we as [28:21] developers we deal with objects that [28:23] represents real world things okay like [28:27] customers and orders and all kind of [28:30] other boring things that we have to do [28:33] in our day jobs and rather not do okay [28:36] but that's also not true because most of [28:39] our programs that we like to write when [28:41] we don't have to do customers and orders [28:44] are data structures list trees those [28:47] don't represent Real World objects I've [28:50] never seen a list I've seen trees in the [28:53] real world but they are not like the [28:55] trees that I have in my code [28:58] right and maybe lists a little bit [29:01] although you know the lists that I have [29:04] on my refrigerator never gets garbage [29:08] collected they never get finished [29:10] whereas the lists in my computer always [29:12] kind of you know end up kind of you know [29:14] disappearing [29:15] so all right [29:18] um but anyway I so I think that this [29:22] whole idea that objects represent real [29:25] world things is nonsense because [29:28] most objects that we deal with in [29:30] programming don't represent Real World [29:33] objects um and the other thing is that [29:38] what we can learn so what we can learn [29:41] from these mathematicians is that we [29:42] should be more careful in formalizing [29:46] the things that we deal with for example [29:49] if we write code in Java we deal with [29:52] methods but these methods themselves you [29:55] know we don't have an object that [29:58] represents [29:59] them is that true well well that's what [30:03] we're after but I'll I'll say something [30:05] more about that later um but the other [30:08] thing that we can learn from the [30:10] mathematicians is that we should also be [30:12] more careful that when we Define a type [30:15] that we think about the properties [30:17] because otherwise some smartass [30:19] colleagues of you can always return null [30:22] and then claim that this is a proper [30:25] implementation because you have not [30:28] specified with that type what the [30:30] properties are okay and the good thing [30:35] is that we don't have like weird [30:37] terminology although if you use uml and [30:40] all that stuff I I guess there's plenty [30:43] of craziness [30:45] there um now this is I'm a big fan of [30:48] ber Meer is not related because his last [30:52] name is with a Y and mine is with i j um [30:55] but he has a great saying where says [30:58] that you know objects don't really [31:00] represent real world things because [31:02] you're always kind of removed even if [31:04] you have a person object it doesn't [31:07] really represent a person because it's [31:09] something in the memory of your computer [31:12] that represents a person so you're all [31:14] kind of already twice removed from [31:17] reality okay [31:20] so let's just forget about that and just [31:23] look at objects and programming as [31:25] formal things just like mathematic iCal [31:29] objects all [31:31] right now I've been talking about [31:33] programming I thought this was about [31:35] category [31:36] Theory um now the thing before we go [31:40] there is we do have a way to talk about [31:44] methods as objects and that is with [31:47] reflection okay because if you do [31:49] reflection in Java you can kind of you [31:52] know go to a type get this methods and [31:54] you can even invoke that method using [31:56] reflection now reflection if you think [31:59] about it is super complex because it's a [32:02] program that can reason about itself [32:05] most of us are not even able to reason [32:08] about ourselves you know when we acting [32:10] foolishly in public after we've been [32:12] kind of you know partying are we [32:15] reflecting no typically not or maybe we [32:18] do um sometimes but but code it's [32:22] amazing that we can write code that kind [32:25] of you know reflects about itself um and [32:28] the mathematicians cannot do [32:31] that um but reflection is kind of a cop [32:36] out because with reflection we're not [32:38] really kind of having an object that [32:41] represents a method because it's kind of [32:42] you know in the in the kind of dream [32:45] world of reflection and what we're [32:48] trying to do here with lambdas or with [32:51] method references we're trying to [32:53] represent methods as normal objects not [32:56] as reflective [32:59] objects oh my [33:02] goodness this has to come okay Dave [33:06] Thomas small talk everybody knows Dave [33:09] Thomas okay Small Talk guy of course [33:12] what do small talk people [33:15] say when I was a young boy and were the [33:18] small talk was still uh popular that was [33:21] a long time ago um we already had blocks [33:26] that blocks are things that represent [33:29] methods that's quite remarkable because [33:32] if you look at small talk that is very [33:34] much as the flavor this emoral flavor [33:37] where objects represent real world [33:40] things where you send messages to it but [33:42] still they already knew that they had to [33:46] represent methods as objects [33:49] themselves okay but don't worry I won't [33:53] talk about small talk um and the reason [33:56] is that in small talk like what we saw [34:00] here in mathematics array indexes start [34:03] with one which as a Dutch person is [34:06] unacceptable because the big ater dexra [34:10] has told us that indexes should start at [34:12] zero and you know the reason why because [34:16] when he is GNA you know that's why I'm [34:18] going of doing this papers the first [34:20] paper there are zero papers here so [34:23] that's why it's zero and now the second [34:26] paper now it's two two so you see that's [34:29] how he got because he always wrote his [34:31] his papers by hand and so he counted [34:34] like how many papers were already there [34:37] okay so now you know why you should be [34:38] counting with [34:40] zero okay [34:43] um now let's kind of talk about why we [34:46] really here is how do we [34:49] represent [34:51] methods as [34:54] objects and again category theorists [34:57] have a fancy word for that they call it [35:01] exponentials and then you can ask [35:03] yourself why do they call it [35:05] exponentials why don't they call it [35:07] lambdas or anything normal like in in in [35:10] typescript you know Arrow functions or [35:14] yeah I don't know blocks well there's [35:17] actually a good [35:18] reason but if we look at this I don't [35:21] know I see people already except for uh [35:24] Mr generic [35:26] here he's like looking as [35:29] yeah this is like know beautiful this is [35:33] beautiful for the rest of [35:35] us it looks a little bit it like look at [35:38] this there's even now two diagrams here [35:41] okay but I see a Lambda can you see that [35:43] here it's like you know the font is not [35:45] so sharp but there's a Lambda so we're [35:47] we're in the right direction so let's [35:50] decode the Greek and let's zoom in so um [35:54] it says let C be a category with binary [35:57] product so that's the reason why we [35:59] started out with tles because in order [36:02] to do functions we need them that was a [36:04] little bit of for side of me um and let [36:10] Y and CB objects the exponential [36:13] object Z to the power of Y oh my [36:17] goodness why what this is why they [36:20] called exponentials because they write [36:22] it as an [36:24] exponent um is defined and blah blah [36:27] blah and then there's a new word [36:29] functor Oh I thought that we were ready [36:32] because I kind of cheated by doing this [36:35] uh products first but now we can to have [36:38] another hurdle here I have to explain to [36:40] you what functors are but first um let [36:45] me kind of explain a little bit why this [36:49] notation of exponentials make sense um [36:54] and the reason is that if I have a [36:57] function from a type y to a type [37:01] Z that there are Z to the power of Y [37:07] possible functions okay so if I have two [37:10] types Y and Z and I take all the [37:13] functions from y to Z then there are Z [37:17] to the power of Y of them now how can I [37:20] remember that okay I see somebody here [37:23] puzzled okay now let's do the simplest [37:26] case let's say say that [37:30] y so this is a function from y to Z so [37:33] now let's take y to be unit okay or void [37:38] so there's only one value and let take Z [37:42] be booleans true and false so how many [37:45] functions are there from void to Boolean [37:50] only two I can go from void to true and [37:53] from void to [37:54] false okay now how how many functions [37:58] are there [37:59] from Boolean to unit well there's only [38:03] one that Maps through to unit and false [38:06] to unit okay those are mathematical [38:10] functions now you can say in Java how [38:13] many functions are there from bull to [38:16] unit oh many because I can do print [38:20] line you know of that Boolean and that [38:23] returns unit I can kind of you know um [38:28] send it with an HTTP request to whatever [38:31] get it back that's another function I [38:33] can do reflection over the Boolean so [38:36] there's many functions and this is why [38:39] in [38:40] Java a method so I'm a little bit lying [38:44] because a method you know of bull to [38:47] unit is not really a function because [38:50] there can be side effects there there's [38:52] a lot of context that's hidden in Java [38:56] that you can use as a progam programmer [38:58] to kind of cheat and don't show that you [39:01] know that doesn't show up in the [39:03] signature now if you're I don't know if [39:06] there's any kind of you know [39:08] fundamentalist functional programmers [39:10] here people that crazy people that like [39:12] hll and no hll programmers here there's [39:15] one hcal programmer he's smiling he says [39:19] yeah look at that in hll this is true [39:21] not in your crappy Java right because in [39:25] hesal heso functions are really [39:28] mathematical functions so everything is [39:30] explicit but you know that's why you [39:34] know what is your name oh my goodness [39:37] even even more complicated than Mr [39:40] generic um let me call you Mr H Mr H [39:46] there his code is like probably 10 times [39:49] longer than the Java code by the time he [39:52] has kind of done all his monets and [39:55] whatever um so um [39:57] you know again maybe it's good to have [40:00] him as a colleague because then you can [40:02] you know you can learn from him and then [40:04] write all this code implicitly and then [40:06] he will say oh but I can do now my kind [40:09] of Monet Transformer with the state [40:11] Monet and the maybe Monet and the list [40:13] Monet and by the time he has figured out [40:15] how to compose all these monets you're [40:18] already here at Fu Cafe listening to [40:20] your next talk that you can put on your [40:22] resume and you get ahead isn't that [40:26] great [40:27] okay good let's translate this into [40:33] normal language Let L be a language that [40:36] supports [40:38] Tes okay that's already kind a big step [40:42] but let's assume that Java has [40:44] doues and let A and B types in the [40:47] language a function a arrow B I'm just [40:51] using normal notation now can be defined [40:54] as a factory method from the functor [40:58] okay so we're nearly there but now I [41:01] have to explain what a funter is because [41:04] I've removed all the Greek and I say [41:07] there's a factory method for functions [41:10] but in order to do that I need to know [41:14] what a funter [41:15] is now what is a funter and again this [41:19] is why most of us hate mathematics so [41:22] much because I warned you that you often [41:24] go into the rabbit hole okay and now [41:27] we're going into the rabbit hole a [41:29] little bit because when you look up [41:31] funter on Wikipedia it's even more Greek [41:36] oh my goodness ah does it ever stop [41:40] well let's look at it and it's not that [41:43] bad let's C be a category a funter blah [41:47] blah blah blah blah blah okay let's [41:49] translate this into normal English and [41:53] now we suddenly understand it [41:56] because since Java 6 and then was it [41:59] when did Java get generics was it Java [42:02] five wow look at that that's a long time [42:07] ago the way they did it yes um so here a [42:13] funter is a generic type that Associates [42:18] with each type A a new type c of a so [42:23] list of T is a funar because I can [42:27] instantiate it with another type say int [42:29] uh sorry [42:30] integer because generics and Java suck [42:34] that you can only instantiate them with [42:36] reference types and not with base types [42:39] um but yes and then on that type there [42:43] must be a function map that goes from C [42:47] of a to c of [42:50] B now think about [42:52] this what does this this thing do it [42:55] says that if I go if I can go say from [42:58] integers to string because I have two [43:01] string right that goes from integers of [43:04] from integers to string now if I have a [43:06] list of integers I must be able to kind [43:09] of you know do two string on every [43:12] element of that list and that's all what [43:15] this thing is saying that if I can go [43:18] from int to [43:20] string then I must go from list of end [43:24] oh sorry list of end to list of string [43:28] that is that's quite reasonable right [43:31] but when we Define generics so again [43:34] here's a trick whenever your colleague [43:38] defines a generic [43:40] type probably they don't specify that [43:44] this should hold that if you have if you [43:47] instantiate that generic type with one [43:49] type you instantiate with another that [43:51] you have to be able to go between them [43:54] well they should have a map function now [43:57] the thing with this map [43:58] function is that it should have some [44:01] properties too say that you know I'm [44:04] going from list of end to list of end [44:08] well how do I do that by doing the [44:11] identity function I'm doing nothing on [44:13] each element so that should be delivered [44:15] the same value right that is kind of [44:18] reasonable the other [44:20] thing is that if I do a map and then [44:24] another map that must be the same as [44:28] doing the map with the with these [44:31] functions combined okay and this is like [44:33] an optimization trick because instead of [44:36] taking a list of int do going into a [44:39] list of string and then say taking the [44:42] length of the string so now getting a [44:43] list of in again I don't have to build [44:46] that intermediate list because then I [44:48] can just map this function over that [44:51] list so these category theorists also [44:55] are efficiency freaks because because [44:57] they say that this map must have these [44:59] properties so that they can optimize [45:01] their [45:02] code okay so a um functor is just a [45:08] generic function um that has a map [45:11] operator [45:13] now in normal Java generics most [45:18] functions uh most types most generic [45:20] types don't come with a map finally in [45:23] Java 8 when they introduce streams [45:27] streams have a map function you can you [45:30] know you can go check now if you Google [45:33] java8 streams you will see there's a map [45:36] function so finally after like decades [45:39] and [45:41] decades [45:42] sorry 20 years of java and finally you [45:47] know they have map where if they would [45:49] have listened to the mathematicians when [45:52] they designed generics that should have [45:55] been built in because you know that [45:57] gives you again that is this thing where [45:59] you know a type doesn't come by itself [46:02] it comes with properties that it should [46:04] satisfy okay hey great now we know what [46:10] a um funter [46:14] is now the other thing if you know if [46:18] there's category theorists here in the [46:21] room I have to be a little bit careful [46:25] because what I said is a category was a [46:28] programming language and a functor is [46:31] really something that kind of goes [46:34] between two categories so a [46:37] functor can go between two programming [46:40] language for example if you have a Java [46:44] array and a [46:48] um Small Talk array then one starts [46:52] indexing at zero the other start [46:54] indexing at one and now say that I have [46:58] a method on arrays that sumps you know [47:00] up the values when I go from java to [47:03] small talk I have to adjust that some [47:06] function to start kind of indexing at [47:08] one okay that's another example of a [47:11] funter but for today we're only looking [47:13] at [47:14] endofunctors ah that doesn't that sound [47:17] cool [47:18] endofunctors but an endofunctor just [47:20] means that it stays within one language [47:22] so it doesn't go between two [47:25] languages okay [47:28] um good so this is the Greek [47:32] decoded [47:34] um now I've cheated a little bit already [47:38] because in [47:40] here you will see when I defined map I [47:44] already used the fact that I have a [47:48] function that I can pass into [47:50] map and before Java 8 you couldn't do [47:55] that right because there were no [47:57] function up there were no lambdas so you [47:59] could not even Define map so we had to [48:02] wait until Java 8 in order to have [48:05] functions such that we can Define map [48:07] but we're not there yet because we were [48:09] trying to kind of come up with how do I [48:12] represent methods as first class objects [48:14] how do I do [48:16] lambdas okay [48:18] and lamback reminds me Eric [48:24] yes that's what Xmen are for okay let's [48:29] go there okay here was the [48:32] Greek Okay blah blah blah there's this [48:36] object there's a morphism [48:39] eval blah blah blah blah blah okay now [48:43] then this diagram have to commute and [48:46] there we see our Lambda so we're getting [48:49] close so [48:52] let's um turn this into reality and of [48:57] course church or this is hesal B Curry [49:02] will say oh but this is currying in [49:04] hesal if you look here you know what [49:07] this is doing here this called eval blah [49:09] blah blah that's just currying and Mr [49:12] H has seen this already and he thought [49:16] yeah ah when did I start doing hll in [49:20] 1986 when did H one came out I already [49:24] did currying and all you Java guys can [49:26] only do it in Java 8 and most of you oh [49:30] most of you were on Java 8 this is very [49:33] Progressive because I know a lot of [49:34] companies that are still doing Java 6 [49:37] most of the time okay now here's another [49:41] well you're not Danish I'm going going [49:43] to insult you um but here is uh Mr [49:49] C++ and he's he's a smart guy because in [49:55] 199 [49:57] in [49:58] 1979 somewhere you know you can find [50:00] that on the web he explained that there [50:04] are no instance methods okay an instant [50:07] method is just a static method that [50:09] takes the disp pointer as an additional [50:11] argument okay so remember that in the [50:13] beginning I said we're only looking at [50:16] morphisms as static methods I'm I'm [50:18] going to ignore instance methods it's [50:21] because BNA told me so BNA told me it's [50:24] safe to ignore instance method [50:28] um so an instance method is just a [50:31] morphism from the the topple of [50:37] the the this parameter and the other [50:39] parameter and returns a value okay so [50:42] that's where the topples come in and [50:45] guess what even C++ has lambdas these [50:49] days isn't this amazing I don't think [50:53] there's any kind of programming [50:54] languages out there anymore more that we [50:57] all use that don't have [51:00] lambdas but it took many many DEC [51:03] decades and why is that because we [51:05] didn't listen to the [51:08] mathematicians all right now it might be [51:11] the case that in C++ that BNA says you [51:14] know there are no instance [51:16] methods but let's [51:18] um uh [51:20] let's [51:23] check what um Java has to say [51:27] so if you want to have an even more [51:29] boring document than the Java language [51:32] specification you should read the Java [51:35] virtual machine [51:37] specification okay but in the Java [51:39] virtual machine specification if you [51:42] browse around a little bit and that [51:45] says when you call a class method or an [51:49] instance method Here Local variable zero [51:54] ah they start to count at zero good boys [51:58] okay is always passed to an object that [52:01] represents the [52:03] instance okay and these subsequent [52:05] parameters are passed in subsequent [52:08] local variables starting at one so also [52:11] in Java there are no instance methods [52:15] it's just a static method where the [52:18] first parameter with index zero is the [52:21] this okay so we can simply um forget [52:27] about instense methods now of [52:30] course there are a little bit things [52:32] that I kind of put under the carpet [52:34] there's no carpet here but you know [52:36] imagine there was a carpet is things [52:38] like inheritance and so on so [52:42] inheritance is it's an interesting thing [52:45] because inheritance is quite useful [52:47] although some crazy people say we [52:50] shouldn't use inheritance we should use [52:52] composition if you have any colleagues [52:54] that say that [52:57] make them look bad and have them fired [53:00] because they are making your life [53:02] miserable because inheritance is a good [53:04] thing but the thing with inheritance is [53:07] that usually it's explained in terms of [53:10] the implementation it's it's you start [53:12] to talk about V tables and whatever and [53:15] the reason is because inheritance is a [53:17] dirty implementation trick to make it [53:20] easier to reuse code and to model [53:23] inheritance mathematically is not easy [53:26] and people write PhD thesis about it [53:29] William Cook maybe you know him wrote [53:32] his PhD thesis about the semantics of [53:35] inheritance um so I'm not going to talk [53:38] about that [53:39] today okay but let's uh continue [53:43] decoding the Greek um and now we are [53:48] somewhere where we can understand what's [53:50] going on so to remind you here's the um [53:57] category Theory with the strange [53:59] notation with the kind of exponentials [54:02] and there was this Lambda blah blah blah [54:05] I didn't even bother to kind of you know [54:06] go through that because you know [54:08] everybody would fall asleep after a few [54:11] hot dogs and hamburgers but now we are [54:15] something that we can understand so here [54:20] a function [54:22] type here together with the method apply [54:26] I is a function we call that a function [54:30] type if given any type a and a method M [54:37] that takes an argument of type B and [54:39] returns a c defined on a and remember [54:43] that if I have a method that's defined [54:46] on a it's really that M has Type A as [54:51] the first argument and B as the second [54:54] argument okay now what we can do is [54:58] there's a factory method that takes an A [55:01] and that factory method looks like colon [55:03] colon M and it returns a function from B [55:07] to C and that function object itself has [55:12] an apply method such that when I apply [55:15] that to B that is the same as calling M [55:19] on a and passing it B and then here I [55:23] just cast to C so that you can show that [55:26] it's the same okay [55:29] so anybody here has used method [55:32] reference in Java if you use intellig it [55:34] will tell you all the time right you [55:36] write something and it says I can [55:38] refector this into a method reference do [55:40] you use that anybody here uses intellig [55:43] you do what is your [55:45] name Paul ah finally a name I can [55:50] pronounce Paul do you ever use refactor [55:53] change into method reference yes and do [55:56] you recognize this kind of double colon [55:59] crazy thing so you have been using [56:02] exponential [56:04] objects did you realize that so now you [56:08] can go to your boss and say in Fu Cafe I [56:11] learned that I'm freaking using [56:13] exponential objects from category theory [56:15] in my coding I need a race because that [56:20] son of a next to me has no clue [56:23] what they're doing they're still using [56:25] whatever virtual methods but I know [56:28] exponential [56:30] objects good but it's [56:34] amazing function references method [56:38] references in Java are exactly the same [56:43] as exponential objects in category [56:45] Theory because the only thing I've done [56:49] here is translate the Greek into Java [56:53] code right so [56:57] why did it take so long they could have [57:00] sat down done the same thing as I did [57:03] came up with this said hey dude let's [57:06] hire somebody to implement this in the [57:08] compiler and we're done okay but I must [57:12] say I find this pretty amazing because [57:14] I'm 100% sure that the Java language [57:18] designers had no idea of category Theory [57:22] but yet they came up with exactly the [57:26] same [57:27] solution that is the amazing thing okay [57:31] so must be some universal truth here [57:35] because otherwise you would not two [57:37] completely independent people one from [57:40] Theory one from [57:42] practice um come up with the same idea [57:45] so if you look at here if I have a [57:48] method reference and I call the apply [57:51] method on that with argument of type B [57:54] that is the same as calling the method M [57:57] on a passing at B that is how method [58:00] references work this is how category [58:03] tier works this is how exponential [58:05] objects work isn't [58:07] this I mean this is America I don't know [58:11] about you but when I discovered this I I [58:15] I I don't know I I I drank a whole [58:19] bottle of this stuff and I don't know [58:22] what this is this is [58:24] rum I [58:26] I Dr your neor you know that's a kind of [58:29] the the Dutch [58:31] FKA okay but this is great now you can [58:37] say great we now know that method [58:40] references are exponential objects okay [58:44] so tomorrow when you go back to work [58:46] you're saying let's do some kind of [58:48] let's introduce some exponentials and [58:50] intellig can help us with that no don't [58:52] say that you you can of use that but [58:55] here's Eric Meyer and he has not [58:58] mentioned the MW yet I have not [59:01] mentioned monets yet so I'm going to do [59:05] a little [59:06] bit yes now I have before as [59:11] well when I was talking about the H yes [59:14] that's true but it was more like a [59:18] joke okay now let's look at this thing [59:22] so if you look at uh this exponential [59:26] object blah blah blah there's a right ad [59:29] joint and there's homets now homets have [59:34] nothing to do with fish EGS I don't know [59:36] is that the same in Swedish H in Dutch [59:39] that's the kind of the the EG of a fish [59:41] like cavar um this has nothing to do [59:44] with caviar okay it just says that if I [59:48] have a function from X to Y to Z that is [59:53] kind of isomorphic to having a function [59:55] that they [59:56] X and Y and return Z okay so this is [59:59] really saying that you can Curry and un [60:01] Curry and go in the in two directions [60:05] okay and a h set home AB is just a fancy [60:09] way of saying all morphisms from A to B [60:14] okay so this is just a fancy [60:16] thing um and the method the magic of [60:20] method references is really what it's [60:24] saying right it's saying that you know [60:26] there's an isomorphism between the [60:29] Lambda expression B Arrow a method [60:32] reference b um and this uh method call [60:37] here so there's nothing kind of really [60:39] fancy about [60:43] this and then you know we can kind of [60:46] talk about ad joints because that was [60:47] the other thing in there so an ad joint [60:50] I have to have two functors and in our [60:54] case it's this and to really prove that [60:57] I'm not talking nonsense you know here's [60:59] some real code that actually executes if [61:01] you use Scala [61:04] um but now here's the thing that if you [61:08] have [61:09] two of these adjoint functors and these [61:12] are the conversions between them that [61:16] gives rise to a [61:18] Monet so we came from exponential [61:22] objects there there came this notion of [61:25] AD joint functors and once you have [61:27] adjoined funs you get monets so there's [61:30] no escape from the monets so in the end [61:33] everybody will be like Mr H because you [61:36] know now that java8 has has exponentials [61:40] the next thing it will have are monets [61:43] because that's what category theory [61:46] predicts and I went through this real [61:48] quick but I tell you 10 years from now [61:53] 20 years from [61:54] now I I this will be the [61:58] case Java will have monets because [62:01] monets are related to adjunctions and [62:04] adjunctions come from [62:07] exponentials now the funny thing is that [62:10] the state modet comes from this [62:14] adjunction uh there um but that's a [62:17] topic for a different talk so [62:22] here's the next thing you had a lot of [62:25] beer [62:27] um tonight this will be your next [62:30] tattoo okay category Theory here [62:34] directly corresponds to Java and if this [62:38] like you know a little bit too dark for [62:41] you what about this one this one looks [62:44] cute right and I made a special deal [62:47] with Liz tattoo [62:49] parlor um where if you show your um Fu [62:54] Cafe t-shirt you will get a discount on [62:58] any of those two [63:03] [Applause] [63:05] tattoos thank you very much