I'm a programmer and code makes me uncomfortable

Well, BAD code makes me uncomfortable.

When I start to write a piece of code, I tend to focus on the functional part of the problem. To just actually solve the problem at hand. That is simply step 1 of development. This is also the most important step. When you write code that doesn't perform the function it is supposed to, then it is literally worthless. Less than worthless actually.

So, now I have a piece of code. Chances are, I am not happy with it. It really makes me uncomfortable. There might be some ugly/non-descriptive variable names, some large methods, incoherent classes. It itches. My stomach turns a little. Things have to be simple, the code should flow naturally. The amount of WTFs should be low. I am not intelligent enough that I can afford having complex code. If it was hard to write, it will be infinitely harder to read later on when I have to track down some obscure bug.

So I start improving the code. Split out a method to simplify a complex piece of code. Improve those variable and method names. Sometimes I remove good chunks of code only to be replaced by some more elegant and simpler piece. Maybe there is a piece of existing code that needs some love. Sometimes there is an ugly piece of code that won't budge. It is the nature of the beast. In such cases I try to be as explicit as possible documenting the piece. I usually try to write as little documentation as possible. I find that when code is well written, it is self explanatory.

Sometimes it is really the design that makes me uncomfortable and I have to refactor large chunks of code. I won't hesitate to do it immediately. It will be worth it in the long run.

I keep doing this until I am happy with the overall quality. The design is right, methods are not too large or too small, no unnecessarily complex pieces of code, no magic numbers etc etc. This makes me happy. The uncomfortable feeling is gone. Now I can ask my colleagues to review what I have written and hopefully they have some insight in how I can improve my code.

Be humble. Be open. Be uncomfortable.

The creative process of software development

This week I faced a technical challenge. One of the modules of an application I have developed didn't behave as expected. Well, in one scenario it works as expected, but it fails miserably in another.

So I started isolating and debugging the code the find the root cause. It's a pretty small application so that didn't take very long. But looking at and playing with the code didn't provide me with an easy solution. It felt like a brick wall. All kinds of complex possibilities kept popping up in my head but they all felt out of place. Big. Clunky. Inappropriate for this particular problem.

I was nearing the end of the day so I decided I'd go home and have a good night's sleep. Usually just taking my mind off a problem gives me the answer. Amazing how the brain works!
While it did give me some new insights I still couldn't mold them into a simple, elegant solution.

Had a couple of meetings. Had lunch. More new insights. Still no solution.

That's when I decided I had to really take a step back and take a different approach. So I closed my laptop, took pen and paper, put on some good acoustic rock and started to design this piece from scratch. Withing 30 minutes I came up with a solution that satisfied my search for elegance and simplicity. Within another hour I developed and tested this solution.


So in the end it took me about 90 minutes to design, implement and test this new solution. Should I have started with and pen and paper in the first place? I don't think so. Because I was working at it for about a day already and had a couple of good new insights I had a pretty good view on the various use cases and requirements. Without this previous investigation I wouldn't have gotten to the solution I have now.


Where would I have gotten if this didn't work either? I would have probably started drafting a question on StackOverflow. Drafting a good question takes a lot of thought and preparation. You have to really understand the problem to be able to ask a proper question. And in this process lies the answer. Only a fraction of the questions I want to ask on SO actually end up being asked. Most of the time I come to a solution myself just by the process of investigating the problem to form the question.


The takeaway for me here is that it is indeed a creative process. Sometimes you have to step back to see things clearly. And that is almost always worthwile to research further before implementing that big, ugly solution. Because usually it can be solved more elegantly. And that always pays off in the long run.

Multiple assignment and variable swapping

It is generally known that PHP doesn't natively support multiple assignment or variable swapping. Multiple assignment can be done by using multiple assignment statements. Variable swapping on the other hand can be done for integers using the XOR trick:

<?php
$x = 10; $y = 20; $x ^= $y ^= $x ^= $y;
echo $x . ' | ' . $y; // outputs: 20 | 10

But as said, this only works for integers. And look at it, it's hideous.

But there is a way that is quite elegant and php-ish. Since 5.4 it has become even better with the short array syntax:

<?php
$x = 10; $y = 20;
list($y, $x) = [$x, $y];
echo $x . ' | ' . $y; // outputs: 20 | 10

I wonder why I didn't think of this earlier!

This might even get better starting PHP 7 or later. Good things!


Happy coding, guys :)

Iterators

Recently I came across a situation where I need to iterate over multiple result sets. Since SPL has a decent collection of iterators I began my search there. So I came across the MultipleIterator thinking it would solve all my problems. It didn't.
The problem with the MultipleIterator is that it doesn't provide a continuous stream of elements of all the attached iterators, instead it 'groups' them. Per iteration you get an array of all n-th elements for all attached iterators.
Given the following piece of code:

