Hi all,

This is a rather long discourse on curriculum, a bit off-topic
for Team-Ada, but since the subject came up I thought I'd write
it. Use your delete key now or forever hold your peace.:-)

* * * * *

For those interested in Ada in UG curricula -- whether you're an
educator or not -- we have a mailing list on the subject, which
has been pretty dormant.

I'm sending another copy of this note to that list, and would like
to continue it over there, where it's more on-topic.

To subscribe, send e-mail to

[log in to unmask]

with the 1-line message

subscribe ada-first your_first_name your_last_name

(substitute your real name, please!)



* * * * *

I'd like to add a point to my note about curriculum. I said
earlier that I had no quarrel with introducing Visual Basic (VB)
in the first course; I realize now that I was referring to VB as
a language. In fact, I do have a quarrel with VB -- not in
general, but as the first-course tool -- because it is, by
definition, proprietary and nonstandard.

This reluctance stems not from any special anti-Microsoft
feelings; my sentiments -- and, happily, those of my department
-- go back to way before Microsoft even existed. Our faculty has
always taken the stance that we have four years to educate our
students, and that the curriculum should move, through that time,
from the fundamental (and, in software, the standard) to the
industrial-strength and product-specific, not the other way
round.

There are two main reasons for this:

(1) Beginning students tend to think the tool they are using is
the only one, or the main one, and resist attempts to move them
to other languages or platforms. So it is important that their
first tools be stable and nonproprietary; we have 4 years to move
them progressively into the ephemeral and proprietary products
that tend to drive industry through one fad after another.

The goal is to prepare them for industry's current pets just
before they move into industry, not four years earlier. By the
time they graduate, industry may well have chosen other pets.

(2) Using standards, per se, sends the right message to
impressionable 18-year olds. Standards make our world go 'round.
When you buy a light bulb, you know pretty much what makes a
25-watter different from a 75, and you don't need to worry
whether the brand of bulb you buy will screw into the socket in
your desk lamp. Students can understand this, but we need to
focus them on it before they can do so.

It's true, of course, that a standard often starts in one company
and is then adopted by the industry as a whole; sometimes (as in
the Ada case) the standard is designed ab initio with industry
participation. What matters is not how it came to be the
standard, but that it is. We all know that Fortran started with
John Backus at IBM and Cobol started at Univac with Grace Hopper,
but both were adopted before long, across the industry. (Uncle
Sam helped the process along, of course, but that's beside the
point.)

The point is that while the juniors and seniors should be working
at the cutting (or bleeding) edge of technology, the freshmen
need to work with stuff that's stable and time-tested and
fundamental.

* * * * *

Teaching freshmen is _hard_, which is why the job is so often
(disgracefully) fobbed off on grad students and the nontenured
junior faculty (or even part- timers who work for a pittance!),
while senior faculty who have a choice stick to their
junior/senior/grad specialty stuff and wouldn't touch a freshman
course with a 10-foot pole.

