Processing Notes, 25 January 2006

I am a lecturer on an MSc course at the Bartlett in UCL, and one of my friends Tom suggested I keep a log of particular difficulties in teaching architects and designers to program via the Processing platform. Thus disclaimed are my digressions from rare postings on chefery, politics and Potter.

Divuldging my side of the fence: I feel Procesing is a deeply flawed albeit contagious and buzzy platform for teaching programming. My criticisms are plenty but now public — because "in the trenches" teacher and student would benefit from these gripes being addressed. It behooves the whole community if nascent programmers come away from their terms spent in Processing with academe nostalgia, not flight. Their appraisals at future design and architecture gigs will make or break Processing, either promoting or dashing its current momentum.

And so, my notes from last week's lecture on boids:

Algol to C to Java to Processing: Matching curly braces — or begin/end blocks — is a necessary evil in this lineage of programming languages. Processing helps by highlighting a matching brace while hovering, but this is of limited use to students who are learning by cut 'n paste. A more helpful feature would be an "auto format" option to indent and align a tab of Processing code, especially after said code has been mangled by many-a CTRL-V. Check, thanks Tom.

No argument methods and functions: Other 4GL languages skip the irritating verbosity of parentheses when passing no arguments, so why shouldn't Processing? Think "obj.meth;" instead of "obj.meth();". Like many of my criticisms, this may seem pedantic nit-picking of the Java legacy. However these sort of redundant redundancies just devastate novices.

Stack traces: Processing should move my cursor to the correct tab and line of a particular stack trace. There seems to be a deemphasis in Processing on making stack traces visible, but they are actually a very natural and linear way to review a program's logic in hindsight. At the bare minimum, Processing's stack traces should at least list line numbers and tabs.

float vs. int: Now we come to probably the most consistently baffling and frustrating (to both teacher and student) aspect of learning to program with Processing. The distinction between floating point numbers and integers, and the accompanying nasty casting, is fundamentally non-intuitive. This is the 21st century; memory, disk and CPU are cheap. Have the stones to make everything arbitrary-precisioned floating point numbers. All literals and all numeric variables are this "super float," and let the interpreter or compiler worry about the optimizations of when-and-where a value can be coerced for faster integer math. From the learning programmer's perspective, it is almost maddening that "1.0/99 != 1/99". And in light of Processing's already compromised performance, please ignore anyone saying "but it'll be slow."

Not criticisms of Processing specifically, but general practices to remember when teaching designers and architects to program:

Top down: Professional developers grow accustomed to a progressive focus on the minutiae of a problem, while gluing these pieces together "later." Long experience in writing software, or a background in mathematics, facilitates this minutiae-driven programming process. Though you may know this bit of code will be needed eventually, it is more conducive to teaching good programming style — or to teaching programming at all — to work from the top down.

Even if it does not resemble your actual programming practice, live lecture or lab demonstrations of coding should invert the minutiae thinking: Code and discuss the most general logic of the program first, and fill in the blanks later. One of my first programming teachers taught programming in this style, and while demanding of the lecturer, it is deeply instructive to code the skeleton first.

Vector vs. points data representation: While we're used to modeling a velocity vector and a spatial position with the same underlying data structure, this is a significant leap for students getting used to 3D programming. This is true even for those designers and architects comfortable with a CAD package. Drill this "not distinction."

Heap data is sorta global: Yet another murky legacy of Algol-ish, side-effect-ridden languages is the confusing heap; that an object instantiated in a small method, but referenced via a stack variable that is eventually returned, is visible to the caller — another conceptual leap for novice programmers. A visual diagram of a simplified heap can help. A purely functional language for learning would help even more...

While these feature requests are certainly not on the grand scale of software methodology practics, these sorts of "little things" are what enable frequent and vicious refactoring, a vital practice in good top-down object oriented (OO) development.