Credit’s Due: Sean Parent

Jun 20, 2015

When it comes to software development no single person has impacted and influenced me more than Sean Parent; and I’m pretty sure I’m not alone. I was first introduced to his work via a Google Tech Talk that forever changed the way I thought about programming as an effort to create generic standalone solutions. I credit this single talk as being the cause behind my ability to make the CMS I was developing grow by leaps and bounds in terms of flexibility, capability, and minimal installation footprint.

Note: I am not a computer scientist, nor do I play one on TV; so, this article is not necessarily written for that crowd. I am, however, someone who enjoys creating experiences and considers new ways for humans to interact with computers; so, if the code doesn’t work, or has copious amounts of bugs, or crashes all the time, or does something different despite the sequence of events being the same—that’s a bad experience.

A Possible Future of Software Development 1

This talk was my first introduction to the thoughts and concepts Sean is a proponent of; primarily generic programming. The idea behind generic programming is that we should be able to describe a solution to a specific problem. Further, that solution should not care where it is or its environment. In the talk, Sean talks about the aspect ratio calculation for Photoshop and, to try and boil it down, an algorithm should receive everything it needs to generate an expected value independent of the rest of the state of the environment.

Do, huh?!

Right. So, let’s try an example; with the understanding that this is just what conclusions I came to in how to execute the concepts and may not be what Sean was actually driving at. I’ll use PHP, but the concepts can apply to most, if not all, object-oriented-programming languages.

<?php

// A bird
class Bird {
    public $feathers = [];
}

// A feather for a bird
class Feather {
    public $color;
    public $length;
}

// Creating the bird
$eagle = new Bird();

// Creating the feather
$f = new Feather();
$f->color = “brown”;
$f->length = 6;

// Adding the feather to the bird
$eagle->feathers[] = $f;
?>

So, that’s pretty cool. Our eagle now has a single brown feather. But, that can become problematic, for example (same as above with a new line):

<?php

// A bird
…

// A feather for a bird
…

// Adding the feather to the bird
$eagle->feathers[] = $f;

$f->color = “purple”;
?>

Now we could have a problem. If $f points to the exact same object in memory, our eagle’s feather is now purple. Because, even though we didn’t explicitly assign the purple feather to the eagle $f points to the feather we did attach to the eagle. Let’s try a different way:

<?php

// A bird
class Bird {
    private $feathers = [];
    public function __construct($feathers)
    {
        // Note: php uses copy to assign arrays; so, understand
        // the $feathers above, is not the same object as $this->feathers
        $this->feathers = $feathers;
    }
}

// A feather for a bird
class Feather {
    private $color;
    private $length;
    public function __construct($color, $length)
    {
        $this->color = $color;
        $this->length = $length;
    }
}

$f = new Feather(“brown”, 6);
$feathers = [$f];

$eagle = new Bird($feathers);
?>

Now I can change $f and it will have no affect on the feathers attached to our eagle.

I could go on regarding other changes I made to the way I write code, but I will spare you that; in summary, what I did was stop multiplying ways for state to change out from under me, which is what happened when the feather on our eagle went from brown to purple. Essentially, the eagle was not a complete and self-contained entity. Instead, it was an entity with a bunch of references to other entities that could be changed by someone else at any time without going through our eagle first. (I believe this is what another Google Tech Talk was referring to regarding polymorphism and don’t go looking for things, which I didn’t quite understand.2)

This programming concept and methodology about how to reason about code and being able to move something from one system to another without changing anything prompted me to begin writing a SQL generator—as writing SQL by hand is one of the biggest bug houses ever. Basically, writing queries against a database tends to look like this:

SELECT * FROM table_name WHERE column_name = 1 AND column2_name = “something”

So, the SQL generator started looking something like this:

<?php
public $q;

public function query($sql) 
{
    // query the database…
    $this->q = $sql;
    return $result;
}

public function select($table, $where = [])
{
    $sql = ‘SELECT *’;
    $sql .= ‘FROM’ . $table;
    if (count($where) > 0) {
        $sql .= ‘ WHERE ‘;
        foreach($where as $column => $value) {
            $sql .= $column . ‘=‘ . $value;
        }
    }
    return $this->query($sql);
}
?>

I can hear the developer community from here cringing at this implementation, and that’s okay: (1) it’s an example and not the real code, (2) this was over a decade or so prior to this writing, and (3) remember I’m not a computer scientist. The point here is that by developing this query builder in this manner, I was able to put it into any framework or system, connect to a database, and begin querying against the database without having any knowledge of the framework. As a point-in-fact on more than one occasion I had to take the standalone SQL generator and put it into someone else’s framework in order to help debug that framework’s code.

This started me on the path of building a set of classes that would, for lack of a better term, create an object-oriented data model. Whereby, instantiated objects would query the database (a little foreshadowing here) by having the database object give context to the application and each object would use it to query the database—making the database the holder of ultimate truth—and minimize referencing objects that could be changed out from under me.

Which brings us to Objective-C and Swift.

Inheritance is the Base Class of Evil 3, 4

A few years ago I was first introduced to Apple’s Core Data. Core Data was developed to help programmers handle data persistence and storage. At the surface level, it creates a connection to a data store (which could be a SQL database), a context, a coordination system, and objects via an object model graph. Each object is assigned a context, because it’s the context that instantiates the objects; however, after that, you tend to interact with the objects—and those objects will query the persistent store through the calling of methods and properties on them. That was when I hopped off the web as my primary focus for creating experiences and software solutions.

At Apple’s WWDC 2015 there was a session called Protocol-Oriented Programming.5 During this talk, they refer to a fictional character, Crusty. This talk only marginally helped me understand what Apple was driving at. But, I found two other talks by Sean Parent, which explained things that made my head explode. These talks made me almost shout to the heavens, “Sean Parent is Crusty!” For example, in one of the talks, Sean says, “I tell developers, ‘Don’t start with a class, start with a library.’” And the talk from Apple has, “We have a saying in Swift, don’t start with a class, start with a protocol.” The talk ends with the presenter saying, “Be more like Crusty.”

Then I watched Building Better Apps with Value Types in Swift6 and, this time, I did at least say (not shout) out loud, “Sean Parent is Crusty”—at least to me—and I had already wanted to be like Crusty…err Sean.

Between those four talks, primarily the ones from Sean, I was able to see what Apple was referring to with protocols; and, it was a direction I had started going with my own code based on the first talk I saw from Sean.

Again, I don’t know if this correlation is just a matter of the collective unconscious kicking in; or, as we all do, forget that we learned something from somewhere else; or, the fact that Sean used to work at Apple, but the correlation was creepy and blew my mind a bit.

Conclusion

As I begin living in the two worlds of web and Apple platforms, I can see the influence of these concepts I first learned through Sean Parent coming into practice on a larger scale. Finally, these implementations are improving the experience for us all—from developers to front-end users.

Thanks Sean.


  1. A Possible Future of Software Development return to text

  2. The Clean Code Talks—Unit Testing return to text

  3. Inheritance Is The Base Class of Evil return to text

  4. Sean Parent: Value Semantics and Concepts-based Polymorphism return to text

  5. Protocol-Oriented Programming return to text

  6. Building Better Apps with Value Types in Swift return to text

###