Ages ago, during my first year of computer science at the university,
one of the recurring complaints was about the stupidity of implementing
programs on paper. Reasoning was usually around memorization and
libraries and how it is or is not the essence of programming. At that
point, I didn't really care about it. I labelled it as "probably stupid"
and put it around the most random conversation topics in my mind. I was
more interested in mailing integer sequences to my favourite lecturer
at very particular points in time after midnight.
Around third year, we had microcontroller laboratories where, among
other things, we used
Motorola 6800.
Sometimes we ended up at the whiteboard discussing selected
implementations. Sometimes it was even closer to golfing. I didn't think
much about it and this time nobody was complaining.
Shouldn't we have complained though? After all, these two are similar
in their lack of computer in the process and necessity to remember things.
First difference is in the people. Four or five semesters is a
significant time in this kind of environment. Those who complained might
have just failed. Although, I doubt we changed our views. If anything,
we were in survival mode. Years later I hear similar complaints from
people that went through this exact or matching process.
Second difference is in the intent and scope. Golfing in a small ISA
with your drink buddies is a fun exercise. Pascal exam written on paper
during your first semester when you have no clue whatsoever is not.
But, can it be made fun or useful?
Quack! Consider
rubber
duck debugging method. In essence, we attempt to resolve a problem by
explaining it aloud. The idea is that by doing so we need to step back,
think it through, choose correct vocabulary, and put it in a frame. In
other words, we formalize the problem and define our solution to it if
any. In process of doing so we may come up with resolution.
Both fun and useful, although, there's no piece of paper and it's
usually a pure natural language explanation and not a programming
one. But the golfing example suggests that a whiteboard—so a written
medium—along with a variation of programming language works as well.
In the end, we pick language and vocabulary based on our intent and
discussion partners. If writing machine code on white board works, so be
it. If a mathematical explanation of problem is required, that works too.
And, of course, plain code is also fine. It's the most basic
communication language for programmers. Not just between us and computers,
but especially between one another.
Does a programming exam written on paper work? No.
However, using programming languages to express ideas and problems
does. Knowing vocabulary and idioms will help with it, so working
towards them is a decent goal. It's just not a starting one. After all,
we don't hand dictionaries to toddlers expecting them to converse with
us. We have fun with words and expand horizons over time. Same here,
we first build stable foundations in selected syntax, build intuition
around it, learn how platform works and then expand. On the way, we
memorize things and it's equally important.
Let's have fun then. And let's not only write code, but talk about it
and talk using it. On paper, e-mail, code review, whiteboard, napkin,
or with beer in hand. Let's refine how we use programming languages
and then have even more fun.