Pong in 30 Lines
Mar 19, 2008

size(400,400)
speed(40)

ball_diameter = 20
paddle_size = 75
v_x, v_y = (3, 4)
p_x, p_y = (10, 10)
bounce = 1.2
points = []
computer = WIDTH / 2
compuspeed = 10

def draw():
    global v_x, v_y, p_x, p_y, points, bounce, computer, compuspeed
    
    if not -ball_diameter < p_y < HEIGHT + ball_diameter:
        text("Game Over", WIDTH/2, HEIGHT/2)
        if p_y < 0: text("You win!", WIDTH/2, HEIGHT/2+20)
        else:       text("Computer wins", WIDTH/2, HEIGHT/2-20)
        return

    paddle_left = min(max(MOUSEX, 0), WIDTH-paddle_size)
    ny = p_y + v_y
    nx = p_x + v_x
    
    if nx + (ball_diameter/2) > computer + paddle_size: computer += compuspeed
    elif nx < computer:                                 computer -= compuspeed
    rect(computer, 0, paddle_size, 4, roundness=2)

    if ny + ball_diameter > HEIGHT and v_y > 0 \
    and paddle_left < nx + (ball_diameter / 2) < paddle_left + paddle_size:
        v_y = -v_y * bounce
        v_x = (nx - paddle_left - (paddle_size / 2)) * .25
        ny = HEIGHT - ball_diameter
    if ny < 0 and v_y < 0 \
    and computer < nx + (ball_diameter / 2) < computer + paddle_size:
        v_y = -v_y * bounce
        v_x = (nx - computer - (paddle_size / 2)) * .25
        ny = 0
    elif nx + ball_diameter > WIDTH or nx < 0:
        v_x = -v_x
        
    mx = max(0, min(MOUSEX, WIDTH - paddle_size))
    rect(mx, HEIGHT-4, paddle_size, 4, roundness=2)

    p_x = nx
    p_y = ny
    oval(p_x, p_y, ball_diameter, ball_diameter)

I'd never written a game before, and they say you aren't allowed if you don't start with pong, so here it is. I was actually just playing around with motion in NodeBox for a seperate project, and did this for fun.

