thr1@ra.MsState.Edu (Thomas Ritter) (03/14/91)
Hello, I've been hearing some discussion in our department about changing our primary language from Pascal to something else. I don't want to start the Ada vs C vs "other" argument.... I would like to hear what people consider important in making a decision. ( Usefulness in the real world, teaching ease, programming environment... etc.) I would also like to find out what some other schools are doing. Tom Ritter thr1@ra.msstate.edu
reggie@paradyne.com (George W. Leach) (03/15/91)
In article <1150@ra.MsState.Edu> thr1@ra.MsState.Edu (Thomas Ritter) writes: > I've been hearing some discussion in our department about changing >our primary language from Pascal to something else. I'm assuming you teach in a CS department. >I don't want to start the Ada vs C vs "other" argument.... Nobody wants another one of those..... > I would like to hear what people consider important in making a >decision. ( Usefulness in the real world, teaching ease, programming >environment... etc.) Those are excellent questions. The answers will depend upon whom you talk to. Pascal has traditionally been the language of choice in CS programs due to its use as a teaching language. However, since I left school I have never used it in the "real world". Certainly, one could argue that the principles can be taught with Pascal and then you can map these into whatever language you choose to use in your work. But many employers want to see specific language and OS skills on a resume. They are not interested in training someone in these skills. Pascal reminds me of a bike with training wheels. But you can't take the training wheels off and use the bike once you have learned. If we could put training wheels on a language such as C, and then take them off when we have learned how to keep our balance, then we would have something. >I would also like to find out what some other schools are doing. I teach part-time, in the evenings at a junior college. I am teaching for the Engineering Technology Department, so my focus is different. They still require FORTRAN, but we also offer a C course for which the FORTRAN course is the prerequisite. I have heard some rumblings about the FORTRAN requirement going away, but I have not heard what it would be replaced with. Some say a general course in using CAD packages, and other tools. But I just can't see all of an engineer's computing needs being served by this approach. Not everything fits into such nice, neat solutions. I advise my students to learn both FORTRAN and C, unless they know for sure what area of engineering they want to go into. George -- George W. Leach AT&T Paradyne reggie@paradyne.com Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA
eibo@rosun1.informatik.uni-hamburg.de (Eibo Thieme) (03/15/91)
If I were to decide which language to use, especially to start with
I would consider the following objectives:
* Immediate Reward
"Write down a few lines of code and watch things happen."
Don't let them be bored by extensive syntax-checking or
mystical compiler usage.
* Being Modern
"Look, I can do fancy windows too." Beginners want their
programs to be as pleasing to the eye as those shiny
products they see on the market.
* Essential Programming
"The algorithm was in the books but doing the interface
took me a week." Most of real world applications seem to
be 90% user-interface, students instinctively try to
adapt to this situation.
* Software Engineering
"When I saw the other group understood our code I knew it
was worth the effort." Systematic construction of software
is a far higher good than freaky code dabbling. Don't use
a language which invites "creativity".
* Reliable Software
"I was dumbfounded when the compiler found my conceptual
glitch." Beginners should learn to appreciate extensive
syntax-checking, type-checking, etc.
I cannot think of any small set of languages taking into account
all these constraints and there will be even more to add to the list.
Sorry, but I would like an answer too.
eibo
--
eibo Thieme * FB Informatik
eibo@fbihh.informatik.uni-hamburg.de * Universitaet Hamburg
..!uunet!mcsun!unido!fbihh!eibo * Schlueterstr. 70
PHONE: +40 4123-5660 * D-2000 Hamburg 13 (FRG)mcn@mimas.UUCP (Michael C. Neuman) (03/17/91)
reggie@paradyne.com (George W. Leach) writes: > I teach part-time, in the evenings at a junior college. I am > teaching for the Engineering Technology Department, so my focus is > different. They still require FORTRAN, but we also offer a C course > for which the FORTRAN course is the prerequisite. I have heard some > rumblings about the FORTRAN requirement going away, but I have not > heard what it would be replaced with. Some say a general course in > using CAD packages, and other tools. But I just can't see all of an > engineer's computing needs being served by this approach. Not everything > fits into such nice, neat solutions. I advise my students to learn both > FORTRAN and C, unless they know for sure what area of engineering they > want to go into. > With my experience in the "real world", FORTRAN is nearly a prerequisite to doing anything with engineering. At Los Alamos National Labs, the majority of programmers use FORTRAN for several reasons: 1) It's nearly as easy as BASIC to learn which means that the scientist can get down to the problem rather than messing with the programming technicalities. 2) The compilers for the Crays and Connection Machines automagically vectorize and parallelize fortran code, whereas C has to be "forced" by the programmer to multitask. However, on both systems, FORTRAN is less effecient. A piece of well written C code will outperform the FORTRAN stuff easily. Unfortunately, the scientists who are using the machines to do their work don't have time to learn the intricasies of a programming language, and thus will stick to FORTRAN. Thus, my advice: learn them both. If you want to be a programmer, learn C, if you want to be an engineer, learn FORTRAN. If you're not sure, learn both of them. C is hard to learn, FORTRAN just requires knowledge of BASIC. <<<===========================--------==============================>>> <<< Mike Neuman || Senior Systems Programmer >>> <<< mimas!mcn@bbx.basis.com || Albuquerque Academy >>> <<< mcn@beta.lanl.gov || Computer Science Division >>> <<<===========================--------==============================>>> "It's hard to work in a group when you're omnipotent" - Q ST:TNG "Counsel will refrain from making opposing advocate disappear" - Data
faustus@ygdrasil.Berkeley.EDU (Wayne A. Christopher) (03/17/91)
Despite its reputation as a baby language, Logo has a pretty nice conceptual framework -- it's a dialect of Lisp, even though the syntax doesn't make it look that way. From an early training in Logo, it should be possible to progress to Scheme and then to Common Lisp. These languages are strong in the "immediate reward" and "essential programming" categories you mention, and can be augmented with environments that make snazzy programs easy to write. As for "software engineering" and "reliable software", the outcome is debatable. The question is, if all people are exposed to early are Lisp-like languages, will they be able to adapt easily to using Algol-like languages? That is, which of these sequences is better: Logo -> Scheme -> Common Lisp -> C++ -> Ada .... Basic -> Pascal -> C++ -> Common Lisp ... I am assuming that in order to be an effective computer professional, one must be familiar with both Lisp-like and Algol-like languages. Wayne
cheung@mathcs.emory.edu (Shun Yan Cheung) (03/17/91)
In article <1150@ra.MsState.Edu> thr1@ra.MsState.Edu (Thomas Ritter) writes: >Hello, > > I've been hearing some discussion in our department about changing >our primary language from Pascal to something else. > >I don't want to start the Ada vs C vs "other" argument.... > > I would like to hear what people consider important in making a >decision. ( Usefulness in the real world, teaching ease, programming >environment... etc.) I feel the language is the least important in teaching programming, rather, concentrate on the programming methodology. The programming language is just a tool. A good carpenter will work magic with any tool. Didactically, I see no reason what so ever to favor either Pascal or C when the objective is to teach student programming. The concept of an assignment, procedure etc is the same. If the student masters the concepts, he will have not problems learning another language in a few days. Personally however, as a teaching tool, I prefer Pascal over C because the typing is stronger (I am comparing the old style C, I have no idea if ANSI C is strongly typed.) Certainly I will reject Fortran (no recursion), even though it is widely used by engineers. On the other hand, if you are teaching programming to engineers (non majors), you may want to consider Fortran for the sake of familiarity. If you want to based your choice on practicality measured by the number of programs written in a certain language, I think Cobol is still the number one language. Surely you don't want to use Cobol.... > >I would also like to find out what some other schools are doing. At Emory, the non majors get Pascal and the majors gets C because the higher level courses all use C. -- Shun Yan Cheung | cheung@mathcs.emory.edu Internet Emory University | cheung@emory.bitnet BITNET Dept of Math and CS | Voice: (404) 727-3823 Atlanta, GA 30322 | Engineering: make it work. Research: make it work BETTER
jff@denali.ee.uidaho.edu (Jim Frenzel) (03/19/91)
In article <3s3wy4w163w@mimas.UUCP> mcn@mimas.UUCP (Michael C. Neuman) writes: > With my experience in the "real world", FORTRAN is nearly a >prerequisite to doing anything with engineering. At Los Alamos National >Labs, the majority of programmers use FORTRAN for several reasons: ... While I've never worked at Los Alamos, I was an engineer with IBM for 7 years and NEVER saw anyone use FORTRAN. Based on that and interaction with other engineers, I seriously question that FORTRAN is a "prerequisite to doing anything with engineering." A lot of number crunching was done during the 70's with FORTRAN; that and the existence of vectorizing/parallelizing tools are the only reasons it continues to exist. > However, on both systems, FORTRAN is less effecient. A piece of well >written C code will outperform the FORTRAN stuff easily. This is an excellent reason for abandoning FORTRAN. > Thus, my advice: learn them both. If you want to be a programmer, learn >C, if you want to be an engineer, learn FORTRAN. If you're not sure, >learn both of them. C is hard to learn, FORTRAN just requires knowledge >of BASIC. IMHO, C is no harder than any other language, PROVIDED you start simply and add material as the student improves. I wouldn't jump into pointers and structures the first day of class. Again, IMHO, the only reason to learn FORTRAN is if you intend to be an engineer historian. :-) It is a dead language that anyone can pick up if ABSOLUTELY necessary. Why waste class time teaching yesterday's tools? -- Jim Frenzel Electrical Engineering University of Idaho Moscow, ID 83843 208-885-7888 jfrenzel@groucho.mrc.uidaho.edu
dww@math.fu-berlin.de (Debora Weber-Wulff) (03/19/91)
Here in Berlin at the Free University we just have a program for minors and for teacher certification in "Informatics". The first semester is taught Miranda (a functional language) so that all the students, those with programming experience and those without (i.e. BASIC freaks... <--- flame!) are all at the same level. This works rather well, although it is difficult to motivate further because Miranda is not used in industry or in the schools. The big project last semester was to write a text formatter in Miranda, the students were quite enthusiastic about it. The Miranda system works quite well, it is more robust than the Hope system that was tried a few years ago (before my time, I don't know details). In later semesters MODULA-II is taught as the imperative language. Some students complain that they would rather learn Pascal, but on the whole they are enthusiastic, and even try and introduce MODULA-II into the schools. I am somewhat mystified by the statement to the effect that Pascal is not used in industry: I spent 4 years writing library information systems in a Pascal dialect with modules and most of the ISO stuff, and got a good feeling for the industrial potential: with the right collection of interfacers (window stuff, a good database interface, an abstract data type procedure/function generator, etc.) we got a lot done. And as much as we cussed at the strong type checking - as soon as we tried to get around it mit tricky modules, etc. we fell flat on our collective noses! -- Debbie -- Debora Weber-Wulff snail: FU Berlin, ZI Fachdidaktiken, Habelschwerdter Allee 45, W-1000 Berlin 33 email: weberwu@inf.fu-berlin.de, dww@math.fu-berlin.de
kemnitz@hermes.Berkeley.EDU (Greg Kemnitz) (03/19/91)
Some statements about languages and industry. Note that this is based on my
experience in the US and is not "official"...
In my experience, the following seems to be true:
1. Algol-style languages are still by far the most common in software
development, at least in industry.
2. It is quite rare for knowledge of a Lisp-like language to be necessary
outside of relatively restricted environments (ie expert-system vendors,
some military and DOD work, etc). These languages are far more important
in academia than they are in industry.
3. While ADA is The Required DOD Language, it has not caught on in quite the
way the DOD envisioned for various factors, among them is the fact that
the vast majority of software people are not working on projects that are
source-code deliverable to the Department of Defense, and it took quite a
while before ADA compilers of any quality appeared on real hardware. The
DOD itself may have killed ADA with a loophole that several large trucks
have been driven through - the statement that ADA was unnecessary if it was
too expensive and not "mission critical" (ie F-16 flight control software).
ADA is used a a few MIS shops and at some DOD contractors, but outside
this relatively restricted domain, it is not very common.
The following seem to be the most commonly used languages in industry:
1. C.
The old favorite, with all its foibles and annoyances, is still the
undisputed leader in UNIX and PC software development. I don't want to
quote percentages, but C is dominant enough in these environments that
_not_ using C for a piece of software indicates an unusual group. Pay
for good C hackers is generally the best in the industry.
2. COBOL.
This ancient language still dominates MIS shops. However, COBOL programmers
are almost always the most poorly paid in industry. It is unclear to me
whether C or COBOL is number one in actual numbers of people coding in
each. COBOL is likely to stay around as long as MIS shops exist, primarily
due to the conservative nature of most MIS executives, and their colossal
investments in existing hardware and software.
3. FORTRAN.
This is another ancient language that dominates by force of inertia. Used
largely by scientific programming shops or people who crunch numbers.
Billions of lines of code guarantee that this language will continue to be
important, in spite of the nightmares that seeing a GOTO statement cause
modern software engineers.
4. C++.
The first (and as far as I can see only) of the "object oriented" languages
to become truly important in industry. Many C shops are converting to
C++ so they can take advantage of existing code as well as the wins that
object oriented programming provide. C programmers should learn C++, and
its object oriented programming paradigm, if they learn nothing else.
A person skilled in C++ will not have many problems finding a job.
The Small Fry:
Lisp, ADA, Pascal (once much more important - derailed largely by C),
Modula I, II, etc, PROLOG, Forth (important in manufacturing and robotics),
numerous smaller and in-house languages.
While it is important for students to be able to learn any programming language
quickly and easily, and to be exposed to several different language paradigms,
they need to eat as well. A CS major whose undergraduate curriculum has
emphasized Lisp and Ada, and has no experience in C, will find that employment
prospects are quite limited. While this should not stop universities from
teaching new programming paradigms, they must pause and think whether their
graduates will be able to eat, and make sure their students are armed with both
the latest in paradigms and software engineering techniques, and have a good
understanding of languages and paradigms they are likely to encounter in
industry.
The argument that any good student can pick up any programming language quickly
makes sense in the context of teaching, but it often doesn't wash with hiring
managers and the personnel departments that screen resumes.
-----------------------------------------------------------------------
Greg Kemnitz | "I ran out of the room - I
Postgres Chief Programmer | didn't want to be killed by a pile
278 Cory Hall, UCB | of VMS manuals" :-)
(415) 642-7520 |
kemnitz@postgres.berkeley.edu | --A friend at DEC Palo Alto in the Quakebillh@hplsla.HP.COM (Bill Harris) (03/19/91)
I just found an article by Curtis, Sheppard, Kruesi-Bailey, Bailey, and
Boehm-Davis entitled "Experimental Evaluation of Software Documentation
Formats", published in "The Journal of Systems and Software", vol. 9, pp.
167-207, 1989. Briefly, they studied the effectiveness of certain types of
software problem-solving behavior as a function of documentation formats
and styles.
On page 198-199, they describe how they removed the effect of programmer
variability from the results of their study. They found that the number of
years of professional programming experience did not correlate to
performance on any of the 4 experiments they ran. On the other hand, the
number of languages the programmer had used did correlate positively with
success on 2 of the 4, and it was on the borderline of significance on a
third.
They claim this is consistent with reports in a prior study ("Modern Coding
Practices and Programmer Performance" by Sheppard, Curtis, Milliman, and
Love in "Computer", vol. 12, no. 12, pp. 41-49, 1979), which showed that
the number of years of programming performance didn't correlate with
performance, but breadth of programming experience (number of programming
languages known, etc.) did. (I have not yet read this article.)
Incidentally, the subjects (programmers) in the 1989 report were all
professional Fortran programmers with an average of over 5 years
professional experience.
My conclusion is that you should pick the concepts which you wish to teach
and then select a language which is effective at teaching those concepts
and meets other constraints which you may have, as one of the other posters
mentioned. It would only seem beneficial for students to be exposed to a
variety of languages over their careers at the university. Having hired
software engineers in the past, I can say that a person's understandings of
the fundamentals was more important than whether or not they already knew
the language we were using at the time.
Bill Harris
billh%hplsla@hplabs.hp.com
Hewlett-Packard Co.
Lake Stevens Instrument Division ms/230
8600 Soper Hill Road
Everett, WA 98205-1298 pjh@mccc.edu (Pete Holsberg) (03/19/91)
In article <3s3wy4w163w@mimas.UUCP> mcn@mimas.UUCP (Michael C. Neuman) writes: =reggie@paradyne.com (George W. Leach) writes: = => I teach part-time, in the evenings at a junior college. I am => teaching for the Engineering Technology Department, so my focus is => different. Other than teaching full-time, our situations are identical. => They still require FORTRAN, but we also offer a C course => for which the FORTRAN course is the prerequisite. We require FORTRAN of our Engineering Science students but not of our Engineering Technology students. We find it more important that they learn to use the computer as a tool, rather than as a programming instrument. After all, there are a lot of good analysis programs already in existence. I would rather see Engineerining Techs learn how to use the analysis programs (e.g., PSPICE for EETs, DCA for CETs, etc.) and CAD than spend a lot of time learning programming. HOWEVER, ABET -- the Accrediting Board for Engineering and Technology -- has deemed programming a necessary skill, and that's why I'm the author of "C For Electronics and Computer Engineering Technology"!! ;-) Oh, yes -- we teach the EETs Z80 assembly language programming, too. Goes very well with the microcontroller course. => I advise my students to learn both => FORTRAN and C, unless they know for sure what area of engineering they => want to go into. => Do all your students transfer to four year engineering schools or do they go to engineering tech schools and/or out to industry? = Thus, my advice: learn them both. If you want to be a programmer, learn =C, if you want to be an engineer, learn FORTRAN. If you're not sure, =learn both of them. C is hard to learn, FORTRAN just requires knowledge =of BASIC. But if you're going to be an engineering technologist, maybe you don't need either??? Pete -- Prof. Peter J. Holsberg Mercer County Community College Voice: 609-586-4800 Engineering Technology, Computers and Math UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91
hcc@candy.cs.olemiss.edu (Conrad Cunningham) (03/19/91)
In article <12103@pasteur.Berkeley.EDU> kemnitz@hermes.Berkeley.EDU (Greg Kemnitz) writes:> > have been driven through - the statement that ADA was unnecessary if it was > too expensive and not "mission critical" (ie F-16 flight control software). I don't know which version of the F-16 is being referenced here. The A/B versions of the F-16 were done in the mid-to-late 1970's when Ada was still some military bureaucrat's dream; the C/D versions were done in the early 1980's before reliable production quality Ada compilers were available for the required target machines and before Ada was required. ------------------------------------------------------------------------------- H. Conrad Cunningham | Dept. of Computer & Info. Sci., Univ. of Mississippi Tel: (601) 232-5358 | 302 Weir Hall, University, MS 38677 U.S.A. Fax: (601) 232-7010 | Email: cunningham@cs.olemiss.edu
kemnitz@gaia.berkeley.edu (Greg Kemnitz) (03/22/91)
My comments about industry are largely restricted to the US - other countries certainly can/do have different programming language usage patterns in their software industries. In particular, I would doubt that many other countries are hindered by the huge "installed base" of antiquarian languages as the US; a thing about being relative latecomers to the computer scene will be that many companies based in other countries will avoid the FORTRAN/COBOL black hole that many American companies have fallen into. Also, I intended to describe what I feel is actually happening in industry, rather than trying to say what can happen or should be happening - this is what academics are for :-) The thing that tends to determine which language will be used in industry would surprise many people - it has very little to do with the intrinsic quality of the language itself in most cases. It is whether people are available who know and are familiar with the language. In many companies the question on new projects is whether to use C or C++. No other languages are considered, primarily because training expenses are large and most good programmers in the US know C. Other factors include the cost and quality of compilers and debugging tools on the target platform for these new languages, etc. Also, software has a way of taking on a life of its own (at a couple of points in my career I have encountered FORTRAN II subroutines - that were in use - that are older than I am), so justifying the use of an unusual or new programming language for a product that is expected to have a long lifetime is difficult. Another factor is the ratio of completely new software ventures to improvements on existing software is rather low. One rarely has the chance to start completely from scratch - in many cases, rewriting is simply not feasable, even if the base is an ancient FORTRAN program using arithmatic gotos. ----------------------------------------------------------------------- Greg Kemnitz | "I ran out of the room - I Postgres Chief Programmer | didn't want to be killed by a pile 278 Cory Hall, UCB | of VMS manuals" :-) (415) 642-7520 | kemnitz@postgres.berkeley.edu | --A friend at DEC Palo Alto in the Quake
NORVIG@Teak.Berkeley.EDU (Peter Norvig) (03/23/91)
There seems to be a consensus that the first thing to do is decide what concepts you want to teach, and after that, the choice of a language is not as important. I agree. But after the concepts are chosen, it is also crucial to find a text book that presents those concepts well. For those who decide that they would like to teach the principles of Computer Science rather than the details of some language's syntax, Abelson and Sussman's "Structure and Interpretation of Computer Programs" fits the bill. This text happens to use Scheme, but in my opinion it is so much better than competing texts that I would use it even if it's language were Fortran, Cobol, or anything else. (Of course, I think that its not just a coincidence that it uses Scheme; many of the important concepts could not be presented so well in other languages.) - Peter Norvig
louk@tslwat.UUCP (Lou Kates) (03/23/91)
In article <12219@pasteur.Berkeley.EDU> kemnitz@gaia.berkeley.edu (Greg Kemnitz) writes: >The thing that tends to determine which language will be used in industry would >surprise many people - it has very little to do with the intrinsic quality of >the language itself in most cases. It is whether people are available who know >and are familiar with the language. Actually I don't think that people even go into it that much. Its mostly a matter of market share -- if most other people are using it then you use it too. People make these decisions on the basis of minimizing their risk ("nobody ever got fired for recommending IBM") rather than maximizing their gain and the more other people that are using it the more proven it is. Lou Kates, Teleride Sage Ltd., louk%tslwat@watmath.waterloo.edu
plb@plb.icsti.su (Peter L.Brusilovsky) (03/23/91)
I was silent looking on this interesting discussion.
Let me now to introduce one more oppinion from the USSR.
I apologise in advance for my poor English...
1. The situation at the Dept of Applied Mathematics and Cybernetics,
Moscow State University. (Applied Mathematics + CompSci)
1983 (Non-CS students): Algol -> Fortran
1983 (2/3 of CS students): Algol -> Fortran -> Assemblers
1983 (1/3 of CS students): Algol -> Fortran -> Lisp+PLANNER
1990 (Non-CS students): Pascal -> Basic -> (some of st-s) Fortran
1990 (MathLog students): Pascal -> Basic -> Prolog
1990 (2/3-CS students): Pascal -> C -> Assemblers
1990 (1/3 of CS students): Pascal -> Assemblers -> Refal -> Lisp+PLANNER
Note 1: '1/3 of CS students' are the those from the Chair for Alg. Languages
Note 2: I see, the approach in 1990 is quite the same as in 1983,
but "Pascal is Algol of nowdays and C is Fortran of nowdays".
It is my own oppinion, based on a teaching and programming experience
with all these four languages. Are you agree?
2. Why not to start with mini-languages (pre-languages)?
To support the first steps of learning programming we need:
a) simple language with no unimportant details, to see the
main concepts of programming better
b) easy-to-start language, to write quite interesting programs
just at the first or the second lessons.
c) language with visible interpretation, to see immediately
the results of all the commands' performing - this is a strong
tool to understand the semantics of language constructions
There is no any "professional" laguage with a-b-c features
(LOGO is an exlusion, it is educational language).
Let's build such a simple language to support the first steps
of learning. We could learn such a mini-language for 4-5 lessons
and then start to learn the professional ones.
As an example of mini-languages (m-l) I could suggest LOGO-turtle
(embedded one), Karel, Josef (independent m-ls).
The mini-languages approach is quite developed in the USSR
and there are a lot of Russian mini-languages. We could build
a special m-l for a special cathegory of students.
3. The sequences of languages to learn, some viewpoint from USSR
for 'classic' CS students: m-l -> Pascal or Modula-2 -> C[++] -> [LISP?] ...
for 'symbolic' CS students: m-l (Logo) -> LISP + Prolog -> [Pascal] ...
for 'Math-related' students: m-l -> Pascal or Modula-2 -> Basic or Fortran ...
for "advanced Computer literacy": m-l -> Pascal or Basic [or Fortran??]
for "only Computer literacy": m-l (Karel,...)
Note: I am not acquanted with Scheme (it's unknown in the USSR yet).
Peter
------------------------------------------------------------------------------
Dr. Peter Brusilovsky || International Centre for Scientific
Telex: 411925 MCNTI || and Technical Information (ICSTI),
FAX: +7 095 943 0089 || Kuusinen str. 21b, Moscow 125252, USSR
E-mail: plb@plb.icsti.su or plb%plb.icsti.su@relay.eu.net
------------------------------------------------------------------------------mikef@cs.ed.ac.uk (Mike Fourman) (03/25/91)
In article <eibo.669049308@rosun1> eibo@rosun1.informatik.uni-hamburg.de (Eibo Thieme) writes: >If I were to decide which language to use, especially to start with I suggest you use Standard ML >I would consider the following objectives: Let's consider them > > * Immediate Reward > "Write down a few lines of code and watch things happen." > Don't let them be bored by extensive syntax-checking or > mystical compiler usage. ML can be used as an interactive language, with a read-eval-print interface, a la lisp (but (far) fewer () {:-)}). > > * Being Modern > "Look, I can do fancy windows too." Beginners want their > programs to be as pleasing to the eye as those shiny > products they see on the market. Too true! We've spent some effort producing simple graphics for ML for use in introductory courses, and it pays off. (Some ML implementations also have sophisticated graphics for fully-fledged user-interfaces.) > > * Essential Programming > "The algorithm was in the books but doing the interface > took me a week." Most of real world applications seem to > be 90% user-interface, students instinctively try to > adapt to this situation. The interactive nature of ML and the built-in parsing for user-defined (and built-in) datatypes make it possible to concentrate on the algorithms. > > * Software Engineering > "When I saw the other group understood our code I knew it > was worth the effort." Systematic construction of software > is a far higher good than freaky code dabbling. Don't use > a language which invites "creativity". ML has: static typing, polymorphism, controlled assignment, higher-order functions, abstract types, and a module system for 'programming in the large'. > > * Reliable Software > "I was dumbfounded when the compiler found my conceptual > glitch." Beginners should learn to appreciate extensive > syntax-checking, type-checking, etc. ML's static analysis performs type inference, type checking, and analysis of cases for redundant patterns and missing cases. The first perception of ML is invariably that once it type checks it's correct. (Second perceptions are more realistic, but most of the bugs you would have put in in C, for example, are caught by ML's static analysis.) In addition, ML has a formal semantics, and the Extended ML specification and refinement language supports top-down program development > >I cannot think of any small set of languages taking into account >all these constraints and there will be even more to add to the list. Hope the list is small enough :-) Prof. Michael P. Fourman email mikef@lfcs.ed.ac.uk Dept. of Computer Science 'PHONE (+44) (0)31-650 5198 (sec) JCMB, King's Buildings, Mayfield Road, (+44) (0)31-650 5197 Edinburgh EH9 3JZ, Scotland, UK FAX (+44) (0)31 667 7209 ------------------------------------------------------------------------------- -- Prof. Michael P. Fourman email mikef@lfcs.ed.ac.uk Dept. of Computer Science 'PHONE (+44) (0)31-650 5198 (sec) JCMB, King's Buildings, Mayfield Road, (+44) (0)31-650 5197 Edinburgh EH9 3JZ, Scotland, UK FAX (+44) (0)31 667 7209
stern@decserver.mc.ab.com (Ken Stern (ext 4157)) (03/26/91)
In article <348@tslwat.UUCP> you write: |> In article <12219@pasteur.Berkeley.EDU> kemnitz@gaia.berkeley.edu (Greg Kemnitz) writes: |> >The thing that tends to determine which language will be used in industry would |> >surprise many people - it has very little to do with the intrinsic quality of |> >the language itself in most cases. It is whether people are available who know |> >and are familiar with the language. |> |> Actually I don't think that people even go into it that much. Its |> mostly a matter of market share -- if most other people are using |> it then you use it too. |> |> People make these decisions on the basis of minimizing their risk |> ("nobody ever got fired for recommending IBM") rather than |> maximizing their gain and the more other people that are using it |> the more proven it is. |> |> Lou Kates, Teleride Sage Ltd., louk%tslwat@watmath.waterloo.edu In fact, it is often even simpler than that. Very often it simply boils down to INERTIA. If a company (or individual) has a significant amount of code written in a language there will be a great deal of pressure to protect that investment and continue to use the language (otherwise, why would there still be so many people working in COBOL!?). In fact, even moving from one compiler to another for the same language can represent a significant cost, and one that will be borne only for good reason. Remember, most companies produce software to make money, NOT to advance the state of the art. And educational institutions, if they are doing their job, should be preparing their students for the real world. So ... how many companies are looking to hire people with Lisp experience versus the number looking for people with a background in C? The same or similar agruments help explain why C++ is so much more popular than SmallTalk or Eiffel.
hcc@candy.cs.olemiss.edu (Conrad Cunningham) (03/26/91)
In article <242@zeus.mc.ab.com> stern@decserver.mc.ab.com (Ken Stern (ext 4157)) writes: > ... And educational institutions, if they are doing their job, should > be preparing their students for the real world. ... Although I agree that students graduating with a degree in computer science should have a reasonable level of immediately applicable skills and knowledge, developing such skills and knowledge is not our primary "job". Our job is provide an environment which encourages students to become "educated", not necessarily to train students with exactly those skills that some industry believes it needs. We ought to teach the better ways to do things, not just the conventional ways. Our students need to be dissatisfied with the status quo; otherwise how can organizational inertia be overcome. The "real world" is one of rapid technological and social change. Students need to prepare themselves for that kind of world. ------------------------------------------------------------------------------- H. Conrad Cunningham | Dept. of Computer & Info. Sci., Univ. of Mississippi Tel: (601) 232-5358 | 302 Weir Hall, University, MS 38677 U.S.A. Fax: (601) 232-7010 | Email: cunningham@cs.olemiss.edu -------------------------------------------------------------------------------
bzs@world.std.com (Barry Shein) (03/29/91)
I don't teach now, but I taught programming courses in the Computer
Science Dept (at Boston University) for a decade (until 1988). I've
taught courses using 370/assembler, C, PL/1, and others ("Survey of
Programming Languages", or "If it's Tuesday, this must be Cobol!".) I
am very comfortable with most major programming languages, including
Fortran, Lisp, C, etc. I've written extensive code professionally in
many of those languages (the point being: my opinions don't stem from
rumors about languages I've never actually used, and in many cases
have taught.)
That said, here are my opinions on the subject:
The most important factors of a successful programming/teaching
environment are a good book, an environment which follows the book,
and of course a teacher who knows what they are doing (I'd rate
knowledge and vision of computer science as a subject over sheer
technical knowledge, tho some of each has its value.)
A computer is a confusing, complicated environment to a new-comer. Not
being able to type in a simple example from the book is exasperating
and convinces a student that this is all impossible to ever master.
It seems simple and obvious, but inevitably teachers adopt (e.g.) a
Unix-oriented C programming book and then proceed to teach on the
available campus mainframe which sort of has a C compiler.
Of course, none of the file I/O works as advertised, the math
libraries are strange and incomplete, link-editing and compiling
involve mysterious voo-doo, none of the examples in the book will
really work.
The teacher gets overloaded trying to make up for these deficiencies
with handouts, teaching assistants, user services people, and quickly
spit-out notes in class ("on page 243 you'll have to use "rb" rather
than "r" in the fopen() to get the example to work...on page 177 make
the large auto array static or external...", you're laughing!, yeah,
I've been there too.)
Students get grumpy about always being one obscure detail short of
getting an example to work, the whole thing invites disaster.
(the same could be said for Fortran or Pascal or whatever, just an
example.)
It's really important to instill a sense of predictability and
usefulness of written materials in students right away.
They have to learn to find out information for themselves. If you
badly mismatch the text and the environment you'll lose them forever,
they'll never believe there's any relationship between what's written
and what they actually need.
Now, some opinions on languages and environments:
1. C - C is very easy to learn and teach. The key is not to introduce
the advanced features right away. I've never had problems even later
with pointers etc, but I think that's because I understand such topics
deeply (I am a programmer at heart). I think most teachers who botch
such topics tend to not understand them themselves and relay their own
anxieties to their students. A little order and method is all that's
needed. But there's absolutely no need to start with such topics. When
you get to dynamic data structures they come up naturally enough.
Just about any cliche in a so-called easier language can be taught in
C, it's just a matter of style. Looping thru an array, character
strings etc. In fact, I think the closeness of some of these topics to
the machine is a good thing and highly abstracted languages leave
students without a clue as to what is really going on inside a
computer (of course, that assumes the teacher has a clue...)
C is highly standardized, in a good environment a student can use
additional texts if desired and be pretty confident that everything is
relevant.
Finally, there's an enormous amount of free source code available.
Some should be made available and students should be encouraged to
look at it, see how "real" people solve "real" problems. I can't
overemphasize playing with and looking at others' code. Just its
existence is immensely encouraging to a student, makes them realize
the goal. They'll look at it because they'll think they can crib from
it. That's fine, they'll have to understand it before they can crib.
2. Pascal - The problem with Pascal is related to my first
recommendation, it's hard to find any agreement between any two books
on just what Pascal is!
Every implementation is chock-full of extensions and exceptions to
make the basic language useable. This also makes it difficult to find
a book which matches the locally available Pascal *AND* covers CS
topics. Often one has to resort to at least two books, one which
covers CS topics in Pascal and another which covers using the
particular dialect available. The student is left with the chore of
translating between the two books, very silly.
Most pascals also have the problem of complicating or completely
avoiding external linkage, at best it is pushed off to an advanced
topic which is a terrible thing. Breaking a programming chore into
modules (files), re-using them etc is an important lesson. It's sad
to see this skipped simply because the compiler makes it difficult!
I consider Pascal a dying language in general, mostly due to its
astounding lack of portability (due to all the ideosyncratic
extensions.)
3. Fortran - You'll have some problems finding a good CS book based on
Fortran. This might be the result of the prejudices of the CS
community, but it is a fact nonetheless.
Fortran has few of the extension and knowledge-portability problems of
Pascal (VMS Fortran excepted, which is barely Fortran tho most
extensions can be successfully ignored, in its favor it is mostly a
super-set and will compile standardized examples.) Environment
excepted, if you know Fortran you know Fortran, most everything you
know will work anywhere.
Fortran's biggest flaw is its lack of data structures, and for the
purpose of teaching Computer Science (I assume there's a bigger lesson
being taught than the mechanics of programming) this flaw is just about
fatal.
Forget Fortran, offer a one-credit off-hours course to students with
some programming background to pick this up later if they like.
4. ADA - Few compilers, mostly too expensive for academics to ever
own, few books oriented towards CS, very demanding on the computing
resources (usually precipitating battles between the people who teach
and those who run the computers as the intro class makes the system
unusable), oh well.
DOD et al blew it with ADA by not making ADA environments available
(thru grants etc) to educators. Right now it's mostly non-existent in
academia, and the few faculty I know who insisted on teaching with ADA
had to be heroes with raising money to support their courses.
So its suitability as a teaching language is mostly moot, you don't
own it, and you can't afford it.
5. Modula - I suspect there are still no CS texts based on Modula, so
there's a problem. At least one free compiler (for Unix) exists, tho
you'll have to support it yourself. The language does look promising
as a teaching language, tho it doesn't seem to really exist. I doubt
you'll find much environment to deal with Modula, not sure how much
you really need (a debugger?)
6. Lisp/Scheme - Probably the most under-rated teaching languages, but
you'll never fix that. Abelson & Sussman is an excellent text. It's
not the choice of the trade-school/resume crowd since these languages
are just not used much "out there". Wonderful environments, usually
free, quite standardized etc. But you won't use it, you don't
understand the language yourself, so who are we kidding?
7. ML/Logo/others - Huh? If you drive an electric car and lean towards
macrobiotics and seances these might have some appeal.
8. C++ - Worth considering, I don't consider it "object-oriented", but
it is an interesting language, more like Algol/68 done right. G++ can
be had for free, a real plus (pardon me.) Probably hard to find a text
tho I wouldn't be shocked to hear one exists at this point. I might be
more inclined to start students out with C and then, perhaps in a
second term, move to C++. That combination would be a real service to
students, there's a lot of interest in both "out there", lots of
papers on C++ also which might be worth introducing as material as you
go on. Many of the interesting extensions of C++ over C are real,
hard-core CS topics worthy of discussion and natural lessons in data
abstraction etc.
----------
A final note: A nice way to teach an intro programming course is to
assign lots of little, tiny projects each incorporating a cliche and
slowly building skills. Programming is learned by drilling, in a way.
Practice. Get them to realize that it's mostly a matter of matching
the problem at hand to a particular cliche they've seen before. Build
on that rather than getting macho and trying to get them to write big
applications (the inevitable text editor) before they've realized that
big programs are made out of lots of little, well-understood pieces.
Teach them early how to link to libraries and exploit the terrain. If
possible, use windowing libraries as a motivator (writing a few
non-standard but simplified library routines is fine, give them the
source!) Encourage them to explore and experiment, make it clear
you'll like little variations on the assignments, reward them for it.
(I realize in over-loaded environments this is hard, well, try some
controlled variations and have them hand them in after doing the basic
assignment for extra-credit or whatever.)
--
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLDkemnitz@gaia.berkeley.edu (Greg Kemnitz) (04/02/91)
In article <1991Mar26.134531.1644@cs.olemiss.edu> hcc@candy.cs.olemiss.edu (Conrad Cunningham) writes: >In article <242@zeus.mc.ab.com> stern@decserver.mc.ab.com (Ken Stern (ext 4157)) writes: >> ... And educational institutions, if they are doing their job, should >> be preparing their students for the real world. ... > >Although I agree that students graduating with a degree in computer >science should have a reasonable level of immediately applicable >skills and knowledge, developing such skills and knowledge is not our >primary "job". Our job is provide an environment which encourages >students to become "educated", not necessarily to train students with >exactly those skills that some industry believes it needs. We ought >to teach the better ways to do things, not just the conventional ways. >Our students need to be dissatisfied with the status quo; otherwise >how can organizational inertia be overcome. It seems to me that there is a very fine and difficult line to be walked by educators in computer science: on the one hand, students who know all the "better" ways to do things, but who can't find a decent job will feel cheated by the irrelevence and practical worthlessness of their education. On the other hand, a tech-school style training curriculum will cause computer science to truely stagnate and would be a threat to whatever lead the US holds, if any, in the field. CS is both a trade and a field of theoretical study, and it seems to me that a good CS education should have elements of both. It seems to me that after working for several years in both academia and in industry, the best prepared software people did their undergrad work in CS programs in which they did three things: program, program, and program some more. Book-learning is useful only in conjunction with experience on the computer, except possibly in more mathematically inclined theory courses. But even so, the curriculum should be structured in such a way that theory and practical courses can complement each other; for example, students should be encouraged to take the compiler course during the same term as they take their theory course in abstract machines, languages and grammars. A pushdown automaton or context-sensitive grammar makes lots more sense when you are trying to write a compiler than it does when you are just reading about it because it will be on the exam on Friday. Probably my biggest peeve is that many practical courses become "theoretical" due to lack of equipment. Courses in databases, compilers, graphics, operating systems, etc should not be bookish "survey" courses but courses in which people actually write or work intensively with these things and see both the practical and theoretical problems that must be overcome in implementing and dealing with these big, complex programs. Lessons, especially in software engineering and good coding techniques, go to heart the first time a student has to rewrite 4000 lines of code in one night because they hardwired all their constants, or after they end up debugging all night because they had a local variable with the same name as a global one (or some similar problem that is not caught by decent compilers). Another thing, and a very important consideration, is that intensive programming be done fairly early in the curriculum so that the students can decide whether they really enjoy programming. If they don't, they will not be terribly successful in industry, and will be doomed to unfulfilling second-rate programming jobs. If this happens, the computer science education has certainly failed the student. ----------------------------------------------------------------------- Greg Kemnitz | "I ran out of the room - I Postgres Chief Programmer | didn't want to be killed by a pile 278 Cory Hall, UCB | of VMS manuals" :-) (415) 642-7520 | kemnitz@postgres.berkeley.edu | --A friend at DEC Palo Alto in the Quake
david.lloyd-jones@rose.uucp (DAVID LLOYD-JONES) (04/02/91)
To: olshause@copper.ucs.indiana.edu (Ronald Olshausen) >Orga: Indiana University, Bloomington > >one-dimensional, workaholic employees. In terms of America's >industrial competitiveness, we are surely better off with a multitude >of high-tech drones, rather than well-rounded, educated, and cultured >individuals with interests outside their profession. I once spent three months chatting-on-Mondays with the senior management of Mitsubishi Motors, seven guys, roughly equivalent to the Division Heads of General Motors. Not the Board of Directors but the people who actually ran things. (This chatting thing was for the sake of their English and for the sake of their exposure to the world. They hire a distinguished visitor (I qualified as a recent member of the Professional Staff of the USCongress) pay the person very well, and wring them out pretty thoroughly over three months. then on to the next professor, writer or whoever...) I assure you these guys, high level metal benders, are also your "well-rounded, educated and cultured individuals with interests outside their profession." And not just because of the program that had brought me into their use. Japanese workers at all levels have hobbies, studies and interests outside work. The "drone" of American mythology is an American invention. > >But in the long run, such an education is not an education at all, but >rather an indoctrination into High-Tech Corporate America. Perhaps I'm >just an idealist, but I still believe Education means an introduction to >the finer things in life, like literature, philosophy, and history... >things even the most cerebral of students might get a 'C' in. You may think this is idealism. Empirically, on the results, I'd say it's operational common sense. -dlj. ---
olshause@copper.ucs.indiana.edu (Ronald Olshausen) (04/04/91)
>>In article <242@zeus.mc.ab.com> stern@decserver.mc.ab.com (Ken Stern (ext 4157)) writes: >>> ... And educational institutions, if they are doing their job, should >>> be preparing their students for the real world. ... As part of my last job, I used to do quite a bit of on-campus recruiting for my employer. I would visit leading engineering schools, and interview some very bright students. But I was somewhat astonished that students at some very reputable schools, like MIT and CMU, could get by with such minimal exposure to non-scientific curriculum. Many of the students with whom I talked had taken innumerable CS and EE courses, yet their liberal arts exposure was often limited to 'Intro to Music Appreciation', 'Expository Writing 101', and 'Intro to Sociology'... fluff courses, to say the least. Certainly such an education is not a disservice to Corporate America... most managers dream of having one-dimensional, workaholic employees. In terms of America's industrial competitiveness, we are surely better off with a multitude of high-tech drones, rather than well-rounded, educated, and cultured individuals with interests outside their profession. But in the long run, such an education is not an education at all, but rather an indoctrination into High-Tech Corporate America. Perhaps I'm just an idealist, but I still believe Education means an introduction to the finer things in life, like literature, philosophy, and history... things even the most cerebral of students might get a 'C' in. I feel that the communications and interpersonal skills of most engineers are lacking, and that a greater emphasis on traditional curriculum could alleviate that problem. So, I'm not sure the role of the University is as simple as 'preparing students for the real world'. I think the role of the University is personal, intellectual, and spiritual enrichment. If that is the case, then a pure CS and EE curriculum is a disservice to the student. I'm not discounting the technical education part... I feel that my MSCS program prepared me well to take on the challenges I face in industry. But I also feel enriched by the liberal arts courses I took, like poetry, history, and political science. In fact, perhaps in the long run those courses will be more influential on me than my CS courses. Ronald Olshausen Graduate School of Business Indiana Uiversity
mikef@cs.ed.ac.uk (Mike Fourman) (04/04/91)
In article <BZS.91Mar28121402@world.std.com> bzs@world.std.com (Barry Shein) writes: [Barry's Credentials omitted ...] >A computer is a confusing, complicated environment to a new-comer. Not >being able to type in a simple example from the book is exasperating >and convinces a student that this is all impossible to ever master. So lets agree that one requirement is a simple environment in which simple examples can be run without uneccesary overhead. [Stuff on NON-standards omitted ...] >It's really important to instill a sense of predictability and >usefulness of written materials in students right away. So the language should be well-defined. >Now, some opinions on languages and environments: [<C is easy if you do it right> omitted ...] (But its easy to do it wrong!) >Just about any cliche in a so-called easier language can be taught in >C, it's just a matter of style. Looping thru an array, character >strings etc. In fact, I think the closeness of some of these topics to >the machine is a good thing and highly abstracted languages leave >students without a clue as to what is really going on inside a >computer (of course, that assumes the teacher has a clue...) I agree. I would teach C in place of assembler - but not as the introductory programming language in a course where they're supposed to first learn about structure and discipline. [ more on C Pascal Fortran and Modula omitted ] > >6. Lisp/Scheme - Probably the most under-rated teaching languages, but >you'll never fix that. Abelson & Sussman is an excellent text. It's >not the choice of the trade-school/resume crowd since these languages >are just not used much "out there". Wonderful environments, usually >free, quite standardized etc. But you won't use it, you don't >understand the language yourself, so who are we kidding? I think this is short-sighted (for the reasons given under 7 below). > >7. ML/Logo/others - Huh? If you drive an electric car and lean towards >macrobiotics and seances these might have some appeal. Is this an argument? In my experience, the _good_ C programmers take to ML easily. ML enforces good practice, and they recognise that the ML type system (for example) is helping them. Of course there are some situations, typically, when you need control of what is stored where when, where a high-level language is not appropriate. For these use a high-level assembler like C. Sometimes you even have to be specific about what is stored in which registers when; then you need assembler itself. But these are side-issues; we're talking about teaching concepts and skills, to students who optimistically expect to be using these for another 45 years! Pass the rice :-) [Stuff on C++ omitted] (I agree that students should be exposed to lots of programming styles or paradigms in the course of their education. C and C++ may be the best available vehicles for this. But I don't agree that either should be the first introduction to programming.) Most programming tasks require an ability to consider the whole and to abstract away from most of the detail. Most languages "out there" are geared primarily to the detail. To educate our students properly, we must help them to see beyond this. [Stuff I broadly agree with, about how to teach programming, omitted ] If we teach them right, they'll be able to pick up any reasonable language quickly and apply what they have learnt to good effect, "out there". For example, I'd expect one of our graduates, or one of the good programmers from companies I consult for, to pick up Scheme and become productive in a couple of weeks :-) There are good practices that are used, but not yet understood well enough to be incorporated in efficiently implementable language designs. For the moment, if we are to allow the programmers to use and develop these, we may need to use C in _production_ programming, and for some of our teaching. (However, I have been closely invloved in the development of a system built with over 100K lines of ML code. Everything, including a sophisticated graphical interface, is in ML, and we've found it to be a very productive language. The type system and the module system work to gether to make sure that individual modules make sense and fit together properly. They enforce a discipline that would require a lot of management effort if the code were written in C.) Finally, to repeat myself, some aspects of some things (eg datastructures, types, abstraction) are well-enough understood that, for an introductory programming course, we can choose a language that helps the student to 'get it right'. -- Prof. Michael P. Fourman email mikef@lfcs.ed.ac.uk Dept. of Computer Science 'PHONE (+44) (0)31-650 5198 (sec) JCMB, King's Buildings, Mayfield Road, (+44) (0)31-650 5197 Edinburgh EH9 3JZ, Scotland, UK FAX (+44) (0)31 667 7209
vancleef@iastate.edu (Van Cleef Henry H) (04/08/91)
In article <4bb36214a43427f8f148@rose.uucp> david.lloyd-jones@rose.uucp (DAVID LLOYD-JONES) writes: >To: olshause@copper.ucs.indiana.edu (Ronald Olshausen) >>Orga: Indiana University, Bloomington >> >>one-dimensional, workaholic employees. In terms of America's >>industrial competitiveness, we are surely better off with a multitude >>of high-tech drones, rather than well-rounded, educated, and cultured >>individuals with interests outside their profession. > >I once spent three months chatting-on-Mondays with the senior >management of Mitsubishi Motors, seven guys, roughly equivalent to >the Division Heads of General Motors. Not the Board of Directors >but the people who actually ran things. (This chatting thing was for >the sake of their English and for the sake of their exposure to the >world. They hire a distinguished visitor (I qualified as a recent >member of the Professional Staff of the USCongress) pay the person very >well, and wring them out pretty thoroughly over three months. >then on to the next professor, writer or whoever...) > >I assure you these guys, high level metal benders, are also your >"well-rounded, educated and cultured individuals with interests outside their >profession." And not just because of the program that had brought me >into their use. Japanese workers at all levels have hobbies, studies >and interests outside work. The "drone" of American mythology is an >American invention. > >> >>But in the long run, such an education is not an education at all, but >>rather an indoctrination into High-Tech Corporate America. Perhaps I'm >>just an idealist, but I still believe Education means an introduction to >>the finer things in life, like literature, philosophy, and history... >>things even the most cerebral of students might get a 'C' in. > > >You may think this is idealism. Empirically, on the results, I'd say it's >operational common sense. > > -dlj. >--- I have worked in and around the world of computers since 1958. Suffice it to say that I never took a single course in "Computer Science---there were none to take. My formal education is in History and Philosophy of Science. Some twenty years ago, I went to monthly meetings of all the organizations involved in building the enroute air traffic control display system as the representative of my company. There were ten or twelve of us who met, and we soon discovered that none of us had graduate-level science training---indeed, I think one fellow had a BA in mathematics (not a BS). Evening discussions tended to Shakespeare, Bach (one fellow played a cello, got together with friends for quartet sessions), history, philosophy, etc. These were the people who made the decisions about a system that is still in place and operating. The last twenty years have seen technological developments such that we can put all the computing horsepower most people can use on a desk in a box that draws about 250 watts. Some questions that people are going to have to answer in the next twenty years, as I see it are: 1. How do we make the resources of the machine accessible to people who are genuinely frightened of them. 2. How are we going to convince managements to use these resources in the workplace to improve the work environment? I have very strong feelings about "keystroke counter" and other such monitoring programs being used to create sweatshop environments. 3. How do we protect freedom of individuality in the face of monumental and comprehensive data collection (credit bureau activities are one example, the establishment of a "national identity" data base using social security numbers is another). I submit that proficiency in the C language or any other is not going to help young people entering the field to identify and address such questions. Going back to the Medieval Trivium and Quadrivium isn't the answer either, but it would seem to me that there are some things worth considering there, and my impression is that the existence of an Aristotle is a rumor to the average MSCS. Hank van Cleef vancleef@iastate.edu Iowa State University, Ames. Ia. tmn!vancleef The Union Institute, Cincinnati, Oh. -- Hank van Cleef vancleef@iastate.edu Iowa State University, Ames. Ia. tmn!vancleef The Union Institute, Cincinnati, Oh.