Re: U.S. colleges retool programming classes - Yahoo! News WORTH READING --

[David Farber <dave () farber net>]

Begin forwarded message:

From: Gene Spafford <spaf () cerias purdue edu>
Date: June 3, 2007 10:35:59 PM EDT
To: dave () farber net
Cc: ip () v2 listbox com
Subject: Re: [IP] Re: U.S. colleges retool programming classes -  
Yahoo! News WORTH READING --

I had a reply started, but tossed it upon reading Rod's very  
thoughtful reply.  So, let me touch on a few other points.

First, my background -- I'm an academic.  I teach students. I create  
courses.  I've served on curriculum committees at local and national  
levels.  I'm probably pretty good at what I do, because I've won a  
number of major awards as decided by peers and students.  But even  
more important -- employers tell me they love my students, my  
students tell me they got great preparation for their jobs, and they  
almost all are in significant positions.  I regularly talk to  
recruiters to learn what they look for -- and our students are  
generally a good match.  Few of them write code as a major part of  
their jobs.

Some people have groused that the CS graduates they get aren't  
prepared to do exactly what they want, including some from well-known  
schools.  Well, keep in mind that:
  1) Schools and faculty are different, with different priorities  
and experiences
  2) Students are different, have different abilities, and even at  
"name" schools, half the students graduate in the bottom 50%.

Thus, it isn't fair or correct to make sweeping accusations about all  
of CS education based on observing a small group of students from a  
few places.  Nor is it proper, necessarily, to think that the "top"  
universities produce the best undergrads.

My job is not to prepare students to graduate and immediately take up  
job X that someone wants.  It is to provide them with a broad  
education in the science and engineering of computing so that they  
are in a position to quickly learn new concepts and keep current in  
the field -- enable breadth and lifelong learning.  The students  
aren't a finished product, and if we do our job correctly, never are.

We don't produce programmers.   Anyone can learn programming -- all  
they need to do is buy "C for Dummies" and they can learn to  
program.  But that isn't learning fundamentals.  For instance, ask  
people who know how to program to write a sort routine and they can  
do it, although the results may not be pretty -- or efficient.  But  
task people with a good CS education -- who have had some background  
in algorithms, big "O" complexity, and data structures -- and they  
should ask about input data set sizes, whether identical key sorting  
needs to be non-destructive, whether the set is pre-ordered, and  
whether the sort needs to be inplace or not.  That may be obvious to  
you, but non-obvious to someone who hasn't been exposed to the  
*science* in computer science.

What about automata theory?  That's valuable to understand issues as  
diverse as pattern matching, parser construction (for input  
languages), running time and space complexity, and why some programs  
simply can't be constructed.   Ask a code monkey to write a program  
to validate if the parentheses and operators are properly matched in  
an input arithmetic expression and see how long it takes.  A good CS  
grad should understand the use of stacks and recursive parsing, and  
be able to do it with some minimal (or no) consultation of a  
reference.  You may not *think* you're using automata theory after  
you graduate, but it informs a lot of what decisions are made even if  
it isn't explicitly referenced.

We expose our students to lots of topics so they understand the  
science and complexity of what they are doing, and some of what goes  
on "under the hood."  Why teach operating systems?  To understand  
what deadlock is, why parallelism is difficult, how file systems work  
and what it means when they get corrupted, what a device driver is  
and why it is needed, and how access control works.  It's amazing how  
often those concepts are useful in a career.

The list of examples goes on. A programmer knows programming; a good  
CS grad knows a heck of a lot more, is capable of understanding more  
new things with less effort, and is able to keep up with technology  
changes in the field over the course of their careers a lot better  
than someone who only knows how to program C# and html -- this week.

Now as to specific complaints about some students.  Yes, we have  
students who won't listen and take the easy path through the  
curriculum.  We also have students who squeak through and never  
really work hard enough to get the material thoroughly.  Most of them  
get employed, but they aren't as proficient in lots of things that we  
wish.  Some schools focus so much on the theory that they don't  
balance it with practical skills in software engineering,  
programming, and the like.

Of course, many of our students excel, take hard courses, do  
extracurricular work, maybe pursue a graduate degree or two, double  
major in another area, and do internships.  You won't see those  
graduates -- they are going to work in more senior positions right  
off.  There are company recruiters falling all over themselves to  
find those people and give them meaningful jobs.   And those students  
know enough not to bother looking at jobs where the requirements are  
listed as simply knowing how to program javascript  and use version  
control, and where the interviewer shows disdain for the fact that  
they took courses to give them breadth.

There are certainly things I wish I could include in our curriculum.   
However, we are limited in how much time we can spend on required  
courses.  Students need to meet university requirements in  
communication, history, general science, foreign language, and math.   
They also want to take some electives for their own growth and  
interests.  And thus, we only have so many classes we can offer.  I  
wish we could teach real-time OS in assembler, for instance, and  
programming system comparison with APL and PL/1 and LISP and ML and  
Euclid and Modula and Smalltalk and....  Instead, we settle for  
general skills that should make it possible for the students to learn  
those languages on their own if they need them.  I wish we could  
include a mandatory sequence in software engineering instead of a two- 
semester elective.  And so on.

I wish I could teach my students on several hardware and software  
platforms commonly used in industry.   However, the vendors don't  
donate those to the university (with maintenance -- especially  
important if I build a course around them).  Thus (for instance) we  
have one of the top information security programs in the country, but  
we can't give the students hands-on experience with commercial  
firewalls or IDS systems because we don't have any, and we certainly  
have no budget to buy any.  (And that's true at most schools -- if  
you want a conversation on the funding in higher ed, I'd be happy to  
have it.)  That also holds true for any commercial software  
engineering tools.

I'd like to have my students work in a large team on a project that  
is too big for them to see it completed despite several years  
effort.   However, I need to provide grading and feedback  
individually to the students, and have a means for transfer students  
to fit into the system.  I also don't have resources for such an  
effort.  So, most of the pedagogy is directed towards (at most)  
semester-long projects, and we include teamwork on some of them.

Are we teaching dead skills?  I hope not.  We don't use Jovial and  
Cobol in classes anymore, for instance, or IBM 360 assembler.  But  
consider how quickly things change in our field -- teaching things  
that are "hot" today is not necessarily going to be useful for our  
alumni of 10 or 20 years from now.  Fortran and Cobol were "hot" 20  
years ago, as Java and Python and Ruby on Rails are "hot" now.  We're  
trying to focus on the basic skills and the underlying science that  
ties together the whole field and will be useful in 30 years, long  
after many current fads are dead and gone.

That last statement is, in summary, the difference between a "ready- 
to-code" software engineering graduate and someone graduating from a  
good computer science program.  One can build commercial systems  
starting today, and the other understands why and how things work in  
computing but might need some on-the-job training to get up to speed  
on the systems in use.  Both have roles to play.

And as to why we want more computer scientists -- I am looking  
forward to the new languages, running on new operating systems, using  
new network protocols, and supporting amazing new apps that have not  
yet been invented.  Some of those may be crafted by hobbyists, but  
the majority will be designed, tested and built by CS grads.  If you  
think Windows and C++ are the pinnacle of human achievement, then I  
guess computer science isn't going to have much appeal.  But dang,  
you sure are going to need those debugging and version control skills!!



-------------------------------------------
Archives: http://v2.listbox.com/member/archive/247/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com