Thoughts on WWDC 2019
The future is very promising and here are my primary reasons:
- ReactiveX has lost the debate on `Error` event type generic specification
- Expect less mudball mish-mash architecture-less cancer-code in the Darwin application programming.
- MVC family of architectural approaches is to die out in GUI programming being inferior to FLUX.
ReactiveX has lost the observables error type debate
In the Apple programming world there has been a debate. Should the reactive programming framework propagate errors as:
- A most common generic Exception-like type
- Strong well defined as deep as possible type defined by the programmer
And there you go: `ReactiveCocoa` being at times more or less popular did the second thing, where its `Observable` required 2 type parameters, second of which was the type for the `onError` event. ReactiveX, being a more generic, semantically portable concept available for numerous platforms pulled the first way.
On WWDC 2019 the Combine was announced and it allows the programmer to pick the type of which the `onError` events are.
Now bare with me and skim through the ./Documentation/DesignRationale.md in the official GitHub RxSwift repo. What you are guaranteed to notice is the argument of error type mis-alignment, in that if you have two observables with event type Event1 and Event2 and a new observable produced by a merge or combineLatest operator having an event type Event3, you introduce the second type parameter and it suddenly needs to have Error1, Error2 and Error3 as well a full pledged set of operators to map one into another. I will quote the same doc here:
Rx isn’t concerned with why a sequence fails
Oh, my dudes, but you know who is concerned with why a sequence fails? The very sodding programmer who is writing the software. You error handling patterns are manageable if you are propagating the errors in a fall-through as long as the software you are writing is not GUI. I know for myself, if you would like to quickly parse reddit and post on Facebook using GraphAPI, your number one rapid development approach is async/await, Promises.all and Linux process calendar scheduling.
But the very first time you actually decide to stop using generic, thoughtless, theory-only concepts like NSError or EcmaScript Error or .NET Exception, you realize that transparent error typing of a programming framework doesn’t help the cause. The fun bits of code include a service:
and another service that depends on it:
Notice the finicky bit with the assert in the catchError clause.
Alternatively, you could you the Alamofire-alike Result type, with child service being:
and the user-service being
Now, keep in mind that Reactive extensions is a technology not native to the Darwin platform. As noted before, the Foundation has it’s own business logic weak primitive called NSError with an integer status code and a string error domain. But as malicious and unusable it is to rely on localizedDescription , note that Rx got its habit primarily from Rx.NET, RxJava and, now dead, pre-5.0.0 RxJS. Error in the EcmaScript is actually a class with a message property and stack-trace on construction retriever. Already this object should be constructed with a message that is fully localized and is ready to be presented to the user. It loses a hell of a lot of specifics of the error, the whole depth of what exactly happened and writing legit code against this already human readable serialized format is painful. Additional cases cover presenting some kind of errors in one way, and some in another. Also, what if the localization message should already be determined by the error data produced by execution context 3 or more layer prior? Building trees of errors is a stem in modern, robust exceptioning and that is why I went out to formalize UnityError and apply it in all of the projects I am currently working on.
Also, the Swift 5 Result type and the explicit exceptioning of Swift where you are forced to indicate whether if a function can throw and all the places where it does actually throw. I am having this impression that engineers at Apple are bothering to limit the usage of problematic and debatable language tools and help the community self-improve the code base, portability, architectural concerns and make software right for once.
The net technical debt of the whole Earth population is estimated 17 quadrillion man-hours in 2016
The stat’s made up, lol.
The money is filth. The money motivates competition, the businesses need to output products faster, the whole application programming environment is totally shortcuts-shortcuts-shortcuts. A lot of programmers writing the software to date tend to be weak at SAD, layering, testability, software complexity management, SOLID, elementary DI. And one of the culprits to this mess in my opinion is the complexity of the imperative nature of the NextStep’s Cocoa foundation which by 2019, 4 years into the FLUX boom in the frontend web development, is already to be considered ancient tech, on the same shelf as GTK3 and MFC. You can still treat FLUX wrong by, for instance, having watchers in your framework, but if declarative layout is not a win-win in terms of architecture, at least it’s more bug-free just because of how much hand-holding it is. If you are new to FLUX state machines, you should definitely watch one of the first facebook’s conference lectures on it. But basically, it will force you to interpret and mutate the state as a whole and avoid cases of fragmented state discrepancies, one of the more common reasons why programmers tend to bind the business logic and views so tightly in the CocoaMVC.
The FRP wins again. Now Apple introduces reactive programming out of the box and even makes its new cross-platform GUI framework FLUX-alike. Anyone ever saying that reactive programming is not needed and only makes things unnecessarily complex is either just a noob or has worked only with the worst samples of it, confirmed.
Oh, and it’s not that classic MVVM with Clean elements as I am personally used to. Yet another non-MVC UI framework supported by the big guy. I am betting that the MVC era is to end at some point in the GUI programming.
