Modern Functional Programming: The Onion Architecture
1–10 of 100 posts
Re: Modern Functional Programming: The Onion Architecture
#2I'd not say this is a feature of functional programming. This is a feature of Object Oriented elements being included in fp languages.
These are the same things we were going to happen when using Java and C++ years ago.
You can even see similar graphics here: https://docs.oracle.com/javase/tutorial/java/concepts/object...
I remember there was another in this tutorial that shared more with the image in this post. Although this is the same idea. You're just hiding Objects in Objects.
Re: Modern Functional Programming: The Onion Architecture
#3I'd not say this is a feature of functional programming. This is a feature of Object Oriented elements being included in fp languages. These are the same things we were going to happen when using Java and C++ years ago. You can even see similar graphics here: https://docs.oracle.com/javase/tutorial/java/concepts/object... I remember there was another in this tutorial that shared more with the image in this post. Alth…
Well, he says this pretty early on:
> The onion architecture can be implemented in object-oriented programming or in functional programming.
Re: Modern Functional Programming: The Onion Architecture
#4I'd not say this is a feature of functional programming. This is a feature of Object Oriented elements being included in fp languages. These are the same things we were going to happen when using Java and C++ years ago. You can even see similar graphics here: https://docs.oracle.com/javase/tutorial/java/concepts/object... I remember there was another in this tutorial that shared more with the image in this post. Alth…
The difference is that a "layer interpreter" in functional style is just a pure function that transforms values to values, so it's very easy to test in a very direct way. And we have laws that guarantee that composition works correctly (i.e. the interpretation of a composition is the composition of the interpretations). Whereas it's a lot fiddlier to confirm that an object that uses other objects behaves correctly (you have to mock the inner objects), and virtually impossible to determine whether composition behaves correctly since the object's internal state is opaque.
Re: Modern Functional Programming: The Onion Architecture
#5Gary Bernhardt describes a similar architecture using a "Functional Core, Imperative Shell" in his Boundaries talk[1].
"Purely functional code makes some things easier to understand: because values don't change, you can call functions and know that only their return value matters—they don't change anything outside themselves. But this makes many real-world applications difficult: how do you write to a database, or to the screen?"
"This design has many nice side effects. For example, testing the functional pieces is very easy, and it often naturally allows isolated testing with no test doubles. It also leads to an imperative shell with few conditionals, making reasoning about the program's state over time much easier."
[1] https://www.destroyallsoftware.com/talks/boundaries
[2] https://www.destroyallsoftware.com/screencasts/catalog/funct...
Re: Modern Functional Programming: The Onion Architecture
#6I'd not say this is a feature of functional programming. This is a feature of Object Oriented elements being included in fp languages. These are the same things we were going to happen when using Java and C++ years ago. You can even see similar graphics here: https://docs.oracle.com/javase/tutorial/java/concepts/object... I remember there was another in this tutorial that shared more with the image in this post. Alth…
The architectural pattern of implementing a program in a language close to the domain and iteratively transforming it into something that can be consumed in an execution environment long predates OO, and is in fact the principle behind compilers.
It came out in a different guise under Model Driven Architecture and executable specifications a few years back.
It'll pop up again in the future under some other name. The principle is as old as computing itself, though.
Re: Modern Functional Programming: The Onion Architecture
#7> Free monads permit unlimited introspection and transformation of the structure of your program; Free monads allow minimal specification of each semantic layer, since performance can be optimized via analysis and transformation.
That is not true and this overselling of the Free monad is hurting the concept.
The Free monad is nothing more than the flatMap/bind operation, specified as a data-structure, much like how a binary-search tree describes binary search. And this means an imposed ordering of operations and loss of information due to computations being suspended by means of functions.
You see, if the statement I'm disagreeing with would be true, then you'd be able to build something like .NET LINQ on top of Free. But you can't.
Re: Modern Functional Programming: The Onion Architecture
#8I'd not say this is a feature of functional programming. This is a feature of Object Oriented elements being included in fp languages. These are the same things we were going to happen when using Java and C++ years ago. You can even see similar graphics here: https://docs.oracle.com/javase/tutorial/java/concepts/object... I remember there was another in this tutorial that shared more with the image in this post. Alth…
The architectural pattern of implementing a program in a language close to the domain and iteratively transforming it into something that can be consumed in an execution environment long predates OO, and is in fact the principle behind compilers. It came out in a different guise under Model Driven Architecture and executable specifications a few years back. It'll pop up again in the future under some other name. The…
> At the center of the application, semantics are encoded using the language of the domain model.
Say pg/psql.
> Beginning at the center, each layer is translated into one or more languages with lower-level semantics.
ORM mapping into Java?
> At the outermost layer of the application, the final language is that of the application’s environment — for example, the programming language’s standard library or foreign function interface, or possibly even machine instructions.
Or maybe even html+javascript.
Congratulations, you have (re-)invented the layered architecture.
Re: Modern Functional Programming: The Onion Architecture
#9> Free monads permit unlimited introspection and transformation of the structure of your program; Free monads allow minimal specification of each semantic layer, since performance can be optimized via analysis and transformation. That is not true and this overselling of the Free monad is hurting the concept. The Free monad is nothing more than the flatMap/bind operation, specified as a data-structure, much like how a…
Maybe this is a bit trite, but isn't the ordering given in Free simply the order of the code? At what stage does loss of information happen.
Re: Modern Functional Programming: The Onion Architecture
#10Earlier quoted context omitted.
The architectural pattern of implementing a program in a language close to the domain and iteratively transforming it into something that can be consumed in an execution environment long predates OO, and is in fact the principle behind compilers. It came out in a different guise under Model Driven Architecture and executable specifications a few years back. It'll pop up again in the future under some other name. The…
> At the center of the application, semantics are encoded using the language of the domain model. Say pg/psql. > Beginning at the center, each layer is translated into one or more languages with lower-level semantics. ORM mapping into Java? > At the outermost layer of the application, the final language is that of the application’s environment — for example, the programming language’s standard library or foreign func…
>> At the center of the application, semantics are encoded using the language of the domain model.
> Say pg/psql.
Minor nitpick: "pg/psql" is not the language of the domain model. The language of the domain model is stuff like "A car is considered 'All-Wheel Drive' if the drivetrain delivers power to any/all of the axles, not just a single axle."
pg/psql requires translating that domain-model language into something (roughly) like
set @awdCars := (select * from cars where drivetrainAxles >= allAxles)