Re: Re-designing CS (long)

[bjquandt@mail.delcoelect.com (Brian J. Quandt)]

In article <31ca2b3b.184418880@news.cyberport.com>,
   tangent@cyberport.com (Warren Young) wrote:
>First, what of the question of what language to start with?  I've not
>thought it through too closely, but I think staying with the Pascal
>family probably has its benefits.  


My suggestion would be Fortran 77 or C.  A lot of the stuff currently out was 
written before Fortran 90 came out (and, consequently, is written in Fortran 
77).  Most new stuff is written in languages other than Fortran, so most of 
their contact with it will be maintaining/modifying/rewriting older programs. 
The knowledge of Fortran would allow them to interpret the older code more 
easily.

C is a good building block for C++ (ie. C++ is a superset of C), so C would 
allow the students to gain a good understanding of programming before 
advancing to the advanced elements of C++.


>They would also learn how to read design diagrams appropriate to the
>language -- for example, Unified Method for C++ and Ada 95, a
>structured design methodology for (ewww!) COBOL, etc.  This lets the
>professors supply the design (just like the real world: newbies get
>the design handed to them from On High).  This makes sure that
>everyone can talk about their programs and have people understand
>them.
>
>Currently, students do their own design.  Often, the professor will
>essentially give it away in his lecture, but the students aren't
>actually constrained to a given design.  I wonder if this is the right
>way to go.  Isn't it better to teach the students programming first
>and design second?  This lets a student focus on learning good
>programming at first; as they program to the given design, they will
>absorb the basic lessons of good design.  Eventually, they can be
>turned loose to do their own design, and having a grounding in basic
>design principles, they will less likely to make any of the basic
>design mistakes, so they'll learn faster.

No, no, no!  Doing this type of thing would make all students think like the 
professors that they have, which is not usually a good thing.  The result 
would be a bunch of non-innovative programmers.  The only time I would hire 
someone I knew to not be innovative is if I were managing a McDonalds.

Your model would be like teaching a driver's education class, and not teaching 
"Reverse" until the second half of the class -- not a very productive idea, 
IMHO.

-----

Personally, I took an "Intro to UNIX" class first semester, and an honors 
programming class second semester (first half Fortran 77, second half C).  
Third semester is "Advanced C Programming."

In my first programming class, we had two individual projects and two group 
(~4-5 people) projects (1 ind. & 1 grp. per language).  We were to do all of 
the projects ourselves, although the professor *did* hint at some basic design 
ideas.  However, each of the projects had vastly differing results between 
groups, which benefitted the students (ie. we could see other ways of doing 
the project).

A sample of projects we did (or previous semesters did):
     resolve image files into black and white (from PGM5 format)
     an iterative approach to integrating an input equation
     solving X number of simultanious equations (one of our weekly labs)
     a basketball stats input/output program
     an ATM machine (w/ encrypted password, support for X users)


Just my thoughts,

Brian

________________________________________________________

Brian J. Quandt
     Computer Engineering Student, Purdue University
     Summer Intern, Delco Electronics
     bjquandt@mail.delcoelect.com
     bquandt@holli.com
________________________________________________________