Articles in category: Functional Programming
This year, Facile attended for the first time Lambda Days Conference in the beautiful polish city of Krakow.
It has been a two-days full immersion with speakers coming from all over the world.
The latest trends and academic research in the functional world were showcased, spanning from beginner’s approaches to functional languages to highly specific scientific applications.
This conference was totally worth attending, albeit very intense (sometimes mind-bending, actually!). All the talks were of high quality and the organization was perfect.
Maintaining state is the main cause of complexity and headaches in software development: without a careful consideration of state, our projects will inevitably become impossible to understand. In fact, various development techniques and programming styles are mainly there to handle state in a responsible way: for example, monads, as used in functional programming, are often employed for this very task. A good general way of managing state is trying to make it immutable, either through the use value types, that is, types which instances are passed around with deep copy semantics, or simple immutable objects, which have reference semantics but because they’re immutable their state is fixed.
Last time we looked at the Signal class, that is, a simple, reusable way of encapsulating the observer pattern. There are many use cases for a signal, and I’m going to show one possible application, spawned from a real-world problem. View controllers’ composition and decoupling is hard: we often need an input from a view controller, that has to send its input back to its creator, while handling the back navigation somehow. We often find ourselves in a situation in which several different responsibilities are all expressed in a single view controller, with the effect of creating a gigantic class, full of entangled imperative statements, hard-to-understand sequencing and general complexity. We’ll use the Signal class to assign the various responsibilities to different classes, and write cleaner, more declarative code. The core of this architectural pattern lies in inverting the way in which objects communicate, view controller or other: instead of asking objects to do things, we’re going to observe what objects are doing, and react accordingly. Observe and React are the cornerstones of the programming paradigm known as functional reactive programming(FRP); the present article is not going to talk about FRP as a whole, nor to present shared FRP techniques; the point is to discuss an architectural pattern for decoupling view controllers from responsibilities not strictly related to user interaction, by leveraging some basic FRP tools.
Last time we looked at a possible implementation for the Optional type in Objective-C; while the main point was to port to Objective-C a tool that’s frequently used in Swift, making use of the Optional class can be considered an application of a much more general concept: code reuse. In fact, Optional is not tied to a particular domain, and can be reused over and over again in multiple projects: that’s what actually happens in Swift. But, to think about it, that’s what happens for a wide range of classes in Objective-C, or types in Swift: for example, NSArray and Array are both constructs that expose a certain interface, have a certain implementation, and are reused multiple times within methods and functions. And again, NSArray and Array are not tied to a particular domain, and have two important properties:
L’ultima volta abbiamo visto una possibile implementazione del tipo Optional in Objective-C; l’obiettivo primario dell’articolo era quello di importare in Objective-C uno strumento frequentemente utilizzato in Swift, ma usare una classe come Optional può essere considerato un’applicazione di un concetto molto più generale: il riutilizzo del codice. In effetti, Optional non è legato a un particolare dominio, e può essere riutilizzato più e più volte in molti progetti: questo è esattamente ciò che accade in Swift. Ma a pensarci bene, questo è ciò che accade per una grande varietà di classi in Objective-C (e di tipi in Swift): ad esempio, NSArray e Array sono entrambi costrutti che espongono una specifica interfaccia, possiedono una certa implementazione, e vengono riutilizzati continuamente in metodi e funzioni. NSArray e Array non sono legati a un particolare dominio, e possiedono due importanti caratteristiche:
