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

Functional Reactive Programming

wiki.haskell.org

Post reply on HN
Print view View original

61–70 of 121 posts

Re: Functional Reactive Programming

#61

Post by jfoutz »

zmgsabst wrote: post #49
cybrox wrote: post #23

As someone who had to maintain two applications written entirely using the FRP Paradigm (Rx in Kotlin/Swift with a heavy focus on FRP principles), I am fascinated the idea but I absolutely hated the experience. Writing behaviour flows can end in beautiful blocks of easy to understand operations. However, as these get more complex and you need to combine multiple data streams, logic is scattered all over a module. Ref…

Do you have any thoughts on what would make a better experience?

So, I'll start with a disclaimer - I've only futzed around with FRP in Haskell, and never for money. Somewhere on an old computer I've got some code to simulate a pool table. But it has been a few years.

The pool table is pretty fun to model. You've got events, which are collisions, and you've got an evolving state that you can sort of fast-forward through thanks to elementary physics. if you want to sample at a given time, you can. You can calculate out the time to the next event (collision with another ball or bumper)

For me, when I got to multiple objects interacting at different times it got really tough to store the state of the world. (like after the break) I didn't try to support angular momentum - but it would have been fairly straightforward to add.

What I've been thinking about lately, is algebra driven design https://algebradriven.design That'd really help with nailing down the data structures and operations on them. That book has a couple of really gnarly sequenced state with constraints examples, that came from real production code.

There's no closed form solution to some problems (a lot! most problems!). So I think really nailing down a data structure, and providing operations on that data structure are essential. You, well, I need to create an environment where I can create tactics for solving special cases, without that code for the tactic getting smeared all over the code base.

I'm a dilettante, I've got very little experience on the JS side of things. But from pure Haskell, I'm a reasonably sophisticated amateur. So take my opinion in that context.

I think the automated tooling for finding laws presented by Sandy Maguire really have a lot of potential for Locking down those interactions - and opening up new ways of decomposing those interactions, to make more sophisticated descriptions of interactions. I'm not clever enough to find a closed form, but given some state and a time delta, I can work out a bunch of special cases - the interactions. Keeping that tidy is tricky. That algebra approach seems really promising.

Again. I'm a dilettante. Take my opinion in that context. There are probably horrible corners where all this falls down. Anyway, the day is starting and it's almost time to go wrestle yaml.

Re: Functional Reactive Programming

#62

Post by marcosdumay »

cybrox wrote: post #23

As someone who had to maintain two applications written entirely using the FRP Paradigm (Rx in Kotlin/Swift with a heavy focus on FRP principles), I am fascinated the idea but I absolutely hated the experience. Writing behaviour flows can end in beautiful blocks of easy to understand operations. However, as these get more complex and you need to combine multiple data streams, logic is scattered all over a module. Ref…

FRP is like OOP. For some problems, there is a level of granularity where it's an absolute killer, and nothing gets even nearly as effective. But if you write it with too much granularity, it will completely destroy your code. (And with too little granularity, it will be useless.)

This phrase alone: "data-flows that go through multiple modules" is a very good indication that you broke things down too much, and should have ditched the FRP abstraction on a higher level.

Re: Functional Reactive Programming

#64

Post by twawaaay »

amarant wrote: post #30
cybrox wrote: post #23

As someone who had to maintain two applications written entirely using the FRP Paradigm (Rx in Kotlin/Swift with a heavy focus on FRP principles), I am fascinated the idea but I absolutely hated the experience. Writing behaviour flows can end in beautiful blocks of easy to understand operations. However, as these get more complex and you need to combine multiple data streams, logic is scattered all over a module. Ref…

Huh, my experience with Rx-Java is (partially) the opposite to yours. Partially because I've seen it used poorly in one project, and it was quite horrible, but that time it was more due to misusage of RX than it was the fault of RX itself. The second time I've used it in a big commercial project it was used well, and that remains the best codebase I've ever worked with. Super easy to reason about, extremely performan…

I am big fan of FRP with Java and RxJava/Reactor. When I learned about it three years ago I practically got drunk on it.

I think the issue is, the more power you get the more you have to be vigilant and more effort into ensuring the power is used wisely. The first project I joined that used RxJava learned this lesson very painfully.

