Thursday, November 08, 2007

Array Array!

Much in the tradition of repeated titles such as Europa Europa, Jamon Jamon, and Corinna Corinna, there's Array Array!.

Except this is not a film, but a play on words. "Array" roughly "hey" as in "hey you" in Hindi. And in computer-ese, arrays are the simplest data structures beyond the lowly variable. Once you teach a beginning programmer a variable, if-then, then it's time for loops and arrays. And, in this day and age, the next step is objects.

We say familiarity breeds contempt, but it also breeds love. People gravitate to the stuff they find easiest. Since arrays come so early on, people use arrays, even as, in principle, they learned objects.

To give a more drastic example, I heard of a project where students were asked to design classes for a project. Up until that point, they had been told classes and methods to implement. They didn't have to think it up themselves.

When asked to do this project, students fell into one of two categories. Those who used one super class to do everything. And those who treated each class as if it were a variable(!). Thus, if the program needed ten variables, they created ten classes.

Indeed, you also find, despite knowing better, that beginners prefer to write super functions hundreds of lines long rather than break it up into functions. The thought of having to pass variables to functions, even to break down a problem into functions drives them nuts. They have no idea how to do it. Indeed, given their druthers, they might prefer to code in FORTRAN, and forget about modular design, despite all attempts to teach them otherwise.

I have an idea how to solve this.

Teach design.

And teach design separately from coding it up. There's perhaps many a entry level coder, who goes to a computer job, and finds execs who've never programmed seriously a day in their lives making decisions on how this should be done and that should be done, and says "I could make those decisions too!" (They probably can't, but it seems easier than coding).

Design is something like making managerial decisions. If you don't have to code the design up, you might create a more sensible design. Then, the design can be critiqued on its own, and eventually, this might lead to better designs, which means coders will care about design rather than care about getting the code to work with the least hassle possible.

Of course, after the novice coders create a design, then they should implement it, to see if they regress into arrays and huge functions. If they don't, then the idea has merit.

No comments: