CS intro != Programming intro

Yes, "CS intro != Programming intro". Of course, it is not; maybe it would never occur to you that it could!? Well, in some places, though, the CS 101 ("introduction to CS") course ends up being essentially that, at least for some initial part. In some places (Koblenz included; see my OOPM course which is under attack in this post), the CS 101 course certainly ends up trying to also introduce the basics of programming (because the lecturer thought he/she should).

Here is why I think this is wrong and I apologize for coming forward so late:

• Teaching the trivial level of programming ("getting you going with for-loops and such" :-)) just doesn't belong at the university. Maybe it never belonged there, but it certainly doesn't belong there anymore (for like 10-20 years) because it is just such a basic skill and there is so much guidance out there (Youtube etc.) that a contemporary student wanting to study CS must (or should) simply be beyond the point of needing such a trivial introduction.
• At a "mediocre" university like mine (not overwhelmed exactly with brilliant students like this), we may get some otherwise possibly smart students however certainly lacking the most basic programming skills. Trying to get them up to speed in a university-style course is just frustrating everyone. It certainly has bored me near to death.

As a result, I am changing my CS 101 course (11 ECTS on paper, which is crazy in itself), per immediately (effective per end of October), as follows:

• I decouple the objective of teaching basics of programming from other aspects of the course by running two tracks in parallel for some time. I collect these other aspects of the course, which are not about basics of actual programming, as the "theory track". The "programming track" is just there for those who need it. I expect it to be skipped by some students. The theory track will not make any assumptions about previous programming skills.
• In the theory track, I spend several weeks overall on algebraic specification with applications to abstract data types and what is maybe best called "algebraically oriented domain modeling". See my recent slide deck (.pdf), in that instance Haskell-focused, though. This is joint work with Magne Haveraaen, University of Bergen. Welcome to the university! Students need to understand algebraic signatures and logic formulae. I am going to be nice with the students :-) So I shall limited coverage to pragmatic application of loose algebraic specifications; no term algebra, no quotient algebra, no Herbrand universe, no nothing. Structural induction is in, though! Sorry.
• As the two tracks have progressed enough, synergy happens such that we implement specifications in Java or Python. Appropriate axioms from the algebraic specifications will lend themselves as assertions and as (parametrized) unit tests. We are also well equipped to discuss design by contract. We will also be prepared to appreciate the beauty (?) of UML class diagrams with OCL constraints. Algebraic specifications and logics are everywhere.
• Logistically, I will be working mostly without slides. Rather I will use the whiteboard and different editors. The 101wiki of the 101companies project will host code and explanations and links to Wikipedia and other online resources. I will distribute some lectures notes, but no wall of text is going to replace my previous wall of slides. I want to get across (through focused lecture note material) some basic notions and for the rest I use online resources including commented specifications and programs as well as links to Wikipedia et al.

This gets us through 2/3 of the course. The remaining 1/3 of the course will use a single, sequential timeline. I will think about it, as it gets closer, but here are some thoughts:

• Coverage of EBNF as another modeling method. Great! There is this wonderful connection between algebraic signatures and context-free grammars. Maybe, I will do term algebras anyway and manage to bore everyone to death.
• Very basics of complexity theory. This can be done as soon as students are fluent in basic algorithmic programming. The same is true for the very basics of program verification. Coverage of program verification (Hoare logic) will definitely benefit from dealing with logic formulae in the theory track earlier.
• There is a bunch of non-very basic programming topics that I tend to cover such as pointers, encapsulation, interfaces, modularity, inheritance, generics, exceptions. Some order needs to be determined. I have managed in the past.

Luckily, in the second semester, I teach "introduction to functional programming".  It is, of course, wonderful (in the view of the lecturer anyway) to make the students see the connection between algebraic specification and functional programming.