A lot has been written about the benefits of functional programming, but little of it is accessible to a newcomer. Some of the benefits are easy to understand from an inexperienced perspective (e.g. “it makes concurrency easier”), but others are pretty nebulous.
Chief amongst the inscrutable properties of functional programming is its “elegance.” It isn’t immediately clear what that word actually means in this context. Read more on A Simpler Case for Functional Programming & “Elegant” Code…
TypeScript can help you with its
readonly property modifier. With
readonly, you can rely on TypeScript’s static analysis to enforce and flag mutations in your codebase.
Read more on Understanding and Embracing TypeScript’s “readonly”…
Generators are an ES6 feature that started receiving a lot of attention a few years ago because of their potential to ease some of the pain associated with writing asynchronous code. However, with the emergent async/await proposal (mere syntax sugar around generators and promises), some of the shine has worn off, and generators aren’t getting the same amount of attention they used to.
This is a shame, because even if you disregard their uses in asynchronous code, generators are still pretty cool in their own right. I’m going to explore some of the ways you can use them to implement lazy sequences.
Read more on Lazy Sequences with ECMAScript 6 Generators…
The Elm architecture is a simple and straight-forward alternative to the common model-view-controller architecture, and it’s well suited to functional programming.
In brief, the Elm architecture uses a data structure to render a UI, the UI fires actions, and actions are used to update the data structure. This is the same sort of uni-directional flow that React.js uses and the one that Ember.js has been gravitating toward in place of two-way data bindings.
Read more on Implementing the Elm Architecture in ClojureScript…
RSchema-Hamster is a Ruby gem that lets you use Hamster’s persistent data structures to define and validate the shape of your data via RSchema.
In order to clarify my designs, reduce mistakes, and leave code easier to change than when I found it, I:
Read more on RSchema-Hamster: Schemas for Shaping Immutable Data…
On my current project we are using ReactiveCocoa to manage Core Bluetooth’s asynchronous callbacks when communicating with a Bluetooth Low Energy device in an iOS app. John Fisher recently explained how he’s used ReactiveCocoa to chain asynchronous operations together in this same project.
As with any application that communicates with a remote device/server, we’ve run into the need for timeouts when we don’t get an expected response in a reasonable amount of time. This got me to wondering if there might be something built into ReactiveCocoa to help with this problem. And it turns out there is! There’s a
-timeout:onScheduler: operator available for use on any RACSignal. In this post I’ll show a simple example of how
-timeout:onScheduler: can be used to manage a long-running asynchronous task.
Read more on Timeouts in ReactiveCocoa…
Dealing with asynchronous operations is a common problem in mobile development. To keep our app’s user interface as fast and responsive as possible, we need to offload network requests, resource loading (e.g., images), bluetooth operations, and file I/O onto a background thread.
Calling one asynchronous routine and responding to its result is a relatively simple matter, but what happens when several different asynchronous operations must be executed in some set order (serialized)? Apple has built in support for queuing asynchronous operations with
NSOperationQueue and Grand Central Dispatch, but there’s another solution: using a functional reactive approach with Reactive Cocoa. Read more on Easy Asynchronous Operations in iOS with ReactiveCocoa…
Partial application is awesome. I love it. Same goes for functions as first-class citizens. I wish these were features in every language. I’m working in Ruby right now, and every time I use
reduce(), I find myself wishing I had them.
-1 * x
def add(x, y)
x + y
obj = MyClass.new
values = [1,2,3]
# this is needlessly verbose
values.map do |val|
end # [-1, -2, -3]
# this is disgusting
# Ruby, why u no allow this?
values.map(&obj.negate) # although dropping the & would be even better
# And how about instead of this
values.map do |val|
# we could just do this?
Funkify to the Rescue
To overcome these limitations (and because it sounded fun), I started looking for a gem that would help with writing code that supports partial application. Read more on Funkify and Pattern-Proc: Messing with Ruby for Fun (but probably not profit)…
Recently, I’ve been playing with the F# programming language in my free time. One barrier that I ran into was the fact that I don’t have a Windows machine, meaning I had to use the Mono runtime on my Macbook. This presented some challenges that I had to work through.
So, why was I playing with F# in the first place? I had been looking for a language to fix some frustrations that I had with my current toolset:
- Lack of static typing that isn’t painfully repetitive (Java)
- First class support for common functional programming idioms – e.g. immutable by default, option types, pattern matching, etc. (All of the above)
I also wanted to take the opportunity to get some experience with the Microsoft/.NET ecosystem. Since the Microsoft stack is incredibly popular at many companies, including some of our clients, it seemed like a solid bit of knowledge to have. Also, I was excited about the possibility of using the Xamarin stack to create mobile apps with F#. Read more on Running F# Using Mono and Unix…
The less stateful your code, the easier it will be to reason about the effect of a change to it.
Strive to never store state in your components. When you do, let the component do nothing else. An ideal system will be made up, almost entirely, of small, stateless, functional components.
A consummate component is a pure function, meaning it’s output or return value is based solely on its input or arguments. Realistically, any reasonably interesting component will end up delegating to others so as to rely on abstractions instead of details. Keeping the number of these collaborators small is a worthy goal. Some of these calls to other components will cause side effects. Intentionally designating which components make calls causing side effects or changing state will reduce the entaglement components in your system and increase the mobility of those components un-encumbered with such details.
Read more on Less State Begets Better Software…