Reactive is garbage:
1. Has no point. Literally no reason for ovbservables over promises/events.
2. Very difficult to debug.
3. All the "good" things, like pure functions, are not exclusive to it.
An introduction to Reactive Programming
71–78 of 78 posts
Re: An introduction to Reactive Programming
#72Earlier quoted context omitted.
So its like an rxjs BehaviorSubject?
Not quite sure, haven't looked into rxjs much. We were running on an embedded micro with 256KB of RAM, so just making everything async and callback based was already pushing the boundaries of the industry. Vendors we worked with got extremely confused when we said they needed to hand us async code, that they had a few milliseconds to run in before they relinquished control, and that busy loops were verboten. I really…
There is ZERO utility to using observables with a registration form. Zero.
Re: An introduction to Reactive Programming
#73My shop specializes in multiplatform FRP applications via the reflex haskell library [0]. After many years of wrangling FRP my biggest learned lesson is certainly this: not everything is a stream! You need to be able to mix streams (also called events), which embody push semantics and behaviors (things you can sample), which embody pull semantics. This is important for performance and for the structure of large appli…
> After many years of wrangling FRP my biggest learned lesson is certainly this: not everything is a stream! You need to be able to mix streams (also called events), which embody push semantics and behaviors (things you can sample), which embody pull semantics. I have a creeping suspicion that after a few more years, "push" is just going to be viewed as codata, and "pull" will just be "data". I mean, that's kind of w…
The intuition is close but it's not quite the same duality as between data and codata. It's probably true that Behavior and Event are dual but they should be viewed more like modalities than as data structures. In fact, a first cut at semantics for FRP is temporal logic which has modalities like "sometimes" and "always".
Re: An introduction to Reactive Programming
#74> If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article Thanks for actually writing. Written information can be parsed non-linearly, which is super important for learning and reference. For whatever reason, a lot of people don't seem to understand that, and just put out videos, which are like lectures: helpful, but frustrating.
Both can be useful - especially if video is with live coding. Texts often omit the small details that are perhaps obvious to the author, but you are not aware of them. IMHO every installation instruction out there that takes more than copy&pasting 2 lines of text should be in a form of a video, because there's always that one step that is not in the text...
"Well, obviously, you needed to press CTRL+Q+F4 between steps 2 and 3, it's so obvious we don't even need to put it in the instructions."
Re: An introduction to Reactive Programming
#75What should we call original FRP now since Stream/Flow based programming has highjacked the term?
Re: An introduction to Reactive Programming
#76> If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article Thanks for actually writing. Written information can be parsed non-linearly, which is super important for learning and reference. For whatever reason, a lot of people don't seem to understand that, and just put out videos, which are like lectures: helpful, but frustrating.
> For whatever reason Just a wild guess, but that reason could be that ad monetization works way better on videos than static pages and are more likely to garner subscribers to build a following.
That's an excuse, not a reason.
Reasons are dependencies. Excuses are orthogonal.
Re: An introduction to Reactive Programming
#77> If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article Thanks for actually writing. Written information can be parsed non-linearly, which is super important for learning and reference. For whatever reason, a lot of people don't seem to understand that, and just put out videos, which are like lectures: helpful, but frustrating.
Both can be useful - especially if video is with live coding. Texts often omit the small details that are perhaps obvious to the author, but you are not aware of them. IMHO every installation instruction out there that takes more than copy&pasting 2 lines of text should be in a form of a video, because there's always that one step that is not in the text...
It also helps to actively do the thing the way you expect the reader/viewer to do it, so that you don't skip any steps, and you understand common pitfalls.
The problem with doing that, however, is that you are doing something a specific way, on a specific platform, using specific tools. That can make it frustrating or even impossible for viewers/readers to break out of your specific workflow/tools/platform, which is usually what they want to do.
Re: An introduction to Reactive Programming
#78I really liked Kris Kowal’s general theory of reactivity [1]. It’s a pretty in depth explanation of reactive programming in JavaScript that I found really illuminating. It goes through many different kinds of asynchronous data types and compares them to their synchronous counterparts along the way.
[1]: https://github.com/kriskowal/gtor/blob/master/README.md