TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

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
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To:
"W. Wesley Groleau x4923" <[log in to unmask]>
Date:
Fri, 3 Dec 1999 16:42:33 -0800
Reply-To:
AdaWorks <[log in to unmask]>
Subject:
From:
AdaWorks <[log in to unmask]>
In-Reply-To:
Content-Type:
TEXT/PLAIN; charset=US-ASCII
MIME-Version:
1.0
Parts/Attachments:
TEXT/PLAIN (89 lines)
On Fri, 3 Dec 1999, W. Wesley Groleau x4923 wrote:

> Look, if schools would just shift their programming emphasis to VB and
> Excel, in only one generation, Microsoft would be unable to "improve" or
> even maintain its products.  And that would be a Good Thing, right?,

I am reminded of a line attributed to one of the early "bodice rippers"
in the romance novel genre, "seduced and abandoned."  During the early
days of the personal computer, the "killer app" was VisiCalc followed
by Lotus 1-2-3, both of which were eclipsed by MS Excel.  Concurrently
with spreadsheets we saw the emergence of database products evolving from
DBII through DBIII, DBIV, Foxbase, Quicksilver, and whole host of others.

One of the interesting properties of these "killer apps" was their ability
to seduce ordinary folk into believing they were actually programming. The
learning curve for each was quite steep, misleading the user into a false
sense of confidence about what could be accomplished.  With Lotus, once one
got a little further into building applications, it became necessary to learn
how to program "macros."  Those who remember macros will recall how fussy
they were when one tried to alter them.  With the dBASE family of products,
it did not take long before one discovered that, to do real applications, one
had to learn the associated programming language, how to call procedures from
other procedures, and lots of entertaining little quirks that made the
difference between an operational program or a lot of midnights sorrowing
over misunderstood consequences of obscure syntax.

When we make programming really easy at the beginning, we must ensure that
our students are aware that real programming is not at all easy.  It took
us a long time to persuade our clients that the prototype is not the product,
no matter how lovely it looks on the screen.  We must also make certain that
students are not seduced into believing that what they do in the early stages
of VB programming represents the real art of computer science.  This is, in
fact, a very real danger of making the learning curve too steep.

On the other hand, if the curve is too shallow, the students may feel that
everything they are learning just takes too long. If we enter the curve at
the wrong place, they will be unprepared.  I have been guilty of both
offenses at one time or another, usually because I misjudged the needs or
preparation level of my students.  As fascinated as we might be by some
aspect of partial differential equations, it is no surprise to anyone here
that we could not teach that subject to anyone with no foundation in college
algebra.  The same is true of software engineering and advanced programming
concepts.

I am concerned that starting students with a language such as VB leads them
to a false idea of what computer science is about.  At the same time, I am
confident that this is not the case when those students are under the
guidance of an instructor such as Dr. Conn.  However, under less experienced
tutelage, a student whose first language is VB may very well find himself
or herself "seduced and abandoned" if it is conveyed that VB is actually
computer science, or even good programming practice.

One programming manager I know here in Silicon Valley will give preference
in recruiting to graduates who know several programming languages. He also
has little patience for those who think only one of the languages is any
good.  Though this attitude is rare among employers, it does exist.

Ada can be as good as a first language as VB, C++, Eiffel, or any other. The
important thing we promote in our students is the ability to think critically
about choices, including programming language choices.  Those who graduate
with this ability will make appropriate decisions when the time comes. If we
teach Ada, we should also teach C++ and other languages.  As things stand
now, there is no "perfect" programming language.  We are preparing students
for a future in which entirely new languages will be designed.  Let's not do
them the disservice of making them think the Microsoft products are all that
wonderful, their not.  Let's not indoctrinate them at all.  If they learn
the fundamentals of programming language design, the fundamentals of
programming, and the characteristics of good programming practice, we
will have done our job.

Ada should be part of the mix.  So should VB.  So should C++ and Eiffel. We
are preparing these young students to think.  The more ways they have of
looking at a problem, the better they will think about the solutions.

So for ranting on and on.  It happens just after I return from a very long
airplane trip, as some of you know I have just done.

Richard

Richard Riehle
[log in to unmask]
AdaWorks Software Engineering
Suite 30
2555 Park Boulevard
Palo Alto, CA 94306
(650) 328-1815
FAX  328-1112
http://www.adaworks.com

ATOM RSS1 RSS2