Programming languages are embracing multiple paradigms, in particular functional and object-oriented paradigms. Modern languages are designed to support multi-paradigms. Wellknown examples include OCaml, Swift, Rust, TypeScript, Scala, F#, and Kotlin. Meanwhile, mainstream object-oriented languages such as C++ and Java are gradually extended to support functional paradigms. When multiple paradigms are available within one programming language, a natural question arises: which paradigm to choose when designing programs?

A fundamental difference between functional and object-oriented paradigms is the way of achieving data abstraction [1,2]. That is, how to organize data with associated operations. If we view a program as a matrix, data variants and operations are then the rows and columns of that matrix respectively. Object-oriented programming decomposes the program by row and is operation first: we first declare an interface that describes the operations supported by the data and then implement that interface with some classes. Conversely, functional programming decomposes the program by column and is data first: we first represent the data using an algebraic datatype and then define operations by pattern matching on that algebraic datatype.

There are important tradeoffs between functional and object-oriented decompositions in terms of extensibility and expressiveness. As acknowledged by the notorious Expression Problem [1,3,4], these two decomposition styles are complementary in terms of extensibility. Object-oriented decomposition makes it easy to extend data variants through defining new classes. On the other hand, functional decomposition makes it easy to add new operations on expressions. Besides extensibility, object-oriented and functional decomposition have different expressive power. Object-oriented decomposition facilitates code reuse through inheritance and enables interoperability between different implementations of the same interface whereas functional decomposition allows inspection on the internal representation of data through (nested) pattern matching, simplifying abstract syntax tree transformations.

Unfortunately, programmers are forced to decide a decomposition style in the early stage of programming. A proper choice, however, requires predictions on the extensibility dimension and kinds of operations to model, which may not be feasible in practice. Once the wrong design decision was made, the price for switching to the other decomposition style could be rather high since pervasive manual refactoring is often needed.

A better way, however, allows programmers to choose a decomposition style for prototyping without regret. When the design choice becomes inappropriate, a tool automatically transforms their code into another style without affecting the semantics. Even at later stages, such a automatic translation tool could be used to make extensions of data variants or operations easier by momentarily switching the decomposition, adding the extension, and then transforming the program back to the original decomposition. Furthermore, studying the transformation between the two styles can provide a theoretical foundation for compiling multi-paradigm languages into single-paradigm ones. From an educational perspective, the tool can help novice programmers to understand both decomposition styles better.

To address this issue, we propose a bidirectional transformation between functional and object-oriented decomposition based on the observation that restricted forms of functional and object-oriented decomposition are symmetric. We formalize an automatic, type-directed transformation in the core calculus FOOD, which captures the essence of Functional and Object-Oriented Decomposition. We prove that the transformation preserves the type and semantics of the original program. We further implement FOOD in Scala as a translation tool called Cook and conduct several case studies to demonstrate the applicability of Cook. Interested readers may want to consult the full paper for more details [5].