I'll be responsible for teaching a few core concepts to my ICS 22 study group for our midterm with Java. However, I plan to teach it effectively. Reflecting on my own learning process and the process of others, I've been exploring programming aptitude with relation to a programmer's abstract capabilities.

Details of the Midterm

Most likely, we will cover the Scanner class; try-catch-finally with Exception objects; LinkedList, Iterator and Stack data structures; and possibly unit testing. All of the classes and data structures have very specific mental models associated with them. FIFO and LIFO abstract LinkedList objects (depends on the implementation) and Stack objects respectively with the context of our class.

Easy work for me; however, if I plan to teach it, then I should understand why others have difficulty. Instead of re-learning my own material, I tried to seize the context by placing myself under someone with greater programming skills.

Learning from Greater Abstraction Skills

Last Thursday, I saw Eric Hennigan again. With Alex Thornton, they discussed mental models and their correlation with programming aptitude.

A little backtracking: Eric and I were discussing LHS and RHS values on assignment operations which reminded me of Dehnadi and Bornat's tests on programming aptitude via mental modelling. I've skimmed his articles before, but they cover simple constructs: assignment operation mental models (though the variations of the mental models were surprising). Dehnadi explains that specific mental models are necessary to succeed in programming.

Eric is an example of a successful programming student. He is a post-doctoral student that will soon be teaching the introductory Computer Science course at CSU Fullerton.

Eric quickly conceived a mental model of my Discrete Event-Driven Simulation before I could imagine my own system. He also derived the test cases as he spoke. I was learning from Eric. His abstract thinking skills enabled him to teach me effectively as my senior.

Based on the conversations between Eric and I lately, I'm planning to watch for signs of understanding between grammar and mental modelling like the Stack model above with my peers.

Grasping the Mental Model

Now my conception of a successful study is a strong foundation in the mental model of the system at hand. For example, understanding Stack objects requires an understanding of the LIFO mental model.

public interface Stack {
  public abstract boolean isEmpty();
  public abstract int size();
  public abstract void push(E e);
  public abstract E top();
  public abstract E pop();
}

The Stack above is a concrete implementation of the LIFO model which pushes elements to the top of the stack and pops elements from the top of the stack. My plan of attack is as follows:

  1. Introduce the mental model through proper diagramming e.g. UML and process diagrams.
  2. Bridge the abstract model with a concrete example e.g. a stack of plates.
  3. Bridge the abstract model with an interface (see the code example above).
  4. Implement the interface!

From my experience, our current ICS 22 professor, Thornton, has a similiar process in his lecture though the design and mental model of the systems are taught auxilliary. I believe that it should be taught a parallel skill alongside programming which should be part of a semi-upper-division course.

Problems with the Current Introductory Courses

As a student of UC Irvine, we are a Java-oriented school. It's easy to see that OOD is a necessary skill associated with Object-Oriented Programming (OOP). Because Java is purely OOP, it should be taught alongside OOD; however, the school defers the course until upper-division classes which leaves students to crystallize their own ideas of OOD as they learn OOP for a year.

Learning OOD and OOP places significant weight on a student as seemingly two separate classes that integrate into a single course. However, an introductory course shouldn't introduce all aspects of programming simultaneously which could overwhelm students. Instead, as Alex and I have discussed, the introductory course should introduce fundamental concepts of programming, such as control structures, before teaching OOP and OOD.

Fortunately, I've confirmed, through my e-mails with Alex, that UC Irvine will soon use Python as an introductory language at the beginning of the next academic year. Python has the advantage of significantly less scaffolding for developing simple programming skills independent of OOD.

The success of Python as a language of practice is still up for debate but MIT ostensibly works with it. As for OOP and OOD, we'll see how they'll be incorporated into next year's program.