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…
Last year at around this time, Github announced ReactiveCocoa. I was excited to see a Functional Reactive Programming framework made for Objective-C and found an immediate use for it in an iOS project. Since its release, there’s been a tremendous amount of activity, documentation, and blog posts around it.
The point being, there isn’t an excuse not to use it anymore, and I’d argue that it is (excuse the reference) the Rearden Metal of Objective-C frameworks. It will significantly improve the structure and reduce the complexity of your code. It removes the need for the delegate pattern, continuation-passing style programming, and (most importantly) keeping track of state.
Read more on ReactiveCocoa: The Future of Cocoa Programming…
I recently attended RubyConf 2012 in Denver, CO. I had a great time, and I learned a lot. While getting a clearer picture of the Ruby development community was interesting — particularly the tension among MRI, JRuby, Rubinius, etc. — the talks I keep thinking about were essentially language-independent.
Read more on RubyConf 2012 Reflections: Bad Code Is a Symptom & Keeping Your Business Logic Functional…
The way that programmers and mathematicians work seems to be very different. Programming is about making computers do something, whereas math is about describing things. Programming involves state that changes over time, whereas math deals with Platonic theorems that are always true, even if not proven yet.
But, in fact, the Curry-Howard Isomorphism states that there is a very direct correspondence between basic logical concepts (namely, propositions) and basic programming concepts (namely, types). This correspondence has been known for a long time, but it is only recently that it has begun to creep into the actual practices of programmers and mathematicians alike.
Due to a recent advance in mathematics called Homotopy Type Theory, programming and math are about to be unified on a practical level in a way that will fortify their strengths and overcome some of their respective weaknesses. Read more on Unifying Programming and Math – The Dependent Type Revolution…