(We teachers of Ada -- like Scheme and ML folks -- are something
of an exception -- often we are senior people who genuinely
believe that the first courses are the most important, and want
to build our students' education on the right first platform. But
that's for a different discussion.)

Our freshman courses cannot be constantly changing to suit the
latest version of nonstandard (or prestandard) tools. We need
stable texts, stable compilers, stable APIs, etc. Otherwise our
youngest, least experienced, students are always being used as
unwitting experimental guinea pigs. This is unfair; if we do this
to them, at the least, we should ask them to sign human-subject
release forms.

(Aside -- at GW we are doing exactly this in a series of
empirical studies on the effects on an intro course of
introducing tasking in it. See

http://www.seas.gwu.edu/~csersrch

for links to this and other similar experimental work. And yes,
we do ask the students to sign those forms!)

To see the problem, look at the present turmoil in the
Java-in-CS1 movement, in which professors, students, and textbook
authors are being jerked around by the trend away from Java 1 to
Java 2 (that is, from AWT to Swing). This is horribly
distracting, and cannot be contributing positively to the
education of our freshmen!

* * * * *

At GW in 1975, we were teaching Fortran (using texts that taught
_standard_ Fortran 66, not IBM's Fortran G dialect). We've tried
to stick to standards ever since, moving to de facto standard
Jensen-Wirth Pascal, then to Ada 83 (CS2 course in 1985 after
experiments starting in 1983, CS1 course in 1992), then to Ada 95
(in 1995).

At GW we've had brief flirtations with proprietary dialects, in
particular with Turbo Pascal in the late 80s. We wanted to get
the benefits of nice PC editors, etc. We were _wrong_ to do this
with freshmen. We found 4 big problems:

(1) It gave an unfair advantage to the kids who had used PCs in
high school (at least that was the perception of those who didn't
do it in high school).

(2) It made the kids think that Turbo Pascal _was_ Pascal, and
when we moved them over to Unix in the second year, they had a
rude awakening when the language turned out to be different. And
they resented that we took the nice Borland API away.

(3) They learned to use the "build and run" button in the IDE,
which messed them up later when they actually had to learn about
compiling and linking. They had been taught the wrong first
"mental model" of the process. We had "dumbed it down" for them
and we all got burned.

(4) It played into their PC addiction and made it much harder to
move them over to a shared system (Unix) when we had to do so.
After all, these were CS majors, not end users, and they had to
learn not only Unix but how to share stuff properly. This is more
a problem with male students than with female ones.

So currently in our intro courses, we are doing Ada 95 with GNAT
under Solaris, using our labs' Macs and PCs as telnet terminals.
We have a few scripts that encapsulate many of the flags to the
compiler, binder, and linker, but we don't tell them about
gnatmake. They must learn what compilation and linking is about
-- this is fundamental.

About halfway through the 2nd course students must compile enough
packages and clients that they get impatient and ask whether GNAT
offers any shortcuts. Then we tell them about gnatmake but not
how to use it -- they must read the GNAT docs for this
"just-in-time learning." :-)

Students who have their own computers aren't forbidden to use
them, but we encourage them to use them first as terminals, then
move to CodeBuilder or AdaGIDE or Linux as they get better at the
Ada part.

* * * * *

About our students: we collect demographics in every semester in
these courses. We discover two characteristics that have been
astonishingly stable for at least 5 years:

(1) Roughly 50% of the freshmen have their own computers. It's
NOT true that every kid brings a computer to university!

(2) While most incoming students have some computer _experience_
(writing, web-surfing, whatever), roughly 50% of them have no
_programming_ experience whatever. It's NOT true that "all the
kids are doing programming in high school!

And these are kids with the money to pay GW's tuition, and/or the
grades to get GW's merit scholarships, so they are mostly pretty
high on the economic scale!

Comparing the first-course grade curves with the demographics,
I've found (stably, over 5 years or so) that

(1) The top very 3-4 in the class generally have prior
programming experience; we can't completely negate this effect.

(2) The very bottom 3-4 have had no experience. They end up as
clueless as they started. Too bad, but we just cannot reach
everybody.

(3) In between those extremes, all categories of students seem to
hit the same curve, which is more-or-less the usual bell-shaped
one. So for most students, our advertisement that the course has
no prerequisites, and requires no student-owned computer, is
borne out in practice. Some do well, others not, but there are no
built-in biases: _everyone_ can potentially succeed, and most do.

This may be a reason why our low dropout rate -- from the first
course, not from the program overall -- is not much more than
10%. We are teaching what we advertise.

(Aside: our experience, and the more formal studies done by our
UG admissions department, both show that the strongest predictor
of success in all engineering-school fields -- CS is in
engineering at GW -- is success in a good high school calculus
course. Most of our program dropouts quit because they fail
first-year calculus and/or science; a CS major who makes it
through the first 2 years will usually graduate.)

* * * * *

Finally, just a point about Ada, _per se_. Our _seniors_ were
interviewed last fall about some proposed curriculum changes.
With the benefit of 3 years' experience, the students recommended
(among other things) that

(1) We reduce the amount of plain C in the middle 2 years and
increase the amount of Java there. C++ is desirable but not
essential in required courses.

(2) We stick with Ada in the first two courses. The students said
it was the best place to start their education. One of the best
things (they said) was the great GNAT error messages, which they
only appreciated after they coped with C/C++/Java compilers.

I'm looking forward eagerly to introducing some jgnat and jrapid
work next semester, probably toward the middle of the second course.

Visit

http://cs.seas.gwu.edu/undergrad

for all the details of our curriculum. Some courses -- not all
yet -- have detailed outlines and other materials linked from the
overall curriculum page. As you can see, the newest curriculum will
offically take effect in Fall 2000, but it's an incremental change
from the earlier 1996 version.

* * * * *

Whew! Thanks for your patience!

Mike Feldman