[# ▷] nodebox, python, programming

DNA on Programming
Feb 16, 2008

"Well, what we called a computer in 1977 was really a kind of electric abacus, but..."

"Oh, now, don't underestimate the abacus," said Reg. "In skilled hands it's a very sophisticated calculating device. Furthermore it requires no power, can be made with any materials you have to hand, and never goes bing in the middle of an important piece of work."

"So an electric one would be particularly pointless," said Richard.

"True enough," conceded Reg.

"There really wasn't a lot this machine could do that you couldn't do yourself in half the time with a lot less trouble," said Richard, "but it was, on the other hand, very good at being a slow and dim-witted pupil."

Reg looked at him quizzically.

"I had no idea they were in such short supply," he said. "I could hit a dozen of them with a bread roll from where I'm sitting."

"I'm sure. But look at it this way. What really is the point of trying to teach anything to anybody?"

This question seemed to provoke a murmur of sympathetic approval from up and down the table.

Richard continued, "What I mean is that if you really want to understand something, the best way is to try and explain it to someone else. That forces you to sort it out in your own mind. And the more slow and dim-witted your pupil, the more you have to break things down into more and more simple ideas. And that's really the essence of programming. By the time you've sorted out a complicated idea into little steps that even a stupid machine can deal with, you've certainly learned something about it yourself. The teacher usually learns more than the pupil. Isn't that true?"

"It would be hard to learn much less than my pupils," came a low growl from somewhere on the table, "without undergoing a pre-frontal lobotomy."

"So I used to spend days struggling to write essays on this 16K machine that would have taken a couple of hours on a typewriter, but what was fascinating to me was the process of trying to explain to the machine what it was I wanted it to do. I virtually wrote my own word processor in BASIC. A simple search and replace routine would take about three hours."

"I forget, did you ever get any essays done at all?"

"Well, not as such. No actual essays, but the reasons why not were absolutely fascinating. For instance, I discovered that..."

He broke off, laughing at himself.

[# ▷] computer, programming, dna

Functional Roman Numerals in Python
Jan 12, 2008

def unfold(f, x):
    res = []                       
    while 1:
        try:
            w, x = f(x)
            res.append(w)
        except TypeError:
            return res

And then the answer becomes:

numerals = [("M", 1000), ("CM", 900), ("D", 500), ("CD", 400),
    ("C", 100),  ("XC", 90),  ("L", 50),  ("XL", 40),
    ("X", 10),   ("IX", 9),   ("V", 5),   ("IV", 4),
    ("I", 1)]

def next(x):
    for n in numerals:
        if n[1] <= x: return (n[0], x-n[1])

def romanize(n):
    return "".join(unfold(next, n))

Compare to the haskell I posted before:

romanize = concat . unfoldr next
    where next 0 = Nothing
          next x = Just $ second (x-) $ head $ filter ((<=x) . snd) numerals
          numerals = [("M", 1000), ("CM", 900), ("D", 500), ("CD", 400),
                      ("C", 100),  ("XC", 90),  ("L", 50),  ("XL", 40),
                      ("X", 10),   ("IX", 9),   ("V", 5),   ("IV", 4),
                      ("I", 1)]

The "where" idiom allows you to group helper functions and constants underneath the main function, and the unimportance of function order means you can highlight the high-level logic. The haskell code is much shorter and tighter than the python.

Having powerful iterative functions like unfoldr in the standard library is another clear win for Haskell; it took me more lines to define unfold than it did to define both next() and romanize(). (By the by, some googling failed to turn up a previous python implementation of unfold(); I think this code gets a lot uglier without it. I also don't see any obvious way to do it with itertools.)

On the other hand, I find the simplicity of the python next() appealing, with its constructive instead of declarative approach. It's a less generic solution that's intuitively simpler (for me, still an imperative thinker).

You could match the haskell more exactly:

from itertools import ifilter

def second(f, (a, b)): return (a, f(b))

def next(x):
    return second(lambda a: x-a, ifilter(lambda (y, z): z <= x, numerals).next()

but the result is pretty ugly. The inability to compose functions compactly results in a lot of boilerplate, and in having to pick a lot of meaningless variable names that obscure what's going on. We could move the lambdas out of the call and give them names:

def next(x):
    subx = lambda a: x-a
    ltx = lambda (y, z): z <= x

    return second(subx, ifilter(ltx, numerals).next())

And it's a little better, but I think we're now pretty far from idiomatic python.

Conclusion

The python translation of the haskell isn't bad, but I do think it loses something. The unfold() trick works really well, and translates easily into an imperative, pythonic implementation; I'll look for ways to use it in the future. And, finally, I'm pretty jealous of Haskell's function combination abilities.

Updates

In the comments at reddit, nostrademons posts a nicer unfold function:

def unfold(f, x):
    while True:
        w, x = f(x)
        yield w

And Kay Schluehr prefers the iterative solution:

 numerals = (("M", 1000), ("CM", 900), ("D", 500), ("CD", 400),
("C", 100),("XC", 90),("L", 50),("XL", 40), ("X", 10), ("IX", 9), ("V", 5), 
("IV", 4), ("I", 1))

def romanize(n):
    roman = []
    for ltr, num in numerals:
        (k,n) = divmod(n, num)
        roman.append(ltr*k)
    return "".join(roman)

David Pollak contributes a Scala unfold and romanize at his blog.

[# ▷] python, code, programming

Beautiful Code
Jan 12, 2008

import List
import Control.Arrow

romanize = concat . unfoldr next
    where next 0 = Nothing
          next x = Just $ second (x-) $ head $ filter ((<=x) . snd) numerals
          numerals = [("M", 1000), ("CM", 900), ("D", 500), ("CD", 400),
                      ("C", 100),  ("XC", 90),  ("L", 50),  ("XL", 40),
                      ("X", 10),   ("IX", 9),   ("V", 5),   ("IV", 4),
                      ("I", 1)]

Starting from the inside out is usually the easiest method of understanding blocks like this, so we'll look first at the "numerals" list. It is, simply, a list of tuples matching Roman numerals to their value. Importantly, it's ordered from largest to smallest; we'll see why shortly.

The meat of this snippet comes in the "next" function:

next 0 = Nothing
next x = Just $ second (x-) $ head $ filter ((<=x) . snd) numerals

This function is going to return either Nothing (in the base case) or Just a tuple of type (String, Integer), where the string is the largest roman numeral that's smaller than x and the int is the difference between x and the value of that roman numeral.

The first thing we do is filter out the numerals larger than x; we can run some quick tests at the interactive console to see how this works:

Prelude> let numerals = [("M", 1000), ("CM", 900), ("D", 500)]
Prelude> filter ((<=900) . snd) numerals
[("CM",900),("D",500)]

We use head to grab the largest numeral we can squeeze into the current value:

Prelude> head $ filter ((<=900) . snd) numerals 
("CM",900)

Then we subtract the value of the roman numeral from the current value of x, in order to return the remainder to be operated on next:

Prelude> :m Control.Arrow
Prelude Control.Arrow> second (900-) $ head $ filter ((<=900) . snd) numerals
("CM",0)
Prelude Control.Arrow> second (915-) $ head $ filter ((<=915) . snd) numerals
("CM",15)

And, finally, we wrap it up in a Maybe monad, so that the main function can handle the base case transparently:

Prelude Control.Arrow> Just $ second (915-)  $ head $ 
    filter ((<=915) .  snd) numerals
Just ("CM",15)

And now we're getting pretty close! What we have is a function that returns either Nothing or a tuple containing a letter to add to our roman numeral and the next value to operate on. All we have left is the code to drive the operation:

romanize = concat . unfoldr next

The use of unfoldr helps explain why we've wrapped next up in Maybe; here's its type:

Prelude Control.Arrow> :m List
Prelude List> :t unfoldr
unfoldr :: (b -> Maybe (a, b)) -> b -> [a]

So we'll take a function from b -> Maybe (a, b), a value of type b, and return a list of [a]. In our case, a = String and b = Integer.

All unfoldr does is call the function it's given as a first argument, which returns a tuple or Nothing. If it's a tuple, it appends its first element to a list and calls the same function with the second element. If it's Nothing, it returns the list it's built up to this point.

As we can see, that matches up perfectly with the "next" function we've already defined, and the unfoldr will build up a list of roman numeral strings:

Prelude> :m Control.Arrow List
Prelude Control.Arrow List> let numerals = [("X", 10), ("IX", 9), ("V", 5), 
("IV", 4), ("I", 1)]
Prelude Control.Arrow List> let next x = if x==0 then Nothing               
    else Just $ second (x-) $ head $ filter ((<=x) . snd) numerals
Prelude Control.Arrow List> unfoldr next 9
["IX"]
Prelude Control.Arrow List> unfoldr next 8
["V","I","I","I"]

(We had to mangle the definition of next a bit to fit into the interactive interpreter, but we haven't changed anything fundamental about it.)

Finally, all we have to do is concatenate the strings into our final result:

Prelude Control.Arrow List> (concat . unfoldr next) 8
"VIII"

Conclusion

Phew - that's an awful lot of information stuffed into a few pretty lines! I still have a hell of a time geting the types to match up so that I can write stuff like this, but that doesn't mean that I can't appreciate the beauty of how it all fits together. The original function presented here is tight in the very best sense of the word.

[# ▷] haskell, code, programming

Poe on Programming
Dec 28, 2007

Code As Poetry

In The Philosophy of Composition, Poe attempts to describe exactly how he composed The Raven, simply because he's never seen such an attempt before. While we might be wise to doubt his motives (as did TS Eliot), it nevertheless may be interpreted to provide solid principles for the construction of a program.

Before we do so, I must first convince you that code should be read as poetry instead of prose. Since this will always be a matter of opinion, and I know that many people will disagree, my argument will be short and simple.

When you read prose, you read it as if it is being narrated to you; whether by a narrator, a character in the story, or many characters, the distinguishing characteristic of prose is its similarity to speech. We find that it is allowed a much greater freedom of verbosity, so long as it accomplishes its goal of conveying a plot to its reader.

Poetry, on the other hand, is an abstract block of words in which every one must carry meaning if the poem is to be any good. We value the poem for the beauty not only of the story or image given, but of the way in which it is constructed as well. It tends to be much denser and more compact than prose. When you read it, you must proceed carefully and consider the meaning of each word, and each group of words, and pay attention for double meanings and allusions if you are to grasp it fully.

To help us decide how we read code, let's go to a particularly nice bit of it, and meditate on it for a moment. Did you read it as if it were speech, or poetry? Did it have a narrative "flow" for you, or was it something of an abstract block of "words"?

Of course, code is really neither prose nor poetry; it is a distinct art form of which Poe could not have been aware. I like to think that it may be read much more closely to poetry than to prose, and we will proceed from here as if this were true.

Unity of Impression

If any literary work is too long to be read at one sitting, we must be content to dispense with the immensely important effect derivable from unity of impression- for, if two sittings be required, the affairs of the world interfere, and everything like totality is at once destroyed. But since, ceteris paribus, no poet can afford to dispense with anything that may advance his design, it but remains to be seen whether there is, in extent, any advantage to counterbalance the loss of unity which attends it. Here I say no, at once. What we term a long poem is, in fact, merely a succession of brief ones- that is to say, of brief poetical effects. It is needless to demonstrate that a poem is such only inasmuch as it intensely excites, by elevating the soul; and all intense excitements are, through a psychal necessity, brief. For this reason, at least, one-half of the Paradise Lost is essentially prose- a succession of poetical excitements interspersed, inevitably, with corresponding depressions- the whole being deprived, through the extremeness of its length, of the vastly important artistic element, totality, or unity of effect.

In the first sentence of this paragraph, Poe provides an alternate metric to Yegge's metric of "code size" - that of "unity of impression". Beautiful code is that which is not composed of "a succession of brief.. poetical effects", but of just the poem. It is code without filler, bureaucracy, or artifice, regardless of how long it is.

As a practical matter, not all programs may be written in this manner. In an operating system kernel, a great deal of "corresponding depressions" — documentation, error handling, and interrupt handling — must be interspersed in between the "poetical effects", making it "essentially prose".

This does not change the fact that the Linux kernel or a BSD kernel is a thing of beauty, just as Paradise Lost is great despite "the extremeness of its length". Instead, it should give us motivation for our programs, to write them with as few depressions as possible so as not to drag down their unity of impression.

A great example of code as poetry is OpenBSD's tail¹, which I referenced in a previous post. After I sat down with it for an hour, it was extremely clear to me what it did. In the beginning, it set out the patterns of code which would continue throughout, enabling me to quickly find my way to the part that mattered, despite my relative unfamiliarity with C.

It is a great strength of the Unix philosophy that each bit of code may be kept as brief, self-contained, unified, and therefore beautiful. It is a pleasure to work with tools which have been pared down to their bare bits instead of expanded to encompass ever more functionality.

Design for a Purpose

My next thought concerned the choice of an impression, or effect, to be conveyed: and here I may as well observe that throughout the construction, I kept steadily in view the design of rendering the work universally appreciable. I should be carried too far out of my immediate topic were I to demonstrate a point upon which I have repeatedly insisted, and which, with the poetical, stands not in the slightest need of demonstration- the point, I mean, that Beauty is the sole legitimate province of the poem.

If beauty is the sole province of poetry, I propose that data transformation is the sole province of the computer program. (I am not the first to do, although I cannot recall where I read it first). Therefore, when designing a program, we should at all times keep in mind the transformation which we wish to achieve, and discard all those parts which do not assist in that goal.

While this seems at first straightforward, it is important to consider that programs are designed for humans and by humans. Unlike poetry, most code is not generated by its author for the appreciation of the masses. Instead, it is designed to fulfill a purpose, specifically to achieve a certain data transformation.

Just as very few great poems were authored by multiple people, very few great programs have been authored by multiple people. If we consider long programs to be composed of many poems separated by dull bits, their great parts are almost exclusively those parts over which their maintainers have slaved to bring to a state of terse beauty.

If you must have many people working on a program, it is of the utmost importance that they all know and share an understanding of what exactly it is that the program is intended to accomplish. Without this deep shared knowledge of intent, the program will lack a single impression, or effect, to be conveyed, and likely fail to impress.

All The Rest

The length, the province, and the tone, being thus determined, I betook myself to ordinary induction

Once you have determined the length, purpose, and tone of your program, the rest is, as they say, trivial. Poe dedicates the rest of his essay to applying the principles discussed in this essay, and showing how "The Raven" falls ever so simply out of them. If you write a program while at all times keeping in mind its unity of purpose and the impression you intend to convey, perhaps you will find some beauty in it.

I hope that you will read the essay in its entirety; I'm sure that I have failed to do it justice here. Although it is of questionable merit as a method of writing the next "The Raven", perhaps it will help you think about how to write your next program.

¹ pybloxsom is another, and reddit readers provide many more.

[# ▷] poe, literature, programming, python, poetry

I'm a programmer for a small company in Baltimore, Maryland, USA. Besides programming, I play competitive ultimate. I blog at irregular intervals about various programming topics, but mostly Python.