24 ms·
> FRP is a plague on the industry, and everyone is going to figure that out in a couple years. Why is FRP/Combine bad? What is better?
by mlajtos 5y ago
> FRP is a plague on the industry, and everyone is going to figure that out in a couple years.
Why is FRP/Combine bad? What is better?
- skohan 5y agoIt's bad because it obscures flow-of-control from the programmer and surrenders it to a large opaque system. In some cases it makes things a little bit easier, but when things go wrong it's a nightmare because your stack traces are no longer meaningful and flow of control is at arm's length and it's not easy to trace who's calling what. Not that it can't be handled well or used to good effect, but the idea of wandering into an unfamiliar FRP-based codebase which has been in the hands of multiple non-expert maintainers over a couple years is really the stuff of nightmares. edit: answering what's better Normal flow of control is better. You want to be able to look at a function, and see which functions are called from inside that function. And you want to be able to search all instances and see every place where a function is used. You don't want to have some black-box scheduler who's calling all your functions for you. That's how you end up with mysterious action at a distance, becuase you didn't know about the extra subscriber your colleague put on a publisher somewhere else in the codebase, or something strange happening because of an order-of-operations issue which is difficult to understand.
- mlajtos 5y agoAren't result builders just function calls with implicit do-notation? I kinda agree that SwiftUI runtime uses a lot of opaque magic and documentation is still under-par. However, I am very glad Apple went the React way – I tried UIKit after I was writing React for few years and it felt very dated and laborious. Yeah, React isn't FRP, but declarative UI with code FTW.
- twic 5y agoI'm not familiar with this, so googled it, and the third hit was skohan giving dire prophecies about it two years ago: https://news.ycombinator.com/item?id=21011917 https://news.ycombinator.com/item?id=21011917
- skohan 5y agoYou may be able to tell I am not much of a fan of FRP ;) But to be fair, the comment you linked is not a prophecy it was a lamentation
- jen20 5y agoHow many years counts as the "couple in which everyone will figure this out" though?
- skohan 5y agoMany people have already figured it out. I would imagine a few years after SwiftUI becomes the primary UI stack used by iOS developers, many of them will be cursing Combine's name, as it will be clear most of the problems making iOS developers' lives difficult will be coming from FRP.
- jonhendry18 5y agoI'm sure the App Store, code signing, and bad dev docs will find a way to retain the lead.
- skohan 5y agoThose are things you have to deal with once in a while, and largely cease to be issues once you get over the learning curve. Bad code is something you have to deal with day in and day out.
- ironmagma 5y agoIt’s a classic solution-looking-for-a-problem. Async/await is perfectly fine for state reaction, and the learning curve for FRP is enormous, especially for something as straightforward as exponential backoff. https://github.com/alex-okrushko/backoff-rxjs https://github.com/alex-okrushko/backoff-rxjs