From: klausf@softwks.osgo.ks.he.schule.de (Klaus Fueller)
Subject: ACM Curriculum Proposal --- some remarks.
Reply-To: KlausF@OSGO.ks.he.schule.de
Organization: Softwerker-Gruppe am OSGO
Date: Fri, 14 Aug 92 19:48:50 GMT

$Header: /u/klausf/schule/curr/RCS/us-curr,v 1.1 92/08/14 21:45:40 klausf Exp $

\section	{Introduction}

I would like to publish some remarks on the High-School CS-Curriculum
as it has been proposed by the ACM Task-Force.  I've got a version
of this paper which is obviously from about October 1991.

I'm a Maths/Physics/CS-teacher in Germany so my remarks may be of little 
or no relevance the American discussion.  
I even have little experience teaching students below 10th grade 
but my remarks are motivated by the fact that I'm one of the initiators 
for the task-group CS(Informatics)-curriculum 
in the German federal state of Hesia.

So this is the reason I submit this paper: I am very interested in
your remarks about CS-curricula.

For two reasons the remarks are difficult for me to make

\begin{enumerate}
\item I have difficulties to express myself in English
   in an adequate and differenciated way.  If you are 
   about criticizing someone you have to choose your words
   very carefully. I'm not so sure if some of my remarks
   will not sound arrogant in your ears.  This would in
   no case be intended. Please regard the following text 
   as the expression of the problems I personally have
   with the proposed curriculum.
\item I agree with the (authors of the) proposal in their
   general remarks in the ``Introduction'' and ``Focus of Task''.
   But the more the proposal makes concrete statements 
   the more uncomfortable I felt while reading it. 
   When I finally read  ``B: A Sample Course Outline'' I 
   considered it be really impossible.  This makes the critics
   difficult as we obviously agree in at least some general
   aspects but disagree in many practical consequences.
\end{enumerate}


\section	{Fundamental Remarks}

The proposal tries to design a CS-course which is similar in level and
methodology to ``typical high school pre-college science courses''. The
course should concentrate on ``fundamental scientific principles and
concepts'' in the field.

Who doesn't agree with these goals.

The goals must be
\begin{enumerate}
\item	to (generate or implement or ?) in our student's mind 
	a working {\em model} of how a computer works
\item	to give to our students some basic insight in the
	fundamental methods of computer science namely in
	structures and abstractions. This has very much to
	do with mathematics and this is the central part of
	an introduction to C{\bf S}.
\item	to show very few typical examples of computer
	applications and the impact of computer usage
	on society.
\end{enumerate}

The main consequences of this approach must be
\begin{enumerate}
\item to carefully select the few fundamental principles
	of CS that are to be taught and
\item to make a reasonable proposal of topics which
	illustrate these basic principles.
\end{enumerate}

My personal opinion is that the ACM-proposal misses many 
of these aspects.

The proposal tries to `cover the field' with adding one topic
after the other without justifying the topics and their mutual
relationship (except that each topic has `something to do with 
computers').


\section	{Some details}

\begin{itemize}

\item The proposal is too voluminous.

I don't know how good and effective American students learn. 
The proposed contents could not be taught to German students
in a 2-semester course with 3 periods a week.

((This is all in all not so important.))

\item The proposal is too technically oriented.

What do you have to know about a computer in order to use it?
What should you know about how a computer works?

I think you should know that a computer is a machine 
that executes algorithms.  If you use an interpreter language
you can dream of the processor to directly understand the
language.  If you have a compiler you must learn that the 
processor has its own language.

But in no case in an {\em introduction} you have to learn
about ``buffered I/O'', ``circuits'', ``gates'', 
``representation of real numbers'', ``fetch-execute-cycle''.

Computer architecture should be taught only as far as
it is necessary to construct a {\em model} of what's going on 
in the machine.


\item The proposal requests far too many languages.

The question of a language you use to `communicate' with a computer 
certainly is of central interest to a CS-introduction. It is well
known that the language plays a major role in building up a model
of what is going on in a computer. The ``course outline'' asks the student
to use the following formal languages 

	\begin{itemize}
	\item	command interpreter language
	\item	spreadsheet language
	\item	data-base language
	\item	assembly language
	\item	general programming language (probably PASCAL)
	\item	LOGO or graphics language
	\item	a ``graphical user interface''
	\item	expert-system language
	\end{itemize}

Every single one out of these languages makes its own assumption
about what the human user of the language thinks about computers.
Every language assumes a possibly different model of computing.

Using all of them in a beginner's course will generate 
the big mess in the heads of the students.


\item	I refuse teaching  computer applications.

I teach computer applications only to show some common structures:
Menu-Systems, Command/Data-Input, Help-System.

I will not teach a commercial application as such: ether the 
application can be used by intuition: than you don't have to teach it.
Or the application is difficult to use: than I don't see why I
should teach it.

When the student leaves school the application is very likely 
to be out of use.


\item	No software engineering

Software-engineering requires a kind of organization that is untypical
for the school-environment.  If you want to program relevant projects
you have to learn very much about the methodology of programming.
I think you have to learn so much about it that you can fill up a
2-semester's course with it.

If you take smaller projects the methods of software-engineering will
rather hinder your work.

Please understand my the right way: I'm very much for letting our
students cooperate in solving problems of any kind.  

In physics I want to talk about what electricity is and how it is to be
used and not about all end every detail of how to connect wall-outlets
and switches.  To day software engeneering is the CS equivalent of
installing wires in a building.
\end{enumerate}


\section	{Conclusion}

The more practical the proposal gets the less I see concepts and the
less I see how students can acquire an UNDERSTANDING of what a
computer is.

I don't see a justification for many subjects (which is again a
consequence of missing concepts): what has "probability" (``Outcomes
when tossing coins and throwing dice'') to do in a CS-curriculum?
-- 
Mit freundlichen Gruessen		Klaus M. Fueller, Kassel
With kind regards			KlausF@OSGO.KS.HE.Schule.DE
Avec mes sentiments les meilleurs	KLAUSF%OSGO@URANUS.ZER (from Z-Netz)