Hacking S-expressions into Ruby

Background

S-expressions 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 already a nice implementation 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.

Continue reading

Using Defined Properties for Better AngularJS Directives

On Directives

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 DRY 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 feature of JavaScript, we can encapsulate additional details of our business 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 AngularJS, which promotes declarative code over imperative. Without further ado, let us look at the current situation and how we can improve our directives.

Continue reading

Barebones Architecture in Elm

Motivation and Background

In the process of writing larger applications in Elm, 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 canonical article on the subject can be found on the official Elm site and covers everything at a high level. The best example is likely TodoMVC (source) 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 Dreamwriter (source), which also incorporates the separation of components as outlined in the original article.

Continue reading

Writing Game of Life in Elm

Introduction

In this article, we will walk through the steps for writing an implementation of Conway's Game of Life in the 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 entirety.

I first became interested in Elm after seeing Evan Czaplicki's talk from 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.

Continue reading

Lazy Ruby

Lazy Evaluation and Recursive Lists

In Haskell, it is possible to construct infinite lists via recursive definition. This is only possible because Haskell uses lazy evaluation 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.

Continue reading