<?php
$iter = new MultipleIterator();
$iter->attachIterator(new ArrayIterator(range(0, 5)));
$iter->attachIterator(new ArrayIterator(range(10, 15)));

foreach ($iter as $row) {
    var_dump($row);
}

The output is:

array(2) {
  [0]=>
  int(0)
  [1]=>
  int(10)
}
array(2) {
  [0]=>
  int(1)
  [1]=>
  int(11)
}
array(2) {
  [0]=>
  int(2)
  [1]=>
  int(12)
}
array(2) {
  [0]=>
  int(3)
  [1]=>
  int(13)
}
array(2) {
  [0]=>
  int(4)
  [1]=>
  int(14)
}
array(2) {
  [0]=>
  int(5)
  [1]=>
  int(15)
}

Not exactly what i want. And even worse, all iterators need to be of the same length. It just doesn't cover my use case where I simply want to group a bunch of iterators and interface with them as if it were a single one.

It seems the SPL doesn't provide a solution to my use case, so I wrote my own. This is the implementation I ended up with:

<?php 
class MultiIterator 
implements Iterator 
{
    /**
     * Holds the stack of iterators
     * @var array
     */
    protected $iterators = array();
    /**
     * Holds the index to the current interator
     * @var integer
     */
    protected $current_iterator_idx;
    /**
     * Add a new iterator to the stack
     * @param Iterator $iterator
     */
    public function appendIterator(Iterator $iterator)
    {
        $this->iterators[] = $iterator;
    }
    /**
     * Returns the currently used iterator
     * @return Iterator
     */
    public function iterator()
    {
        return (isset($this->iterators[$this->current_iterator_idx])) ? $this->iterators[$this->current_iterator_idx] : false;
    }
    /**
     * (non-PHPdoc)
     * @see Iterator::current()
     */
    public function current()
    {
        return $this->iterator()->current();
    }
    /**
     * (non-PHPdoc)
     * @see Iterator::next()
     */
    public function next()
    {
        //does nothing
        return $this->iterator()->next();
    }
    /**
     * (non-PHPdoc)
     * @see Iterator::key()
     */
    public function key()
    {
        return $this->iterator()->key();
    }
    /**
     * (non-PHPdoc)
     * @see Iterator::valid()
     */
    public function valid()
    {
        if (!count($this->iterators)) {
            return false;
        }
        //check if current iterator is valid
        $valid = $this->iterator()->valid();
        if (false === $valid) { //this iterator has dried up, try and find a new one
            //increment the index to find a new iterator
            $this->current_iterator_idx++;

            //now check if we have a new iterator
            if (false !== $this->iterator()) {
                //we have a new iterator, valid or not
                return $this->iterator()->valid();
            } else {
                //no more iterators
                return false;
            }
        }
     
        //apparantly, the current iterator is still valid
        return $valid;
    }
    /**
     * (non-PHPdoc)
     * @see Iterator::rewind()
     */
    public function rewind()
    {
        //reset state
        $this->current_iterator_idx = 0;
        array_walk($this->iterators, function($iter) {
            $iter->rewind();
        });
    }
}

With the expected usage and output:

<?php
$iter = new MultiIterator();
$iter->appendIterator(new ArrayIterator(range(0, 6)));
$iter->appendIterator(new ArrayIterator(range(10, 15)));

foreach ($iter as $row) {
    var_dump($row);
}


int(0)
int(1)
int(2)
int(3)
int(4)
int(5)
int(6)
int(10)
int(11)
int(12)
int(13)
int(14)
int(15)

Problem solved.

Currying vs. Partial Application

I am a longtime fan of functional programming. I came in contact with it through articles by Paul Graham and Joel Spolsky.

Since first class functions (or closures, anonymous functions, lambda functions) are possibly *the* cornerstone of functional programming, there wasn't much to do in the pre-5.3 days. The closest you'd get to closures was create_function(), which is awkward at best and non-functional at worst.
So now we have closures, which has its quirks, but is mostly functional I guess.

By the way, in the above paragraph I talk about closures, anonymous functions and lambda functions as being equal. I know there are subtle differences, but I think in the context of PHP they are negligible. I will usually use the term 'closure' or 'anonymous function', but they both refer to the same concept.

Now, on to the meat of this post. Currying vs. Partial Application. Two terms most programmers that know about functional languages have most likely heard about, but a lot of people get them mixed up or use them interchangeably.
I will first explain and demonstrate currying in the context of PHP, since this is the most misunderstood and, in my opinion, most useless of the two.

Currying
What is currying? From Wikipedia:

Currying is the technique of transforming a function that takes multiple arguments in such a way that it can be called as a chain of functions each with a single argument.

