Since I originally learned about and tried Elm in 2013, a lot about the language has changed. Elm and I have grown distant and close several times over the years, each encounter being more pleasant than the last, but always ending somewhat abruptly and falling a bit short. After our most recent reunion, however, I feel as though the language has matured to a point where I am empowered to really move forward with the larger projects I began several years ago.
The purpose of this article is to elucidate some topics that were not abundantly clear to me as an effectively new Elm user. It builds from real problems I have encountered while writing real programs, and the solutions I devised to address those issues. These techniques revolve around how we compose and decompose types to make our programs more maintainable.
before we move forward with the specifics, I would like to take a detour through my history with Elm as a way to frame the present discussion.
Encapsulation and information hiding, are well known principles in object-oriented programming, common mechanisms for maintaining DRY code and enforcing the single responsibility principle. While these foundational elements imbue the programmer with significant expressive power and are essential for writing software with possessing anything more than a semblance of maintainability, they sometimes introduce restrictions that are ultimately antithetical to those goals. We, the writers of code, should, therefore, have a solid understanding of not only the standard use of these core object-oriented principles, but also, and, perhaps, more importantly, where they break down in addition to how and when to work around them.
We will look at the ways in which we are able to subvert typical safety nets, and this exploration of various means for exposing otherwise private members will also serve as an introduction to some features of the Ruby programming language less frequently encountered in day to day practice. We will, ultimately, introduce additional safety to objects that traditionally have little, in an attempt to limit the use of our newfound powers for good. Let us begin by looking at the three levels of visibility available and how they are used via a concrete, storybook example.
In a previous article, we explored how to write Conway's Game of Life in the Elm programming language. This example was predicated on one from several years before and compared the differences in Elm over the intervening period of time. Today, we will add some entirely unnecessary features to the simple version of the program.
This exercise in gold plating will serve as a means of probing what it feels like to add new features to an already established Elm program; these microcosmic changes will, hopefully, be reflective of maintaining larger applications in Elm. Throughout the course of this article, we will consider successive diffs, starting from the original implementation, while moving toward the final version.
Today, we are going to look at a straightforward real-world problem, and build a comprehensive solution. In doing so, we will start with some various naive approaches as we increase our understanding of the underlying mechanics, encounter some pitfalls, and, ultimately, approach a reasonable level of sophistication and abstraction. The stack we will be using for this case study is Ruby on Rails 5.1 with PostgreSQL 9.6 for the database.
Now, let me present to you the problem through which we will frame this discussion: given a number of student records, when displaying a single student, also display the quintile into which their grade falls.
This is the first in an ongoing part series exploring the possibilities presented to the programmer when continuations are a first class part of a language. These articles follow Chapter 20 of Paul Graham's venerable treatise On Lisp.
While a powerful semantic construct, there is no secret that continuations are, for good reason, thoroughly reviled. In short, give us the ability to store the state of a computation and return to it at a later point in the execution of our program. This form of non-local return (or jump anywhere) can be compared to goto statements of old or try/catch semantics commonly seen today. Both of these language features, in fact, can be implemented in terms of continuations, and in section 5.8.3 of The Ruby Programming Language, the authors construct a BASIC inspired goto function. Today, when we require 'continuation', the interpreter will kindly inform us that 'warning: callcc is obsolete; use Fiber instead'.
With continuations framed in this way, it should go without saying that, under no circumstances whatsoever, should these curios be used in anything with any degree of seriousness. Why, then, should should we even bother? Sometimes, the simple fact that we should not is enough to make it worthwhile.