Sunday, April 19, 2009

Pair Programming - What makes programming different?

Pair programming is a pretty big movement in the software world and advocates of pair programming often believe all software should be worked on by two people. The question: "Why practice pair programming?", has lots of really well thought out answers. But after some google searching I have yet to read someone talking about what makes programming different.

The wikipedia entry on Pair Programming says nothing about pairing in other industries / professions. Neither does the Extreme Programming entry or the C2 entry

Why did pairing emerge in computer programming? Why is there a lot of literature on pair programming, that doesn't reference other professions? Here are a few possible thoughts:

  • There are lots of professions where pairing would be as beneficial as in programming, but for what ever circumstantial reasons pairing emerged, and was squashed.
  • Pairing exists in lots of other professions, but for some reason it's not as formalized as in programming.
  • The pairing movement is just as big in other professions, but I just haven't heard about it or been able to find any information about it.
  • Pairing doesn't exist nearly to the extent as it does in computer programming because there is something fundamentally different about writing software.

I don't really know which of those thoughts I believe is true. But I am surprised that pairing seems to have emerged from programming, and it doesn't appear to have emerged for other industries. Is programming really that different from other kinds of knowledge professions?

Thursday, April 16, 2009

Shortcuts

There must be a mathematical proof out there that says, coding outside of your design / idiom will always comeback and bite you. I swear it must be true. I've been coding away on a project for a few months now. Things are really starting to come together, the light is at the end of the tunnel. There were a few places, that I took some shortcuts, hey I was in a rush, I wanted to finish up a little component before I left for the day, I was tired, it's not going to be so bad.

But doggonit each time I hit one of those shortcuts, they screwed me. Without fail they turned out to be problematic, in ways I couldn't even have imagined when writing them. And, they were way more time consuming to fix, than if I had written them correctly the first time.

I'm not talking about totally egregious shortcuts either. Some revolved around being cute or tricky or just slightly blurring tiers. But it is amazing to me how each one of the shortcuts turned out to be problematic enough to need to be fixed.

Away, there must be some mathematical proof about this, there must be.

Wednesday, April 15, 2009

Learning Clojure

Well I've started down the path of learning a new language (Clojure) the past few weeks I blame it all on going to NFJS and going to too many Stuart Halloway talks.

Learning Clojure has definitely been challenging. It seems like the total opposite from Java. Beside being a functional language, it feels like it was built to be terse. It makes heavy, heavy use of symbols, who knew the ":" could mean so much!

A friend and I have been working on a snake example (apparently, everyone writes a snake example, just google "clojure snake" there are jokes like, YACS (yet another clojure snake)). I think it took us a good 7-8 hours just to understand all the code. Destructuring was I think the hardest concept to learn.

Destructuring is also called abstract structural binding check out (let [bindings* ] exprs*) where bindings == binding-form and initial-expr. In my limited exposure destructuring is often used in (defn ([params*] body) where params == binding-form and body = expr, AND using your function is applying the initial-expr. Somehow it helped a lot to understand defn in terms of let.
For example:

user> (defn foo [a b] (+ a b)) user>(foo 1 2) 3
So in that example [a b] is your vector binding form (+ a b) is your exprs and (foo 1 2) is the application of the initial expression.

You could view the same behavior with let

user>(let [[a b][1 2]] (+ a b)) 3
Anyway, once I made this connection a lot of things started to fall into place when looking at clojure code. This might have been more obvious to me if I had read more carefully the fn special form, so I would certainly spend time looking through the special forms documentation if you're interested in learning Clojure.

Also to blame on Stuart + NFJS is I setup a github repository which will probably change drastically, but if you're interested in checking out my progress on snake.clj it's up there. We now have 2 snakes, are detecting collisions and are working on setting up a wall.

Oh running clojure is really easy, just download the clojure jar, java -cp clojure.jar clojure.lang.Repl will give you a terminal, and java -cp clojure.jar clojure.main snake.clj will let you run the snake example.

 
Web Statistics