41–50 of 121 posts
FRP is a fascinating paradigm, but I find I really have to turn my brain inside-out to "get" it. But it's really cool to have UIs that are completely consistent.
The funny thing is that good ole MVC also gave us UIs that are completely consistent.
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
This means that you can learnt he basic concepts of operating on data with pure functions, pattern matching etc. Plus it's a nice language that is great for building a lot of things (Phoenix is a great web framework).
Once you've got some of that background of how you build functional programs rather than OO, moving to something like Haskell or Ocaml is a bit easier because it becomes more about understanding how to declare types to keep the compiler happy and less about the fundamental program design stuff.
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’ve been writing FRP code in JS for years now. Ease of refactoring and total clarity of what is happening (assuming you are familiar with the FP methods, etc) are the biggest advantages. I agree the code can balloon in size, and gets a bit hard to organize at some point, but the self-documenting aspect of it is amazing. I combine an FRP framework (bacon.js) with Ramda. I’ll admit I’ve had trouble working with things…
A single block of statements that transform and handle data in a specific way is indeed almost self documenting, which is really cool.
However, how did this work for you with more complex combinations and transformations?
For example, our codebase had one module that took inputs from multiple different sources (low-level network handling based on a library) and generated a consistent state out of them. To keep the code performant, we introduced some intermediary values, so that certain transformations had to be run less frequent. (this was necessary)
In the end, we ended up with a ~500LoC module. I wrote the same later with async/await and split everything into ~20 functions, which worked really well. The reactive version however, was just a bunch (~15) blocks of transformations, which were somewhat self explanatory in themselves but it was almost impossible to trace the flow of data through the whole module without drawing it up.
Even just naming a block (a function name) helped a lot. Sure, you can document blocks of reactive code, which is what we ended up doing but I felt like the self-document aspect fell apart when I had to write a sentence above every block as to why this intermediary transformation is necessary.
Earlier quoted context omitted.
Yeah, actually really. Actual MVC has the model notifying the UI that it has changed and then the UI updating itself from the model, by pulling data. That's always consistent. We then did all sorts of things that we call MVC, but that do not follow the MVC-defined interaction patterns at all, particularly either the model or other views incrementally poking data into the view. That doesn't work, and it is nigh imposs…
So, what if you have a background process (running in the controller I assume) that updates data in the model periodically from somewhere. And at the same time you have the user making changes to the model. How is consistency guaranteed here by having "UI updating itself from the model, by pulling data"? Maybe I have a different understanding of "consistency" but this might very well lead to undesired results if the…
If you have unprotected multithreaded imperative updates of global data, nothing is consistent. Has nothing to do with MVC or no MVC.
Actually having a consistent state to present to the UI is the model's problem.
Oh, and for goodness sake, don't have any kind of async update process running in the controller. All this stuff belongs in the model.
If you're doing that sort of stuff in the controller, I can see why you're having problems with concurrency. You're also almost certainly not doing MVC.
Earlier quoted context omitted.
Yeah but for a limited subset of desirable functionality. It sucks to use for something where you want a dynamic UI.
Can you elaborate? An example for a feature which would be a real pain in MVC but easypeasy with FRP?
Earlier quoted context omitted.
The funny thing is that good ole MVC also gave us UIs that are completely consistent.
I disagree. The moment my controller needs to "set" or "update" something in the model the whole thing becomes a mess in my experience. FRP requires that you change the way you code but it's 100% worth IMO.
Earlier quoted context omitted.
So, what if you have a background process (running in the controller I assume) that updates data in the model periodically from somewhere. And at the same time you have the user making changes to the model. How is consistency guaranteed here by having "UI updating itself from the model, by pulling data"? Maybe I have a different understanding of "consistency" but this might very well lead to undesired results if the…
This is not MVC's problem to solve. It also doesn't solve global warming. If you have unprotected multithreaded imperative updates of global data, nothing is consistent. Has nothing to do with MVC or no MVC. Actually having a consistent state to present to the UI is the model's problem. Oh, and for goodness sake, don't have any kind of async update process running in the controller. All this stuff belongs in the mode…
Yeah, but that is exactly what FRP solves (or strives to solve) and MVC does not give you on it's own (as you said). Ofc MVC can be used in combination with other techniques to gain consistency, but it doesn't provide it on its own, which is what I believe was implied by your original post.
If you were just talking about the UI in isolation, then yeah, maybe MVC gives you that, but it misses the point of what FRP gives you.
Earlier quoted context omitted.
Elm is not dead. It just prefers a slow release schedule but is still actively worked on in the background. That said, you might want to check out OCaml for general purpose programming. Super fast compiler, great performance, can target both native and JS. It is easier to use than Haskell due to defaulting to eager evaluation (like most languages) strategy instead of laziness and being generally more pragmatic, offer…
> you might want to check out OCaml for general purpose programming Any tips on backend frameworks to look at? I need to write a small websocket service for a side-project and have always wanted to try OCaml. I came across https://github.com/aantron/dream .
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…
Earlier quoted context omitted.
i’ve been writing FRP code in JS for years now. Ease of refactoring and total clarity of what is happening (assuming you are familiar with the FP methods, etc) are the biggest advantages. I agree the code can balloon in size, and gets a bit hard to organize at some point, but the self-documenting aspect of it is amazing. I combine an FRP framework (bacon.js) with Ramda. I’ll admit I’ve had trouble working with things…
Out of curiosity, a lot of people are praising the "self-documenting aspect of [Reactive Code]", and I definitely see why. A single block of statements that transform and handle data in a specific way is indeed almost self documenting, which is really cool. However, how did this work for you with more complex combinations and transformations? For example, our codebase had one module that took inputs from multiple dif…
Because of the enforced formality of how data is flowing around, the ability to split these streams up is trivial in a way that was a revelation to me. In the past, I'd be far less confident that I was going to mess up something unintentionally, to the point where I would maybe not bother.
And yeah, I think it's totally valid to take larger blocks of streams/transformations and wrap in a named function that takes a stream and returns a stream.
Over the years I've gotten out of the habit of always using FRP for every problem. There are many cases where async/await is totally fine and simple. I still always use Ramda, which gives me the same self-documenting qualities (which is really a function of the strictness of FP, not so much the R in FRP, now that I think about it).
But whenever I have to coordinate multiple inputs with different time delays (i.e. multiple AJAX requests or UI input) or process a bunch of data where each item creates its own stream of fetching and processing, the "reactive" bit is extremely handy.