Saturday, May 26, 2007

Goal of CS and SE degrees

The goal of CS and SE degrees are respectively to turn out Computer Scientists and Software Engineers. Sometimes it is forgotten that graduates are much more than merely programmers insofar as studies at university can spend an inordinate amount of time immersed in the minutiae of programming.

As part of a recent discussion about programming languages following in part from my earlier articles on the topic and a stimulating presentation at a SE Forum, I read an article entitled An Objective Comparison of Languages for Teaching Introductory Programming (Mannila and de Raadt). To put it in a nutshell, I would contest the word Objective in the title and I think their assumptions about what makes a valuable teaching language and their analysis of the candidate languages against those criteria are both flawed. Some of their criteria, for example, The language is suitable for teaching with reference to Wirth's Pascal and Modula languages are self-serving and circular tautologies.

On the other hand, issues of strong typing (eg. constness), static type safety (i.e. compile-time type checking) and support for reuse via generics, mixins, delegation and inheritance are glossed over or ignored completely. These being some of the very charactistics that make programming languages useful as opposed to such criteria as The language can be used to apply physical analogies in reference to Papert's Logo and Alice that purports to teach object-oriented programming concepts by enabling the student to manipulate objects via their properties and methods in a microworld.

It is as if CS should be taught at university the same way that mathematics are taught through the progression of primary, secondary and tertiary education followed by practice - in the footsteps of Piaget's childhood development of cognition. It trivialises the purpose and mode of tertiary education to suggest that concepts already known should be retaught. The context of the learning environment must be taken into account but teaching object-oriented programming as defining an ontology of classes modelled on the real world - the best description of the thought process being found in Booch's seminal work - is very different to crawling through an object-world sandbox before learning to walk on crippled programming languages designed for teaching.

I think that Bloom's taxonomy or a similar kind of learning path is more appropriate with the tertiary student starting from a higher level from the outset. For example, comprehension is quite distinct from synthesis as evidence of high-level cognitive skills. The same applies for method based reading or code inspections when the inspector can perhaps read and comprehend the code but may lack the technical ability to synthesise the equivalent result in any programming language. Call this a desktop review and arguably one of little value.

Piaget's theories of cognitive development are not applicable to programming because the adult learner is already at an operational stage of competence with abstractions, for example, mathematics. Therefore easy-to-use and simple syntax perhaps are not valid criteria for selection of teaching or industry programming language. Koenig and Moo argue persuasively that C++ is an ideal language for teaching and for industry practice. The study cited uses few if any of the features that set C++ above and C++-like languages including Java and C# apart from the other languages in the feature comparison.

The flavour of the past decade was for C++ and Unix to be maligned as out of step with modern practice however the collective wisdom on Unix has shifted back to one based on common sense; C++ soon to follow in supporting several programming paradigms including functional and generic programming in addition to object-oriented programming. The modern programming languages like Java and C# are becoming more like C++ in feature richness just as so-called modern operating systems are becoming more Unix-like in the elegant simplicity of its design.

Precision teaching in the behavioural formalism of Skinner is perhaps of greater relevance where the reinforcement of outcomes is desirable, again reflecting on industry programming practice and code inspections in the sense of Fagan and Weinberg. Many of the best known text books and reference books available on programming build from an elementary foundation, adding advanced concepts and implementation details according to the authors taste.

Frequently we refer to language features that are not strictly necessary, for example, operator overloading as syntactic sugar. Similarly, the syntax of the language is for all intents and purposes irrelevant since an alternative and equivalent syntax could be substituted. Tritely some argue that their preferred syntax is superior but this is merely an expression of the very-human tendency to believe one's own opinion as to the superiority or elegance of form to be better than another's favoured form.

In teaching and industry practice I do not believe the choice of programming language has as significant an impact as other factors. More important is the way the language is taught, the manner of reading or inspection and other supporting practices, eg. design. I have found that many people who are focused on programming believe that programs are an outcome in themselves however in most settings the business outcome is the only consideration outside of the programming team itself.

Since all of the general-purpose programming languages are Turing complete then business considerations of maintainability and total cost of ownership, for example, mean that project management, enterprise architecture, business processes and issues of service contracts are the business drivers and the implementation mechanism is not directly relevant.

CS and SE degrees programmes must include significant mathematics components. The coverage of material and degree of difficulty depends on the goals of each school however the fundamentals of logic, set theory, statistics, matrix algebra, sequences and series must always be included. Not every graduate needs to know much or perhaps anything about multivariate calculus of a complex variable, number theory, or advanced numerical methods.

Some of this material will probably be covered adequately in a unit on algorithms or maybe even robotics. Probably not to the same level of rigour as if the material were taught in a mainstream unit taught by the mathematics department or even one customised for the needs of CS and SE.

The objectives claimed from teaching simplified programming languages specially designed for this purpose are questionable. The example earlier in this article where the programming language Alice is used to teach object-oriented concepts captures the fatuous assumption that the students in such course do not learn basic mathematics. Set theory, for example, captures and defines the concept of class and object together with axioms, mappings, functions and properties. Likewise a course on algorithms should build on or, if you please, specialise rather than replace or reinvent a unit on numerical methods.(*)

To summarise, we should treat our students as adults not as children to be molly-coddled!

(*) I could launch into a discussion about the seemingly unknowing teaching of kinetics, kinematics and dynamics in physics, mathematics and engineering units simultaneously with equivalent concepts in fluid dynamics and electrostatics.

For example, the curl and div of vector potential fields in Navier-Stokes and Maxwells equations, or more simply the moments V=I.R and F=M.A where V=voltage, I=current; F=force vector, M=mass, A=acceleration vector=second derivative of vector displacement; .=scalar multiplication or vector dot product.

But I won't. :-)

0 Comments:

Post a Comment

<< Home