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

51–60 of 66 posts

Re: The Misunderstood Roots of FRP

#51

Post by sansnomme »

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…

The Svelte framework is something that's pretty close to being truly reactive. Not functional though.

Re: The Misunderstood Roots of FRP

#52

Post by keithalewis »

perl4ever wrote: post #23

I notice the mention of spreadsheets. Something I never thought about until I started writing scripts in Excel is that when you define new functions to be used in cell formulas, they are not allowed to have side effects...and it didn't take long before I wanted to write functions with side effects. Sure, this makes sense from a certain perspective, but when you're using a dialect of Basic, you kind of think it's down…

If you use Microsoft's C SDK then you can write functions with limited side effects by declaring the function "uncalced". For example, you can peek at the current cell value of the function being called.

Re: The Misunderstood Roots of FRP

#53

Post by iamwil »

dakom wrote: post #42

I spent a fair amount of time dabbling with FRP - for example, wrote a Pong for the web using SodiumFRP and Purescript[0] imho FRP is absolutely elegant and wonderful when it all comes together. The difficulty, I found, is iterating and hacking away in order to discover what the end result was meant to be all along. In that respect FRP does slow down development time (at least in my hands. Maybe those with more exper…

What did you find that you had to hack away? Was it notions of how to do things from your previous experience as a programmer? Or was it more specific to the domain problem at hand?

If it's the latter, then I'd argue that's part of the exploration of the problem you're trying to solve, no?

Re: The Misunderstood Roots of FRP

#54

Post by iamwil »

gtirloni wrote: post #47
blondin wrote: post #25

Earlier quoted context omitted.

yep. i knew in our field the F & P could only mean functional programming. but the R eluded my acronym decrypting skills. glad to find someone found what it meant. i almost thought it was "recursive"... can we agree to stop using these meaningless acronyms?!

You just have to spell it out once at the beginning of the article, then it's fine. The author never did it once.

The site is "Future of Coding". He assumed most of his audience were language wonks, and you don't have to go far to run into FRP.

That said, it's best not to assume.

Re: The Misunderstood Roots of FRP

#55

Post by iamwil »

sriku wrote: post #34

This stuff is close-to-heart for me as FRP (and Elliott's work in general) greatly inspired my thinking over the years. Here are a few instances where the drive to be denotational in api design led to very satisfactory results. This is a massive "shameless plug" post, but I justify it as a dedication to Conal Elliott. First, a couple of old talks on the topic - - "Functional thinking" - Brings together some of the th…

What did you replace Elm with in your later work with FRP systems?

Also, with your Elm-anima project, what were the lessons and takeaways? It seemed like it was working, but what are the limitations of the approach?

Re: The Misunderstood Roots of FRP

#56

Post by marcosdumay »

skybrian wrote: post #8
dustingetz wrote: post #6

What Steve calls "Denotative Continuous-Time Programming" – I think Clojurists call this declarative data programming – that is, you figure out a way to model the problem domain in data, and then write pure functions on that data. For example, React.js models the dom as data. Clojure gives you the toolkit of programming language primitives you need to do this easily, ergonomically and often, for all of your problem d…

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…

> This makes designing an intuitive FRP-based language pretty hard.

Yet, I fail to see any other representation where it is viable to solve those problems in a generic way.

If we want to get something better than our current "it's impossible, better not even try" posture, we better look for it somewhere where it is possible.

Re: The Misunderstood Roots of FRP

#57

Post by zyxzevn »

pasquinelli wrote: post #26
zyxzevn wrote: post #19

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…

The first line seems the most easily parsed to me. The second one is the worst, and the third one only works for a tidy pipeline; if you have to combine multiple pipelines you'd need to bracket them, as in the first.

You must be used to reading inside out, instead of left to right.

The parameters will mess up as soon you have multiple parameters. Especially messy if you want to reuse them. Or when you have conditions.

In a graphical system you do not need brackets, which is why I added it as a possible solution.

Re: The Misunderstood Roots of FRP

#58

Post by Izkata »

csande17 wrote: post #32
throwaway_n wrote: post #30

Earlier quoted context omitted.

Won't your example trigger an infinite loop of celsius/fahrenheit conversions? Especially if the floating point value is slightly off. I think your example is exactly why stuff like React won vs data-binding frameworks. With declarative programming, you just have a single source of truth that you change once (you can arbitrarily pick celsius or fahrenheit or even kelvin) and let the framework figure out what needs to…

I'm not aware of any actual real-world GUI system where ".whenChanged do" is valid syntax, but just for the sake of argument, pretend that it only fires when the user changes the textbox. Coincidentally, this also happens to be how the "change" event works in JavaScript.

I know of one that's essentially like that [0], but like you suggested - it only fires on user action, not programmatic update.

(The examples here are for buttons and sliders, but it's the same syntax for input fields)

[0] http://rebol.com/docs/easy-vid.html#section-20

Re: The Misunderstood Roots of FRP

#59

Post by Izkata »

zyxzevn wrote: post #57
pasquinelli wrote: post #26

Earlier quoted context omitted.

The first line seems the most easily parsed to me. The second one is the worst, and the third one only works for a tidy pipeline; if you have to combine multiple pipelines you'd need to bracket them, as in the first.

You must be used to reading inside out, instead of left to right. The parameters will mess up as soon you have multiple parameters. Especially messy if you want to reuse them. Or when you have conditions. In a graphical system you do not need brackets, which is why I added it as a possible solution.

The first and third are both easier for me than the second.

At least in my case, it's not an inside-out or left-right thing, it's a funnel that shows the exact relationship of the data. The problem with the second one is that the multiple distinct statements require scanning up and down across them to ensure the local variables aren't used anywhere else, and then mentally reconstructing the data's flow from one function to the next.

It's also why I strongly prefer statements like this:

  A(
    B(C),
    D,
    E(F(G))
  )
The flow of data is encoded directly in the visual structure, instead of being split out across various statements using local variables that leak intermediate state and introduce accidental mental overhead.

Re: The Misunderstood Roots of FRP

#60

Post by dakom »

iamwil wrote: post #53
dakom wrote: post #42

I spent a fair amount of time dabbling with FRP - for example, wrote a Pong for the web using SodiumFRP and Purescript[0] imho FRP is absolutely elegant and wonderful when it all comes together. The difficulty, I found, is iterating and hacking away in order to discover what the end result was meant to be all along. In that respect FRP does slow down development time (at least in my hands. Maybe those with more exper…

What did you find that you had to hack away? Was it notions of how to do things from your previous experience as a programmer? Or was it more specific to the domain problem at hand? If it's the latter, then I'd argue that's part of the exploration of the problem you're trying to solve, no?

Hmmm good question! I can't say for sure - I guess it was a bit of both.

In either case, I found it's faster to play around with changes in other approaches, though another way of phrasing that could be that it's easier to break things too :)

Post reply on HN