This article focuses on different limitations of the Reactive Extensions implementation of FRP paradigm.

Reactive Extensions is a family of frameworks that allow for functionally-reactive programming in imperative programming languages. One of the greatest factors that allow us to treat all of the implementations as a part of one family is the fact that all of them bring identical concepts to the table, which is reflected in similar primitives naming, operators semantics and life-cycle control tools. The advantages of x for commercial projects include:

1. Seamless asynchronicity
2. Transformation atomicity
3. Use-case configurability

Right now we will, however, take a tour on 3 aspects of Reactive Extensions that showcase the limitations of the modern popular implementations. …

In this article, I would like to discuss the concept of an adventurous and thoughtful error handling in a modern iOS application.

The concept consists of two major aspects:

1. Building error trees
2. Producing the user-friendly error state visualization lazily

All the code presented in this article can be found and fiddled around with here.

Error tree is a compound data structure that is designed to make it easy to see what exactly is the reason behind a failure of a complex operation.

— literally me, writing this very article.

The main premise here is to treat your error objects as regular models, identical to the objects that your view would use to configure itself during positive, error less use case. This emphasis dictates that the creation of an erroneous model to be used by a view may or may not be just as complex as a creation of any other model. In a typical heavyweight architecture you would see that the creation of a model that view sees is preceded by some intermediate steps such as creation of an abstraction over the network’s response, a so-called “data transfer object”, that encapsulates the deserialization logic while not carrying anything related to the business rules of the application. …

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

Swift is a great language to write applications in. However, being more or less proficient in numerous other programming platforms, one will of course acknowledge that one of the most flexible and truly powerful programming languages out there is ECMAScript. In this article I am going to talk about such a syntactic construct as the anonymous class. Consider this little gist.

This one is not the class in its entirety, but just the dynamic behavior I would occasionally end up looking for while working on a project. …

Me and my wife are both web developers. In fact we’ve started dating while doing a project together. I guess you could say that we MERGED WITHOUT CONFLICTS.