are a classic means of storing trees of data. Part of the original Lisp
specification, they have been a part of software engineering since the very
beginning. Other languages, notably Scheme and, more recently, Clojure, have
helped maintain the relevancy of this very simple means for representing data.
In the spirit of
Greenspun's tenth rule,
we are going to attempt make first-class s-expressions in Ruby. There is
of s-expressions in Ruby, for reference, but they are not first-class, which
makes them less than ideal. As such, we are going to to see how far we can
push (read: abuse) the dynamic nature of the Ruby language, and investigate
just how much control we have over certain elements of its syntax.
For anyone more interested in the result than the journey, be warned that this
attempt will not be successful, but some interesting results will be found
along the road to ultimate failure.
Directives in AngularJS are an exemplary solution for writing reusable
components in modern web applications. They allow us to encapsulate all the
messy business logic and expose a very clean, declarative interface to consumers
of the API. As with most tools for constructing abstractions, however,
directives have certain limitations that can lead to implementation details
leaking through, resulting in code that less
and, consequently, less maintainable.
There are, however, ways to work around these shortcomings and to build
simpler, more expressive interfaces to our directives. Leveraging a lesser known
logic. This method is also well suited for building on top of third party
directives with a complex API by abstracting the details into a business
object. In doing so, our markup will become more in line with the ideal in
promotes declarative code
over imperative. Without further ado, let us look at the current situation and
how we can improve our directives.
Motivation and Background
In the process of writing larger applications in
I find it far too easy to initially focus on one small part of the problem
while losing perspective on the bigger picture. For instance, I will begin by
rendering a simple scene, followed by splitting out components, and finally
adding in signals. While this is generally a good approach, in my mind,
it is sometimes difficult to retrofit patterns onto the basis of the application
I have already written.
There are some really excellent resources covering the architecture of applications
in the Elm language. The
on the subject can be found on the official Elm site and covers everything at
a high level. The best example is likely
ported to Elm which uses many the concepts from the article to create a rich
and simple interface, showcasing just how powerful Elm is. Another great and
extremely polished example is
which also incorporates the separation of components as outlined in the original
In this article, we will walk through the steps for writing an implementation
Conway's Game of Life
Elm programming language.
In doing so, we will learn about the basic principles involved with writing
programs in Elm, while grounding them in a concrete problem. We will be
building a single program in steps, so much of the source will be repeated
between the examples, but it will be more clear to present each step in its
I first became interested in Elm after seeing Evan Czaplicki's
mloc.js 2013, where he presented an overview of Elm and the compelling example
of how one would write a simple side-scroller in an extremely straight forward
fashion as a consequence of the core concept in Elm: signals.
Lazy Evaluation and Recursive Lists
In Haskell, it is possible to construct infinite lists via recursive
definition. This is only possible because Haskell uses
rather than eager evaluation. Otherwise, the entire list would need to be
calculated and the program would never terminate.
Because Haskell makes it easy to define lists and is lazy, the code for
defining an infinite series is very simple. The following list represents
the fibonacci sequence.