In my projects I am ensuring some standards on how APIs are constructed and expected to behave so that composing large reactive systems is not getting out of hand very quickly.

Another problem is the steep learning curve for people who learned to mostly copy/paste code from Stack*. You can create very quickly what would normally be a very complex application with just few lines of code of Reactor, but it is not for free -- you still have to understand what it all does and how it all works or you will face consequences at some point.

Re: Functional Reactive Programming

#65

Post by shinzui »

InflexHQ wrote: post #15

I'll be adding this to Inflex ( https://inflex.io/ ), I have the design worked out on paper. (But I'll be open sourcing it first and releasing as a desktop app, and then get back to dev.) It's also helpful to think of FRP in terms of "push" and "pull" (for which there's a related paper by the same chap). This refers to control flow. Behaviours are "pull" i.e. your program has to pull from them. Events are "push" i.e.…

I got the impression that you're already using FRP for inflex.

Re: Functional Reactive Programming

#66

Post by 62951413 »

cybrox wrote: post #23

As someone who had to maintain two applications written entirely using the FRP Paradigm (Rx in Kotlin/Swift with a heavy focus on FRP principles), I am fascinated the idea but I absolutely hated the experience. Writing behaviour flows can end in beautiful blocks of easy to understand operations. However, as these get more complex and you need to combine multiple data streams, logic is scattered all over a module. Ref…

That's basically my Akka (akka-streams/Alpakka specifically) experience. When it works it's great and terse. If it occasionally hangs in the middle of things good luck finding that one timeout parameter you need to adjust. Also, not all people who actually use Actors bother to draw a large FSM diagram.

Re: Functional Reactive Programming

#67

Post by dfee »

Is it viable to build a traditional web product/company on top of Haskell?

That sounds like a silly question - but I’m serious. I’m enamored by the beauty of FP, but I’m not sure if there’s enough tooling or libraries to get to market.

For example - GraphQL. There are two packages (mu and morpheus), but neither clearly document their feature parity in relation to other packages for other languages - and things like dataloaders.

The Reddit almost encourages people to use a different language, too.

Re: Functional Reactive Programming

#68

Post by carapace »

miggol wrote: post #18
BoumTAC wrote: post #5

I learn FP throught ELM and I really enjoyed it. Unfortunately the language seems dead. What are the easiest FP language to learn ? I checked multiple time Haskell but it seems really hard

So sad to hear that Elm appears to be dead. It really excited me at first but I guess that like many I never made the time to give Elm a serious attempt. For me, learning Racket was not too hard. The offical learning materials are excellent, although they are also meant for programmers starting from zero. For me that meant that I occasionally skipped over parts I considered "too easy" only to be confronted by my hubr…

Elm isn't dead. It's in that happy place of stability, people are getting things done with it w/o hassle or churn.

I've heard that an Elm-to-native app compiler is in the works somewhere, which IMO is very exciting.

Re: Functional Reactive Programming

#69

Post by brabel »

rstarast wrote: post #25
BoumTAC wrote: post #5

I learn FP throught ELM and I really enjoyed it. Unfortunately the language seems dead. What are the easiest FP language to learn ? I checked multiple time Haskell but it seems really hard

I have high hopes for the young Gren fork of Elm https://gren-lang.org/ .

It was pretty obvious that at some point, someone would fork Elm, given how Elm has always preferred purity over practicality... but it's not clear how this fork improves things even after reading the (tiny) documentation... can you expand on that?

Re: Functional Reactive Programming

#70

Post by coding123 »

cybrox wrote: post #23

As someone who had to maintain two applications written entirely using the FRP Paradigm (Rx in Kotlin/Swift with a heavy focus on FRP principles), I am fascinated the idea but I absolutely hated the experience. Writing behaviour flows can end in beautiful blocks of easy to understand operations. However, as these get more complex and you need to combine multiple data streams, logic is scattered all over a module. Ref…

I have the same experience. I remember when I was first introduced to Rx(JS in my case) it was really fun to compose async flows. I kept having to explain it to others and they would sort of scratch their head. Eventually we stopped using it. A year later I found some code still using it, and to my own amazement, I was having trouble understanding it. Lightbulb. It's like perl - it's write only.
Post reply on HN