This is best explained using an example. Say we have a function that expects three arguments and returns the sum:

    function sum3($x, $y, $z)
    {
        return $x + $y + $z;
    }

Now we need to create a function that returns a chain of functions that only accept a single argument.

    function curried_sum3($x)
    {
        return function ($y) use ($x) {
            return function ($z) use ($x, $y) {
                return sum3 ($x, $y, $z);
            };
        };
    }


We would want to call it like this:

    $result = curried_sum3(1)(2)(3);


Unfortunately, PHP won't let us. But if I'm not mistaken we get that functionality in PHP 5.4 as part of the (new Foo())->method() syntax. So we have to assign each step to a temporary variable.

    $f1 =  curried_sum3(1);
    $f2 = $f1(2);
    $result = $f2(3);


So this is currying. I honestly can't see a practical use for this in a language (and associated scope) like PHP. But I'd love to be proven wrong! If you can make an argument and use case where function currying wouldn't be as awkward as it seems, or even beneficial, please let me know in the comments.

Partial Application
Now comes the interesting bit: Partial Application. A technique that is oftentimes called currying, but it's actually a whole different animal. Per Wikipedia the definition of partial application is:

Partial application (or partial function application) refers to the process of fixing a number of arguments to a function, producing another function of smaller arity.

Basically it is a technique to reduce the number of arguments to a function. If we build upon the sum3() function we have used earlier, we can fix the first argument to 1 and receive a new function that only requires two arguments:

    function partial_sum3($x)
    {
        return function($y, $z) use($x) {
            return sum3($x, $y, $z);
        };
    }

The resulting function requires only two arguments: $y and $z. $x will be fixed as the argument passed to partial_sum3().

    //create the partial
    $f1 = partial_sum3(1);
    //execute the partial with the two remaining arguments
    $result = $f1(2, 3);

The problem with this situation is that it's not dynamic. What we want is a partial function generator. A function that expects a function and n number of arguments. Fortunately, now we can create something like that fairly easy:

    function partial($func, $arg1 /**, rest*/)
    {
        $args = func_get_args();
        $func = array_shift($args);

        return function() use($func, $args) {
            $full_args = array_merge($args, func_get_args());
            return call_user_func_array($func, $full_args);
        };
    }

With this function we can create any partial we want:

    $f1 = partial('sum3', 1, 2);
    $result = $f1(3);

We reduced the number of arguments to sum3() to only one.
A practical example of this could be to easily map an array of timestamps into nicely formatted date/time's:

    //array of timestamps
    $timestamps = array(1325376000, 1328054400, 1330560000);
    //create the date formatter by fixing the format and effectively removing the first argument
    $date_formatter = partial('date', 'Y-m-d H:i:s');
    //map the timestamps to their nicely formatted counterparts
    $datetimes = array_map($date_formatter, $timestamps);
    var_dump($datetimes);
/**
Output:
array(3) {
  [0]=>
  string(19) "2012-01-01 01:00:00"
  [1]=>
  string(19) "2012-02-01 01:00:00"
  [2]=>
  string(19) "2012-03-01 01:00:00"
}
*/


I think this should pretty much cover the basics of currying and partial application and how it applies to PHP. I hope you enjoyed reading it as much as I enjoyed writing it.

Happy coding!

New blog

This is my first blog post. Ever. Well, besides the obligatory test post found right below this one.

I am not a writer. But I would like to become better at communicating my ideas to others. Thanks to Jeff Atwood, founder of CodingHorror and co-founder of Stack Overflow and Stack Exchange, I have finally gotten around and created my blog.

There are several reasons why I have created my blog, one of which I already mentioned.

1. Become better at communicating in general. Writing forces you to *think* about what you're trying to convey. On the other hand it is also a conduit through which you can come to a better understanding of a given subject. It is a two-edged sword. When you write you have a dialogue with yourself, and it is through that dialogue that you can come to a clearer understanding.
2. As mentioned in the previous point, through writing comes understanding. By trying to get my ideas across to my audience, you--the tech-savvy reader--I will also learn along the way and hopefully become a better developer.
3. Hopefully I can get some dialogue started. It is nice to get in touch with other programmers. Talk, share, discuss. Learn and teach. And it would be great if we get a few good laughs along the way.
4. And last but not least, I think it's a great pastime. Doing something programming related without actually programming. 

 I will blog about my experiences in my day job, some cool new technology I discovered, or just some random thoughts I want to toss out in the open. And of course All Things PHP!

I find writing hard to do, I really have to keep my mind to it. Not to get bogged down in mind-numbing details or too much glossing over. Finding a good tone-of-voice and consistency in my blogs will be important aspects in the next couple of months and need to become second nature.

Next up will be a post about me, what I do, why I do it and why I bother to write about it. Or it might be something PHP5.3 related, a post I am prepping right now. We'll see how it goes.