TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Fri, 15 Jun 2001 12:49:56 -0400
Michael Feldman <[log in to unmask]>
Michael Feldman <[log in to unmask]>
<> from "Mike Stark" at Jun 15, 2001 11:47:13 AM
text/plain; charset=us-ascii
text/plain (114 lines)
Mike Stark et al,
> My opinion is that change is needed in how computer science is taught -- it
> is at least as important to understand how an event-driven interface such
> as Java Swing works as how indexed indirect addressing works -- a lot more
> people will be develoing user interfaces than OS kernels or device drivers.
> I think UI design is good to introduce as early as possible, as it gives
> the added benefit of teaching how to read and understand a library such as
> Swing.  But the choice of language should follow from educational goals,
> and I didn't see much about what the goals of CS1 should be in that thread.
> Perhaps Mike Feldman can enlighten us all ;)
> Mike
Well, since Mike S. invited me to jump in...

CS education has always been fraught with debate over what to teach,
and - more to the point - in what order to teach it. After 26 years of
teaching courses ranging from freshman level to doctoral level and
just about everything in between, and nearly as many years of going
to SIGCSE conferences and suchlike, I observe that:

- there is reasonably good consensus - in the respectable departments -
  on what we should teach over 4 years.

- there is _no_ good consensus - and, IMHO, unlikely to be much in
  the forseeable future - on the propr order.

The main difference between full-scale undergraduate programs, on one
hand, and "training" programs like commercial certifications, 2-year
community-college things, etc., on the other hand. is that the former
focuses more on fundamentals - those things that _don't_ change
from year to year, while the latter focuses more on short-term
concerns - products, "technologies", and skills.

Obviously there is a lot of "skill" stuff mixed into an undergrad
program, but there is much more than that also.

If you're interested in reading about the nearest approximation to
a consensus view of a good undergrad structure, see the accreditation
standards published by CSAB, which is a creature of ACM and the IEEE
Computer Society. Visit for this. Click on "Criteria 2000"
for details; click on "Comp. Sci. Profession" for the underlying
philosophical basis.

You'll note that while some subjects in the standards are "obviously"
introductory, abnd others are "obviously" advanced, in most cases
CSAB does _not_ prescribe an order to introduction.

There is little - if any - credible comparative research on the
various tradeoffs in selecting presentation orders. For example, should
we do UI's "early" (as Mike suggests)? Some do it, and claim success.
Others present UIs "late", and claim success. Nobody can _prove_ one
is better than the other. Similar with O-O concepts, computer
architecture, blah-blah.

In fact, if over 4 years, we are all teaching the subjects we agree
on (and, as I said, there is pretty good agreement here), then the
order really doesn't matter much and we can let each department
follow its own tastes. I think this is the case, and probably always
will be. It's not really productive to spend too much time trying
to change some department's presentation order.

My bottom line to students AND to my colleagues in industry is this:

As a designer of a _4-year_ curriculum (and I AM the curriculum chair
in my department!) I am obliged to produce _seniors_ who have these
basic attributes (in no particular order):

- are prepared for their first job, but also for their 10th job
- understand what changes and what doesn't
- can make design choices
- can tell the difference between revolutionary breakthroughs
  and marketing bullshit
- have enough math and science in their lives to be able to
  communicate with scientists and engineers
- can prepare a decent written report
- can give a decent oral presentation
- can work as a member of a team, not just as an isolated geek

(Aside: If they can read an API like Swing, fine, but if they can't,
they can learn, because in college, they've learned how to learn.
If they haven't learned how to learn, don't hire them!)

OK, that's what I'm obliged to produce. I am NOT (NOT!!!) obliged to

- A worker bee who can jump right into a project with absolutely
  no on-the-job education into the tools and cultures of his/her
  employer. Employers must be willing to invest in their employees.
  If your employer won't invest in you, don't work there!

- A second-year summer intern who has exactly the right skillset
  the employer demands. You're an intern - there to learn, not to
  produce. If your employer doesn't understand this, quit and
  do something fun in the summer. I was a summer camp counselor
  till I got tired of it.

The above is part of my standard lecture to undergrad advisees,
of whom I have roughly 125 right now.:-)

Whew! I'm sure that's more than you bargained for, but that's what
you get for inviting a prof into this discussion!

Oh - if you have a few minutes, read a piece of mine:

Sigh... you asked for it.:-)


Mike Feldman