Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Misunderstood Roots of FRP

futureofcoding.org

Post reply on HN
Print view View original

11–20 of 66 posts

Re: The Misunderstood Roots of FRP

#11

Post by proc0 »

pubby wrote: post #5

Yeah okay. Then why does nobody use it? Even languages like Elm ditched it for easier to understand concepts. Let's face it. FRP kinda sucks. It's awkward as hell to use and takes way to many brain-cells to achieve simple results. Even the experts have trouble with it. I remember e-mailing the author of a popular FRP library once asking him how I could get multiple shapes moving on the screen at once (as opposed to j…

Isn't Redux FRP? You can easily do the basics in React as well. I would say it's the dominant paradigm in UI development and most don't know they're using it.

Re: The Misunderstood Roots of FRP

#12

Post by csande17 »

dustingetz wrote: post #9
skybrian wrote: post #8

Earlier quoted context omitted.

You can think of a timeline as immutable, but you don't know values from the past unless you arranged for them to be recorded, you don't know values from the future until they happen, and you don't know what's going on at any other node unless they send you a message about it and it eventually makes it across an unreliable network. (So, sometime after it actually happened.) If you model this in a declarative way then…

> be careful to avoid implying that all events should be remembered Is that true in a post-AWS world with storage getting cheaper faster than you can consume it? Maybe don't put 4k video in the log. But, you're right, we can stream, shard and forget as necessary. > also avoid depending on anything in the future unless you want to wait for it Can you elaborate on this, my gut reaction is to ask why I need to avoid dep…

> Is that true in a post-AWS world with storage getting cheaper faster than you can consume it?

This might be true of "storage" as in disk space, but it definitely isn't true of "storage" as in RAM. If your phone kept an in-memory log of every single click event, you'd run out of RAM pretty fast.

Re: The Misunderstood Roots of FRP

#14

Post by csande17 »

Imagine you were trying to explain the temperature-conversion program's behavior in the simplest, clearest way possible. (That is, after all, what programmers fundamentally do: try to explain things to computers as simply and clearly as possible.) You'd probably say something like: "When the user changes the Celsius textbox, the computer changes the Fahrenheit textbox to the converted value." And indeed, that's the program most people would write:

    celsiusTextbox.whenChanged do
        fahrenheitTextbox.value = cToF(celsiusTextbox.value)
    end
What you wouldn't say is something like: "The Fahrenheit textbox's value depends on whether the Fahrenheit textbox or the Celsius textbox was edited more recently. If the Fahrenheit textbox was edited more recently, its value is equal to the value the user entered into it most recently. If the Celsius textbox was edited more recently, the Fahrenheit textbox's value is equal to the converted value of the value the user entered into the Celsius textbox most recently." But that's the program you have to write in the "DCTP" approach proposed by the author.

I think this is true of a lot of UI programming: most people intuitively think about it in terms of "when X happens, do Y", so trying to cram it into another programming model is more trouble than it's worth.

Re: The Misunderstood Roots of FRP

#15

Post by _bxg1 »

csande17 wrote: post #14

Imagine you were trying to explain the temperature-conversion program's behavior in the simplest, clearest way possible. (That is, after all, what programmers fundamentally do: try to explain things to computers as simply and clearly as possible.) You'd probably say something like: "When the user changes the Celsius textbox, the computer changes the Fahrenheit textbox to the converted value." And indeed, that's the p…

Yeah. More power to people like this who are trying to make pure-functionalism more accessible and practical, but I have my doubts that contorting logic that's naturally stateful into a denotational paradigm will ever feel natural or intuitive. Human intuition is rooted in navigating the physical world, and imperative/cause-and-effect thinking is a very physical way of accomplishing things.

Re: The Misunderstood Roots of FRP

#16

Post by macintux »

dmitriid wrote: post #10

As with most if these things, the theory is fascinating. And then comes a contrived small code example... and the theory falls apart: - the example is trivial - the code example is extremely complicated for such a trivial example - the code has to be explained in minute detail, with at least one visualization (better, two) - and it still remains largely over complicated I shudder to think of any non-trivial example w…

And the author admits as much:

> Even I find the above code hard to read, despite having written it! While this could be seen as a downside of the denotative approach, I see it as a mismatch between the denotative approach and textual syntax.

Clearly, from this piece and his site as a whole, he’s looking at the long-term picture. Maybe there’s no way to make this better, but we’ve been stuck with the same basic models for decades. I’m glad people are looking for more revolutionary ways to make programming more powerful.

Re: The Misunderstood Roots of FRP

#17

Post by _bxg1 »

pubby wrote: post #5

Yeah okay. Then why does nobody use it? Even languages like Elm ditched it for easier to understand concepts. Let's face it. FRP kinda sucks. It's awkward as hell to use and takes way to many brain-cells to achieve simple results. Even the experts have trouble with it. I remember e-mailing the author of a popular FRP library once asking him how I could get multiple shapes moving on the screen at once (as opposed to j…

Agreed, partly.

> The great irony is that nobody on the planet thinks of spreadsheets as time-varying continuous functions. Nope. People view spreadsheets as a big grid of numbers... i.e. state.

People view some spreadsheet cells as state, and they view others as functions. There's a distinction between things that are naturally represented as one, vs the other.

This is why I preach to people about MobX whenever I get the chance. It's a Redux alternative that embraces state for things that make the most sense as state, while giving you tools to easily FRP not only React content, but any pure function of that state.

Re: The Misunderstood Roots of FRP

#18

Post by pubby »

proc0 wrote: post #11
pubby wrote: post #5

Yeah okay. Then why does nobody use it? Even languages like Elm ditched it for easier to understand concepts. Let's face it. FRP kinda sucks. It's awkward as hell to use and takes way to many brain-cells to achieve simple results. Even the experts have trouble with it. I remember e-mailing the author of a popular FRP library once asking him how I could get multiple shapes moving on the screen at once (as opposed to j…

Isn't Redux FRP? You can easily do the basics in React as well. I would say it's the dominant paradigm in UI development and most don't know they're using it.

To me, the core of FRP is hiding state. You couldn't look at a FRP program and say, "Yeah, here's where we define value X". Instead, you'd see various time-varying functions and the manner in which these functions are composed will implicitly define the state.

I think Redux isn't true FRP because it's very much about defining state. You plainly state every variable your program needs, while in FRP, variables just don't exist.

Re: The Misunderstood Roots of FRP

#19

Post by zyxzevn »

Nobody quickly understands:

    A(B(C(D(E(x)))))
That is why they use the assignments.

    e= E(x)  
    d= D(e)  
    c= C(d)  
    b= B(c)  
    a= A(b)
But many people can understand:

    x-> E -> F-> C-> B-> A  
    // where -> is a pipe operator.
Now you see that you first execute E with x as input.

This shows that Functional program has some kind of problem, if it is not presented in a good way.

There are also other problems. The overuse of Currying is bad, as it hides what is going on. Then we can also have recursion mixed with lazy execution.

I think that the problem with functional programming is the bad presentation of what is really going on.

I try to overcome these problems by using a pure graphical system instead. Everything should be as simple and clear as possible. The system is still in design/development, but you can see some at http://www.reddit.com/r/unseen_programming/

The general idea is that cells like in a spreadsheet are a basis for our functions. Unlike a spreadsheet-cell they can contain multiple variables. These cells can then be combined with pipes and streams. That may already define an functional language, but for me that is just the start.

Re: The Misunderstood Roots of FRP

#20

Post by chii »

pubby wrote: post #5

Yeah okay. Then why does nobody use it? Even languages like Elm ditched it for easier to understand concepts. Let's face it. FRP kinda sucks. It's awkward as hell to use and takes way to many brain-cells to achieve simple results. Even the experts have trouble with it. I remember e-mailing the author of a popular FRP library once asking him how I could get multiple shapes moving on the screen at once (as opposed to j…

> How could we fit HTTP requests into the DCTP model? ... > HTTP requests are too low level ... We need to go higher level and build a denotative model for “whole systems.”

So this points out a flaw in thinking i think : that you own the whole system.

I think the reason FP and FRP is hard to use is because a lot of work involves interfacing with existing systems that are inherently created imperatively (the examples in the article - files, network IO, etc).

It is the same story as LISP machines - the idea is great, but the existing infrastructure and computing devices all rely on register based machines, and run imperative instructions means that at some point, somebody had to write code to work with those machines, and that code tends to infect upwards to the high-heavens of clean abstraction, taking it down. And this happens on every level - because one implementation details is another's interface.

Post reply on HN