NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/edu/2196

Internet Message Format | 1992-12-16 | 3.6 KB

Xref: sparky comp.edu:2196 comp.lang.misc:4023 comp.software-eng:4922
Newsgroups: comp.edu,comp.lang.misc,comp.software-eng
Path: sparky!uunet!ornl!rsg1.er.usgs.gov!darwin.sura.net!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!purdue!yuma!csn!nugget.rmNUG.ORG!jacob
From: [e-mail] (Jacob Gore)
Subject: Re: Programming language evaluation criteria
Message-ID: <[e-mail]>
Organization: Rocky Mountain NeXT Users' Group
References: <[e-mail]>
Date: Sun, 13 Dec 1992 18:35:58 GMT
Lines: 62

If it's pragmatics you want in language selection, here's the list:

1.  See what languages the people who fund your project or pay your
salary want you to use.

2.  See which of those have reliable implementations available and
affordable.

3.  See which of those your teammates know or are willing to learn.

4.  See which of those your teammates want to use.

5.  Use it (learn it, if necessary).

Having got this out of the way, I explain to the students in my
comparative language class that the reason they need the class is not
to learn a bunch of languages, but to discover a variety of problem
solving approaches.  They do that by doing exercises in ML (a
math-looking strongly-typed functional language), Scheme (an
assembly-language-looking dynamically-typed functional language where
one can execute data structures one builds), and Objective-C (a
dynamically typed but strongly typable traditional/object-oriented
hybrid language -- my first choice would have been Eiffel, then
Smalltalk, but I have neither handy).  I give assignments that are
easy to do if you let yourself flow with the new (to most of the
students) paradigm, but suffer greatly if you try to do things the old
way.  (If time permits, we also do Prolog.)

Later, when they are forced to use whatever language filters through
the first four lines of the above list, they will (hopefully) be able
to reason along the following lines: "Well, this problem would have
been a two-liner in ML, but the language I have to use is K&R C with
no vararg library.  Still, I can try using recursive functions without
side-effects and that will simplify the data structure needed, so
here's how I can design this........"

Learning a language for the sake of learning a language is about as
stimulating as learning all the legal chess moves.  Picking a language
within one paradigm is like picking the shape and color of the pieces
and the board: the choice will indeed make it easier or harder to
play...but it is all insignificant if you are a bad strategist.
Computer science education should be about becoming a good strategist.
Exposure to other paradigms is like playing other strategy games: it
is usually not directly translatable into chess moves, but it provides
enlightening insights.

Sorry for the unsolicited preaching, Jim, but I'm a big believer in
the "teach concepts, illustrate with specifics" approach (as opposed
to "teach marketable skills, leave concepts for grad school" approach,
whose proponents always want me to teach some bandwagon language.  As
David Gries puts it (don't know if he quotes someone else): "program
INTO the language, not IN it."  I do not for a moment think that
you're in the bandwagon language camp (if you were, you probably
wouldn't be thinking hard about language selection criteria), but the
comparative language course is such a wonderful opportunity to make
students reevaluate and enrich their bag of programming techniques...

Jacob
(a horrible chess player, actually:-)

Jacob Gore, Eastern NM U.   [e-mail] | [e-mail]
Member of the League for Programming Freedom (LPF)[e-mail]