LISTSERV mailing list manager LISTSERV 16.0

Help for TEAM-ADA Archives


TEAM-ADA Archives

TEAM-ADA Archives


TEAM-ADA@LISTSERV.ACM.ORG


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

TEAM-ADA Home

TEAM-ADA Home

TEAM-ADA  December 1999

TEAM-ADA December 1999

Subject:

First-year courses, standards, and Ada

From:

Michael Feldman <[log in to unmask]>

Reply-To:

Michael Feldman <[log in to unmask]>

Date:

Thu, 2 Dec 1999 09:46:55 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (255 lines)

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

December 2017
November 2017
October 2017
September 2017
June 2017
May 2017
April 2017
January 2017
December 2016
November 2016
October 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
December 2010
November 2010
October 2010
September 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
June 2007
May 2007
March 2007
February 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
June 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
July 1999
June 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
January 1998
December 1997
November 1997
October 1997
September 1997
August 1997
July 1997
June 1997
May 1997
April 1997
March 1997
February 1997
January 1997
December 1996
November 1996
October 1996

ATOM RSS1 RSS2



LISTSERV.ACM.ORG

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager