Nicolas Rinaudo - When is an ADT not an ADT?

Modeling data types is a critical aspect of programming: coming up with the right data representation can mean the difference between clear, efficient code, and an unholy mess of spaghetti code with tons of forgotten edge cases.
At the same time, there’s a fundamental tension between what’s commonly known as ““the OOP approach”” and ““the FP approach””, where the former introduces a tight coupling between data and behaviors, and the latter does the exact opposite.
In this talk, we explore both by attempting to represent and interpret a (very simple) programming language using ““the OOP approach,”” observing the pain points, and seeing what different set of properties we get by fixing them. By the time we’re done, we’ll have explored a large chunk of the design space, and learned lessons on the various tradeoffs one makes by choosing one approach over the other. Importantly, we try to stay away from oversimplifications such as FP good, OO bad. We hope to demonstrate that both approaches are interesting and valid, and choosing one should be a matter of context rather than religious belief.

[@gerardbosch]

Hi anyone, I'd like to ask whether type classes would help to solve the problem of adding new terms, when using ADT-encoding? Thanks!

[@avalagum7957]

Does it look wrong when we write `class Eq extends Exp`? I understand that we come to it because we can describe the equality in a binary tree. However, I don't think all the binary trees are about the same thing, i.e. it doesn't make sense to put a binary tree about A in a binary tree about B. If we agree with that, then we can avoid the complication of `Exp[...]` (but I guess that complication won't disappear, it will go somewhere else 🙂).

[@controlflow89]

Very very basic Expression Problem talk