The Current State of Introductory Computer Science

Outline

There are basic programming primitives which an introductory student faces; regardless of the language you want to learn. For instance, you need to create variables and assign them values like numbers or words (strings). Then, you need lists of numbers or words (etc) with which you can populate, depopulate and test for membership. You also need to perform operations on them like addition or subtraction.

These core primitives form a toolbox with which you can create programs that do important tasks with mechanically perfect execution. This is the same regardless of the language.

Once you learn to master the basic primitives, you can perform all sorts of useful and interesting (even artistic) functions on just about any language platform. Yes, of course there are dizzying heights of complexity which can be reached (in shockingly different ways) with each discrete language. But, those concepts are of no use to you, the beginner. In fact, teaching them at this stage will only make your life hell. Why should you try to understand what a Monad is if you don't even know what a conditional statement is?

This doesn't stop authors and professors from shoving these ideas down your throat. To their credit, they are beneficently trying to introduce you to difficult concepts early on; so that you have so much familiarity with them that, by the time you actually need to use these concepts, you intuitively apply them to solve tricky problems.

The problem is that the human mind just doesn't work that way. In truth, humans aren't too good at dealing with symbolic abstraction (like sigma or delta etc). Ironically, the greatest scientific minds of all times belong to rebels who chose instead to 'visualize' complex abstractions in ways that made sense to them but were still mathematically useful -- think Einstein's thought experiments.

All an abstraction is, is a way to encapsulate a series of complex operations into a 'black box' which we can use without worrying about the intricate details of it's operation.

However, when mathematical symbolism is employed, the exact opposite happens. The student is confronted with what looks like an alien language which works in mysterious ways and is only ever explained using yet more self-aggrandizing academic symbolic terminology designed to prove the author's intellectual command of language and NOT to educate.

Here's an exaggerated example of poorly used symbolic terminology. Say you're a rock guitarist. A mathematician (were she writing a peer-reviewed paper on Electronic Dynamics Control Systems in the neighboring room) would tell you that you need to conscientiously modulate your low-voltage transducer output using a logarithmic potentiometer in series with your high-z output rectification stage. However, a fellow musician would simply say, "Hey man, turn your axe down!" Both sentences say the same thing. However, the first one is precise to the point of facetiousness. The other gets the same abstract point across in universal terminology that also provides some nice visualizations; a guitar does actually look a bit like a battle axe, when you adjust the volume knob it does get turned and the sound does seem to go down; from any observer's vantage. 

This is not merely a trivial argument designed to inflame anti-academic sentiment, it really does point out a salient commandment in academic writing: teachers should always seek to explain things in the most intuitive way possible. There is no logical place for abstruse verbiage in the education system unless it increases the student's intuitive understanding of the subject at hand.

The pointlessly confusing word-choices in academic instruction today are designed to ensure that the author is published on merit of their own 'literary expertise' and have no didactic use whatsoever. It is the stated goal of UP to end this shameful practice formally.

With this in mind, I will introduce the primitives to the student first. Show them how to use these primitives in a (initially limited) set of popular languages. When the primitives themselves begin to diverge widely in their language's handling, only then will I introduce new theoretical structures and then only to explain the difference in their application. The depth of the student's understanding of the language will grow organically in as much as the student is required to understand in order to accomplish universal programming tasks, and no more.

There is a glut of literature on the market explaining all of the most mind-bendingly complex subjects in Computer Science and disturbingly little covering all of the myriad useful tasks that can be accomplished using only the basics. Basic programming tasks like file I/O and merge-sorting have become so hopeless ensconced in techno-babble that many students drop-out altogether before they even learn to use them.

This creates a disconnect between author, student and teacher. Only students who are already indoctrinated in the academic material have any hope at progress in CS (and most other sciences). This is, to put it in academic terms, ass-backwards. Yet, it ensures that tenured professors continue to procure publishing contracts and speaking engagements; which is why it dominates educational literature.

In summary, you will learn about the byzantine abstract mechanization underlying your chosen programming language only when you need to; and then only in the most intuitive and useful way possible. If every level of CS education were instructed in this way*, there would be more CS graduates and more advancements in the field. Professors would no longer have sole authority on the subjects they teach! I wonder why this approach hasn't caught on yet?

*Of course there are a handful (just a handful) of fine books out there that manage to do this very elegantly. CSS: The Missing Manual by David Sawyer McFarland is a shining example and an inspiration to aspiring technical writers like me.