I read this more than 5 years ago, I think from a recommendation on HN. But I must have gotten something different out of it than most people.
It is advocating a particular architecture. But that architecture is essentially LAMP, as far as I can tell. It's what we ALREADY do!!!
From the paper:
FRP is currently a purely hypothetical approach to system architecture
that has not in any way been proven in practice. It is however based firmly
on principles from other areas (the relational model, functional and logic
programming) which have been widely proven.
In FRP all essential state takes the form of relations, and the essential logic is expressed using relational algebra extended with (pure) user-
defined [18] functions.
[18] By user-defined we mean specific to this particular FRP system (as opposed to pre-
provided by an underlying infrastructure)
-----
- All essential state takes the form of relations This is a database. (SQL deviates from the relational model, but I don't view that as important here. An SQL database stores everything as relations.)
- Logic is expressed using pure user-defined functions This is PHP / CGI / FastCGI. PHP is imperative, but the entire program is a pure function, because the request state is cleared between every request.
What am I missing? I'm being totally serious -- this is what I got out of it when I read it 5 years ago.
You can quibble with the details of PHP or Rails not being pure functions, but I believe what's important is the architecture, not how the source code looks. The essential state is in the database, in the form of relation. Accidental state is thrown away.
"All essential state takes the form of relations This is a database" - relations are a more abstract concept than this, see relational programming
"Logic is expressed using pure user-defined functions This is PHP / CGI / FastCGI. PHP is imperative, but the entire program is a pure function, because the request state is cleared between every request." - the entire program is not a pure function as seen by clients; to be functional, sending an identical request would always have to display the same information, but it won't if the page was updated between requests. Functional means that a given input (the request in this case) would always return the same output (page), just like a function in the mathematical sense would.
"PHP/MySQL is functional and relational." In a behavioural view of "functional", what matters is whether an operation always produces the same output for a given input; this is certainly possible with imperative languages, with some discipline. We can't apply a definitional view in this case, because PHP is multiparadign, supporting both stateful and functional programming , so you can't write operations that are functional by definition, you have to know what your are doing.
BTW, I haven't read the paper yet, I guess it will change my views after I do
FRP is a constrained environment, which makes it easier to reason about. PHP is comparatively unconstrained, so when reading code you can’t make as many shortcut assumptions. Of course you could write in PHP in accordance to the rules, but subsequent maintainers, including the future you, cannot trust this self-imposed discipline. In other words, you wouldn’t argue that assembler is just fine because through vigor and discipline you can build PHP-like application. Similarly, PHP is not well-suited to stand in for FRP.
I probably shouldn't have said PHP, since people have reactions to that language that may confuse the issue.
I should have said stateless Python front ends. Not even CGI/FastCGI, but just plain HTTP front ends. Many large websites use this architecture (YouTube, Instagram, etc.)
An example of something that doesn't follow the architecture is a stateful node.js or Go server.
I would say that the typical web architecture is similar to what they are talking about, with the benefit of existence :)
But you're right in the sense that they are trying to be more strict, starting on page 50:
- benefits for state -- avoid useless accidental state. This is the same philosophy behind SQL.
- benefits for control -- They are being more strict here, but I think it is missing a lot, because sometimes you need control flow.
- benefits for code volume -- I would need to see a real system to evaluate this claim. It's not fair to compare systems that exist with ones that don't :)
- benefits for data abstraction -- SQL agrees here. You don't abstract data. People sometimes make this mistake in their OOP languages, but's incidental.
FRP is like excel or well constructed makefiles in that the runtime understands the data flow. Then on updates to any data, you walk through the dataflow graph, running pure functions to update each node.
I think you're talking about functional reactive programming, which they are not talking about. See page 42:
[16] Not to be confused with functional reactive programming [EH97] which does in fact have some similarities to this approach, but has no intrinsic focus on relations or the relational model
It is advocating a particular architecture. But that architecture is essentially LAMP, as far as I can tell. It's what we ALREADY do!!!
From the paper:
FRP is currently a purely hypothetical approach to system architecture that has not in any way been proven in practice. It is however based firmly on principles from other areas (the relational model, functional and logic programming) which have been widely proven.
In FRP all essential state takes the form of relations, and the essential logic is expressed using relational algebra extended with (pure) user- defined [18] functions.
[18] By user-defined we mean specific to this particular FRP system (as opposed to pre- provided by an underlying infrastructure)
-----
- All essential state takes the form of relations This is a database. (SQL deviates from the relational model, but I don't view that as important here. An SQL database stores everything as relations.)
- Logic is expressed using pure user-defined functions This is PHP / CGI / FastCGI. PHP is imperative, but the entire program is a pure function, because the request state is cleared between every request.
What am I missing? I'm being totally serious -- this is what I got out of it when I read it 5 years ago.
You can quibble with the details of PHP or Rails not being pure functions, but I believe what's important is the architecture, not how the source code looks. The essential state is in the database, in the form of relation. Accidental state is thrown away.
TL;DR -- PHP/MySQL is functional and relational.