I am not an expert and I might be well be wrong, but I decided to stop reading this paper after page 28 because I thought it is, well, not serious research and IMHO BS. I decided then to lookup the authors in google and scholar, and came up just with this paper, no other info or any academic background as far as I can tell; there is a Ben Moseley from Washington Uni, but his paper is not listed among his papers so I assume it is a different Ben.

I would have expected the authors of a paper that makes such revolutionary and sweeping claims to have more of a trail.

But of course, you have to judge a paper by its content.

The reason I stopped is because they quote heavily from a well respected book (often described as an updated SICP) that I am studying now, "Concepts, Techniques and Models of Computer Programming", and my interpretation of what the book says is at odds from how they apply it in the paper.

For instance, in the book the difference between a formal specification and an informal one is not in precision, but in that the formal one uses a mathematical language. However, in the paper it says that a formal specification is the same as formal requirements (synthesised by the engineer), which are different from informal ones from the user. These definitions can't both be right.

They also claim that in the ideal world control (basically order) can be entirely omitted. But what if from the user's informal requirements we must deduct that there are events that the user expects to be ordered?

The paper also claims that concurrency is not relevant in an ideal world, given that all operations are instantaneous. This would be impossible if there indeed there would be essential control, given that parallelism in the world is inescapable.

At this point I was convinced that I was wasting my time, and now I know why this paper hasn't had any impact in the mainstream, as one commentator has wondered.

I agree that's a wonderful paper to read, but has it had significant influence in the mainstream?

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.

TL;DR -- PHP/MySQL is functional and relational.

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.

I see what you mean. I was thinking of smaller granularity, less than an entire HTTP request. You have a good point.

"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 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

Maybe not in the mainstream, but I do see echos of the philosophy of reducing accidental complexity in clojure, elm, react/redux, rust.

Not yet, but I suspect that is partly the mainstream not catching up to the ideas it contains yet.

See my sibling comment -- I honestly believe it's describing what people already do. I'm curious what someone who's read the paper (like I have) thinks.