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

91–100 of 121 posts

Re: Functional Reactive Programming

#91

Post by mncharity »

jfoutz wrote: post #61
zmgsabst wrote: post #49

Earlier quoted context omitted.

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 give…

Having a state algebra can also help with speculative execution, as when doing FRP-like complex event processing on human input device streams, while preserving responsiveness despite diverse latencies.

Consider doubleclick. After a click, rather than pausing for 30 frames to see if a second click eventually shows up, you can act immediately, and if there's later a second click, retract and rerun with a doubleclick event.

With incremental speech recognition, interpretation of past words can change as a sentence progresses, so "Launch the missiles!" can replay as "Lunch is mussels! In butter!".

Keyboard and ml-based visual tracking have very different latencies. So when combining them (eg, which finger pressed the key, where on the keycap, and what were any other vision-derived key modifiers), you can pursue a guessed-at transition immediately, and then correct if needed when tracking finally coughs up the hand pose.

Edit: Hmm. Well... having "retractable state transitions". "Algebra" has other implications. Edit edit: s/reversible/retractable/ - sorry.

Re: Functional Reactive Programming

#92

Post by marcosdumay »

dllthomas wrote: post #74
marcosdumay wrote: post #63

Earlier quoted context omitted.

You mean interactive? I don't see how FRP helps with real time.

I expect the parent means having some portions of the output change without user input, which isn't either of those if we're being picky.

Hum, I'll complain about calling it "being picky". We are up to 3 completely different theories about what the GP meant, and no way to tell them apart.

Re: Functional Reactive Programming

#93

Post by slowmovintarget »

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…

Your problem seems to be with static typing, not FRP.

Re: Functional Reactive Programming

#94

Post by yakshaving_jgt »

dfee wrote: post #67

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 d…

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

Yes. I've been doing it for years. I also employ several Haskell developers.

We're happy.

> I’m not sure if there’s enough tooling or libraries to get to market.

There are.

Re: Functional Reactive Programming

#95

Post by yakshaving_jgt »

hiptobecubic wrote: post #75
dfee wrote: post #67

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 d…

I have never tried, but my impression is basically "You could, but why would you?" Haskell had a big jump in popularity around a decade ago, but it didn't gain traction with the "i'll grind 17 hours a day to become a rockstar ninja whatever" demographic that every language seems to bootstrap itself off of. I won't speculate as to why, but the end result is that Haskell is missing a lot of "adapter"-style libraries an…

> The benefits of Haskell don't even _really_ seem that useful when you're just writing yet another big ass crud app where the main goal is to convert json into some other json and then maybe render it.

The benefits have been massive for me, and I'm often doing basically this.

Maybe you should just try it?

Re: Functional Reactive Programming

#96

Post by yakshaving_jgt »

brabel wrote: post #69
rstarast wrote: post #25

Earlier quoted context omitted.

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?

> Elm has always preferred purity over practicality

Elm preferring purity is its practicality.

Re: Functional Reactive Programming

#97

Post by jfoutz »

mncharity wrote: post #91
jfoutz wrote: post #61

Earlier quoted context omitted.

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 give…

Having a state algebra can also help with speculative execution, as when doing FRP-like complex event processing on human input device streams, while preserving responsiveness despite diverse latencies. Consider doubleclick. After a click, rather than pausing for 30 frames to see if a second click eventually shows up, you can act immediately, and if there's later a second click, retract and rerun with a doubleclick e…

Yeah. Java swing early on actually paused the event loop waiting for a second mouse click to return a double click. If I recall, some platforms would drop those events while paused, others would queue them. I think X dropped, windows didn't. this caused some workarounds smeared across the codebase.

It's never going to be easy, and somebody has to pick the "right" answer. With more structure, you can get more consistency. I may not like the answers, but they're consistent answers and so I can reason about them.

Reversible state transitions is a whole other bag of mixed metaphors. But I'd still say, more structure makes it consistent, and then you can reason about it, and then you can maybe solve some of those cases.

Re: Functional Reactive Programming

#98

Post by tasuki »

immigrantheart wrote: post #29
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

OCaml fits the bill for me. It is an amazing language, very practical, fast, and easy to code with. It is a shame that I didn't discover OCaml sooner. FWIW, I tried Elm, Haskell, PureScript, Elixir.

What were some drawbacks of PureScript, or why do you prefer OCaml? I've only ever used Elm and Haskell, but been eyeing PureScript recently...

Re: Functional Reactive Programming

#99

Post by dllthomas »

marcosdumay wrote: post #92
dllthomas wrote: post #74

Earlier quoted context omitted.

I expect the parent means having some portions of the output change without user input, which isn't either of those if we're being picky.

Hum, I'll complain about calling it "being picky". We are up to 3 completely different theories about what the GP meant, and no way to tell them apart.

"Discerning"? :)

Re: Functional Reactive Programming

#100

Post by andrekandre »

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 think an issue is that most "apps" are just CRUD and the "reactive" parts end up just being used to propagate the READ part to the ui, but this can be handled by promises most cases (ime) just fine

the other part is the UPDATE from the ui to the model, again this can be handled by simple callbacks and refresh the ui again with promises

there are some nice features of these libraries but most of it goes unused because most apps don't actually need all that power/complexity (sadly i suppose)

lastly, (ime) many devs also don't seem to know how to program data flow in a single direction which gets really hairy because now everything is reacting to everything and fixing one thing breaks another....

Post reply on HN