pcg@odin.cs.aber.ac.uk (Piercarlo Grandi) (04/08/90)
In article <3168@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes:
I'd go for ML in both cases since it's clean, nicely typed,
I like ML, but:
functional and pointer-safe,
^^^^^^^^^^^^^^^^^^^^^^^^^^^
It depends on what you want to teach. Notwithstanding what the
functional advocates say, statefulness and graphness are damn important
in *programming*. ML is a wonderful language for demonstrating
*algorithms* without being distracted too much by programming. This is
is the usual fundamental problem of CS: is it about algorithms or
programs? is it mathematics or engineering? and so on ad infinitum.
There is also the horrid issue that maybe you should teach
*programming*, if you want so, whereas many CS departments confuse that
with teaching *languages*.
To me a language is just a notation to demonstrate a program, which is
the algol view of language as a medium of communicating program
descriptions between programmers or between programmers and compilers.
To others a language is a notation in which to express algorithms. To
many CS curricula teaching a language is an end in itself. I'd rather go
with the Sussman approach of using Scheme as notation for a book on
program design, and concentrating on the latter (interestingly, my
preference for a first notation to teach *programming* with is indeed
scheme or lisp, and second place ML et similia).
Me, I think that most CS curricula are skewed towards the research
interests of faculty (isn't it always true?), because they tend to be
biased either towards mathematics or towards systems programming.
and easy to use for illustrating important modern language
principles; but perhaps I'm biased.
Most "programmer" jobs will now be about DMBSes and 4GLs, and CS
departments turn out either complexity theorists/logicians (UK) or
system implementors (USA).
Alternatively a Modula or something like it.
To me computers are mostly used to sort data, and secondarily to
calculate. Thirdly, and very rarely, to develop other programs, such as
OSes and compilers. You do not see this in most CS curricula.
Seriously, what about teaching SQL or RPG or Ramis as first language,
and have the first course in *data* design, and then put them to work on
expressing such things and queries against them in one of the above?
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukdavecb@yunexus.UUCP (David Collier-Brown) (04/09/90)
I wonder if people are forgetting a cardinal rule of programming:
to write **into** a language, instead of **in** it.
It was beaten into my recalcitrant brain in the punch-card era
at Windsor, and I noted later that it was alive and well in introductory
computer science at Waterloo and UofToronto, so I'm surprised that it hasn't
surfaced in this forum for a long time (:-)).
I claim the first language is important, but not critical if one
teaches the students to think in terms of simple, representable
constructs. The language then used should contain the constructs,
and should have good diagnostics. Bad error messages are worse
that bad languages, IMHO!
If one has to use C or PL/C or FORTRAN, one had best work on course
content **carefully**, and pick a good compiler[1]. UofT has one of
the better home-made languages, which comes in graduated subsets: this
make it easier to get away with a bad course outline (:-}).
--dave (at Ork, a competing university) c-b
[1] I recommend RedC, a **good** student compiler.
--
David Collier-Brown, | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or
72 Abitibi Ave., | {toronto area...}lethe!dave
Willowdale, Ontario, | "And the next 8 man-months came up like
CANADA. 416-223-8968 | thunder across the bay" --david kiplingmrys@ethz.UUCP (Michael Rys) (04/09/90)
In article <7300008@ux1.cso.uiuc.edu> cs290ac@ux1.cso.uiuc.edu writes: >I'm looking for opinions on what languages people think should >be taught as introduction to programming for both CS majors and >non-CS majors. My initial opinions are C for CS majors because >of its popularity, and its low-level programming characteristics. > DON'T go with C if you want to teach CS. I would propose the following 1. If you take a functional approach take: Scheme or ML 2. If you take a procedural approach: 2.1 Teach them Dijkstra's Method of constructing programs using predicate calculus and invariant. This keeps you independent of machines, languages etc. 2.2 Take any of : Pascal, Modula-2, Oberon I wouldn't take C or Ada (too complex for beginners). This is for CS students. If you want to teach non-CS students I would either go for Modula-2, Pascal or Lisp, APL (still great for Mathematics). Other languages you might look at: Icon, Eiffel If you want to get programmers for a job or a specific company, go and take C or any other language. And don't forget a good textbook, since CS is not only programming!!! Cheers.../Michael +---------------------------------------------------------------+ | Michael Rys, V. Conzett Str. 34; CH-8004 Zuerich; Switzerland | +---------------------------------------------------------------+ | UUCP: mrys@ethz.UUCP or EAN: mrys@ifi.ethz.ch | | mrys@bernina.UUCP IPSANet: mrys@ipsaint | | Voice: +41 1 242 35 87 | +---------------------------------------------------------------+ -- Wovon man nicht sprechen kann, darueber muss man schweigen. -- Ludwig Wittgenstein, Tractatus logico-philosophicus
dooley@physics.utoronto.ca (Kevin Dooley) (04/09/90)
In article <4147@ethz.UUCP> mrys@bernina.ethz.ch.UUCP (Michael Rys) writes: >In article <7300008@ux1.cso.uiuc.edu> cs290ac@ux1.cso.uiuc.edu writes: > >>I'm looking for opinions on what languages people think should >>be taught as introduction to programming for both CS majors and >>non-CS majors. My initial opinions are C for CS majors because >>of its popularity, and its low-level programming characteristics. > >DON'T go with C if you want to teach CS. I would propose the following > >This is for CS students. If you want to teach non-CS students I >would either go for Modula-2, Pascal or Lisp, APL (still great for >Mathematics). I disagree. If a non-CS student is taking a CS course, it is because that student wishes to learn how to program, most likely because they will be using computers in problem solving. In other words, they will need to know how to do practical things using practical readily available languages. C is easily the most common language on large machines so, despite all of the difficulties in learning C as a first language, you do students a disservice by teaching them something that they can't use. I have no objection to teaching CS majors some goofy language like lisp as a first language, but those of us in the sciences need practicality. Kevin -- Kevin Dooley UUCP - {uunet,pyramid}!utai!helios.physics!dooley Physics Dept. BITNET - dooley@utorphys U. of Toronto INTERNET - dooley@helios.physics.utoronto.ca
davee@hpcll14.HP.COM (Dave Elliott) (04/09/90)
I teach several evening courses at National University in San Jose. The
core of the undergraduate CS curriculum is a three course sequence:
C Programming
Data Structures
Algorithms
Each course lasts one month, with sessions held two nights a week (4.5 hours
per evening) and 1.5 Saturdays. When I first started teaching these courses
the language used was Pascal. In response to student "requests" (petitions,
etc.), the language was changed to C. The students felt that this would
improve their job prospects upon graduation.
These are my observations:
1) More students are dropping out of the program during the first month.
Which is more intimidating?
read(num)
or
scanf("%d",&num)
2) Students are having a harder time grasping the concepts of the second
and third month because they are still struggling with C.
3) The quality of the students' programs have suffered.
4) It is harder to find good textbooks that use C.
5) The students that graduate are having an easier time finding jobs.
There's no doubt that employers are viewing C knowledge as a big advantage
in choosing among applicants.
My recommendation would be to teach the introductory CS courses in Pascal.
Once the students are completely comfortably with the concepts of good
programming, give a course on "C for the Pascal Programmer". Teaching C to
non-programmers may only produce a new crop of bad coders.
-- Dave Elliott
davee@hpda.hp.comrro@debussy.CS.ColoState.EDU (Rod Oldehoeft) (04/10/90)
In article <1990Apr9.114303.501@helios.physics.utoronto.ca> dooley@physics.utoronto.ca (Kevin Dooley) writes: >In article <4147@ethz.UUCP> mrys@bernina.ethz.ch.UUCP (Michael Rys) writes: >>In article <7300008@ux1.cso.uiuc.edu> cs290ac@ux1.cso.uiuc.edu writes: >>>I'm looking for opinions on what languages people think should >>>be taught as introduction to programming for both CS majors and >>>non-CS majors. [Deleted] >>DON'T go with C if you want to teach CS. [Deleted] >I disagree. [Deleted] In the 18 years I've been in the CS "ed biz" this question has been nearly constantly batted around, and will always continue to be. The reason has to do with the schizophrenic nature of the introductory CS course, which is in turn caused by the variety of clientele serviced. At a mortal state-assisted university, all of these people are to be found in CS 1: 1. The CS major who has some programming background, and who will succeed as a CS major. Here is an opportunity to get on with CS, so maybe a functional/object oriented/fill in your own approach is best. 2. The CS major who has no background, and who will succeed. Probably ditto, but don't forget that the student needs to learn other language tools as well. Further, the lack of background dictates choosing an "easy" language. 3. The CS major who will not succeed at CS, or will opt out for other reasons. Most of us think a useful experience should result anyway, so a widely available programming language should be taught. 4. The non-CS major who will, as a result of this experience, become a CS major. Once again, let's take the opportunity to get beyond programming to CS for this person's sake. 5. The non-CS major who will not become a CS major. Case 3 applies. Note that the correct thing to do depends on what will happen to the student _in the future_, a difficult thing to predict. All 5 categorites have nontrivial populations. Some schools have CS 1 for current majors, and another section for current non-majors. To the extent a student is in the wrong section because the future is not yet known, educational efficiency will be sacrificed. No easy answer. Rod Oldehoeft Email: rro@CS.ColoState.EDU Computer Science Department Voice: 303/491-5792 Colorado State University Fax: 303/491-2293 Fort Collins, CO 80523
jnixon@andrew.ATL.GE.COM (John F Nixon) (04/10/90)
davee@hpcll14.HP.COM (Dave Elliott) writes: [stuff about intro course taught in C] > 5) The students that graduate are having an easier time finding jobs. This is a difficult question to answer, but how do the successful students of the C course compare in job performance with the successful Pascal course students? Perhaps employers are using C to "wash out" marginal programmers since C requires some discipline to use. ---- jnixon@atl.ge.com ...steinmetz!atl.decnet!jnxion
jnixon@andrew.ATL.GE.COM (John F Nixon) (04/10/90)
I wrote: >davee@hpcll14.HP.COM (Dave Elliott) writes: >[stuff about intro course taught in C] >> 5) The students that graduate are having an easier time finding jobs. >This is a difficult question to answer, but how do the successful students >of the C course compare in job performance with the successful Pascal course >students? Perhaps employers are using C to "wash out" marginal programmers >since C requires some discipline to use. Reading this again made me question a couple of things. One, if this is really an introductory course, why do the students think that is all that is required to obtain a job? Name one other field of study where people get jobs after an introductory course. Two, why do the employers think this way!? Something seems misnamed here - either you are training already educated programmers in C (in which case the course is "Topics in C programming"), or this is an "introductory programming" course, in which case choice of language is better made on reasons other than market forces. ---- jnixon@atl.ge.com ...steinmetz!atl.decnet!jnxion
diamond@tkou02.enet.dec.com (diamond@tkovoa) (04/11/90)
In article <259@puma.ge.com> jnixon@andrew.ATL.GE.COM (John F Nixon) writes: >One, if this is >really an introductory course, why do the students think that is all that >is required to obtain a job? Job offers. >Name one other field of study where people get >jobs after an introductory course. Accounting. There are probably others, too. >Two, why do the employers think this >way!? Because it's cheaper to hire 10 programmers at $30,000 each who can't get a job done -- who will never get it finished properly -- than to hire 1 at $75,000 who can do it in 6 months. It is cheaper, isn't it? (:-S sarcasm) That's how most employers are managed. (no sarcasm in this line) -- Norman Diamond, Nihon DEC diamond@tkou02.enet.dec.com This_blank_intentionally_left_underlined________________________________________
djones@megatest.UUCP (Dave Jones) (04/13/90)
In article <7300008@ux1.cso.uiuc.edu> cs290ac@ux1.cso.uiuc.edu writes: > >I'm looking for opinions on what languages people think should >be taught as introduction to programming for both CS majors and >non-CS majors. My initial opinions are C for CS majors because >of its popularity, and its low-level programming characteristics. > When I taught Introduction to Programming to C.S. majors, as a visiting associate prof for a couple of years, I largely ignored the _Oh! Pascal_ I was supposed to teach from (shudder!), and taught Dijkstra's method of invariants. But I think it is complete folly not to write and test actual programs. For that purpose, we had to use Pascal, as required by the University's curriculum committee. After much reflection on the subject, if I had it to do again, I would fight long and hard against using Pascal. I would start with a "toy" assembly language, following that with C, and then C++ with a good class-library. Introduce stacks and structures in the assembler phase. That will be the stepping-stone to C. Introduce information-hiding, encapsulation, etc. in C, then move to C++. In other words, rather than attempting to hide the machine from the students, I would try to help them learn how the increasingly "high-level" languages are of value and what exactly compilers and linkers and runtime library-routines really do. Languages that automatically do very complex tasks at runtime, such as unification, heap-management with garbage collection, task-scheduling, or hash-table lookups, would be deferred until the second course or later. Ditto for "functional" languages. I would always introduce new language features after having shown how the task which the feature automates would have been done using the lower level tools.
djones@megatest.UUCP (Dave Jones) (04/14/90)
From article <960021@hpcll14.HP.COM>, by davee@hpcll14.HP.COM (Dave Elliott): > [ He changed from Pascal to C. Then... ] > These are my observations: > 1) More students are dropping out of the program during the first > month. ... > 2) Students are having a harder time grasping the concepts of the > second and third month because they are still struggling with C. > 3) The quality of the students' programs have suffered. > 4) It is harder to find good textbooks that use C. > 5) The students that graduate are having an easier time finding jobs. > I find much of this rather surprising. In what ways do the students find C to be more difficult? (Are you using ANSI C and lint, by the way?) Could you save the day by replacing some of the standard library routines with easier to use, but perhaps less general ones? The part about finding good text-books may be true. I have often toyed with the idea of writing an introductory text using C. BTW, when I was teaching, the most popular text on Pascal, by far, was _Oh! Pascal_, an overblown, horrid, rambling, condescending book that contained some of the worst semi-correct Pascal programs I have ever seen. (Check out "gerunds" for a tragic laugh.) They have since replaced it with an even larger second edition. You could stun an ox with it, but I'm not sure anyone can teach a student with it. I would think that the recent C++ craze would have spawned a large number of texts using that language. Are any of them any good? That to me would seem to be the way to go. C++ is, IMHO, an improvement over orignial C. > There's no doubt that employers are viewing C knowledge as a big > advantage in choosing among applicants. That may be a little silly. A good programmer should be able to pick up most languages rather quickly, provided he has a good understanding of what compilers and linkers do. But then I guess there are employers out there who are silly. My recommendation would be, read a book on the language that the employer specifies, whatever it may be, then put it on the resume. > My recommendation would be to teach the introductory CS courses in > Pascal. Arrrrghh. There must be a better choice than that. > Once the students are completely comfortable with the concepts of > good programming, give a course on "C for the Pascal Programmer". How are the students to become "completely comfortable with the concepts of good programming" if they must group all structure definitions together in one place, procedure declarations in another, and have no mechanism for creating and using library packages, or for defining variable length arrays? You must be thinking of some Pascal extension or another. Plain Pascal makes it utterly impossible to program non-trivial applications well.
lth@idiotix.cs.uoregon.edu (Lars Thomas Hansen) (04/14/90)
In article <12594@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >In article <7300008@ux1.cso.uiuc.edu> cs290ac@ux1.cso.uiuc.edu writes: >> >>I'm looking for opinions on what languages people think should >>be taught as introduction to programming for both CS majors and >>non-CS majors. My initial opinions are C for CS majors because >>of its popularity, and its low-level programming characteristics. > >[...] > >After much reflection on the subject, if I had it to do again, I would >fight long and hard against using Pascal. I would start with a "toy" >assembly language, following that with C, and then C++ with a good >class-library. Introduce stacks and structures in the assembler phase. >That will be the stepping-stone to C. Introduce information-hiding, >encapsulation, etc. in C, then move to C++. > >[Some reasonable justification deleted] This seems to imply that you consider programming to be the skill of implementing specifications. I have to disagree with you. In the end we all have to get the code working, but I believe that a programmer is someone who is creative, inventive, and works mostly with conceptual structures. To program is to be creative; we need tools (languages!) that let us quickly and easily implement our high-level designs so that we can test them and refine them further. I am _not_ advocating that the students be taught that the computer works by magic, rather that their primary effort should be spent on solving the problems that need solving, not on learning which register is suitable for what on an 8086 (or whatever processor). Your approach is to let the students discover the utility of HLLs because they are simpler to use and offer more power than assemly language; my approach is to let the students discover the utility of LLLs (low-level languages, that is) because they offer more control and performance than HLLs. The basic idea, however, is that there is an idea to explore, a problem to solve, not a technology barrier to overcome. For these reasons, I am convinced that a "clean" HLL (like Scheme) is ideally suited to introduce students to computer programming. This applies to CS and non-CS types alike; in fact, the latter group is likely to benefit at least as much as the former, since they will most likely end up using some VHLL or 4GL in any job they might get. (Would anybody out there hire an assembly language programmer with 4 months' training?) To educate programmers as implementers and nothing else is a shame. --lars
djones@megatest.UUCP (Dave Jones) (05/04/90)
I have a suggestion. Would everybody who continues this thread please indicate what kind of teaching experience they have? I admit that mine is quite limited: four semesters of calculus as a graduate fellow, and two and a half years full time as a C.S. visiting associate professor. I think it would be nice to know where other people are coming from. It would be particularly interesting to hear from people who have tried several different approaches. Now to reply to an reply to a reply to .... From article <CLINE.90Apr25085430@cheetah.ece.clarkson.edu>, by cline@cheetah.ece.clarkson.edu (Marshall Cline): > In article <12704@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) says: >> [ ... discussing the use of complicated computer languages >>> in C.S. 101 -- Introduction to Computer Science ...] >> >> I would prefer to build up to all that. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I vehemently disagree. > > I believe catagorically that the way to teach people about computers is to > let them `play'. Analogy (beware!): music has *lots* of theory, but the way > to teach an instrument is to let them enjoy it. The analogy is indeed dubious, but I will go along with the gag. Recall what Charlie Parker said: "First learn your horn and all the theory. Next develop a style. Then forget all that and just play." First things first. In our case the "horn" is the computer. Find out at least a little about what kind of thing it is. I used to start my C.S. intro classes by opening up a PC, pointing out the memory chips and the cpu, and describing in very general terms what they do. Next, a bit of assembler is indicated. Only then would I get into the "theory" (abstract languages). Following up on this music analogy, have you ever taught music to a beginner? I have. Or rather, I have taught the rudiments of jazz improvization to people who have never improvized jazz. You see, I am a sax player, happily living in a place where there is a very active jazz scene. I can assure you that people who learn to improvize through undisciplined playing, without a basis in theory, inevitably develop bad habits and limitations which prove difficult or impossible to overcome. I've heard people say the same is true of programmers who begin by "playing" with computers. But you know what? I didn't recommend teaching a lot of theory before allowing the students to play with the computers! I don't know what gave you the idea that I did. I only said that I would not start out with a complicated computer language. I might add that there should be discipline to the play, just as there must be discipline to musical practice. It can be fun without being haphazard and reckless. Sloppy practice only reinforces bad habits. > (Before you press the Flame > key, let me qualify: the long term goal is to have composers, not players. > But I believe people don't learn well if you shove a lot of theory down > their throats when they have *no* idea where this theory will be applied). > Again you are arguing against a position I never even hinted at. I firmly agree that the concrete should precede the abstraction. If you don't have two concrete examples, there is no need for the abstraction. So give two examples first, then generalize. Dave P.s. It's "categorically".