garry@batcomputer.tn.cornell.edu (Garry Wiegand) (01/15/87)
(cross-posted from comp.lang.misc to comp.edu) In a recent article bzs@bu-cs.BU.EDU (Barry Shein) wrote: >... >Actually, I am more and more drawn towards the concept of surveying >programming languages in a first 1-year course, possibly getting a >little proficiency in one but touching upon more than just one or two. >... This was my own actual experience and I can vouch for its worth: the second c.s. course I ever took was the graduate Computing Languages Survey and - it was FUN! We did NOT spend much time talking about the abstractions or the details of the languages; instead, the professor was adept at picking problems and projects, and we could just *see* how the languages fitted in with the problem. It quickly became obvious that each computer language had a mental model - a way of thinking of things - associated with it. More slowly - serenditously - it became obvious that programming itself was just a matter of finding the right mental model, the right way of looking at any given problem... Programming can be thought of as a painful matter of cramming one's ideas into a very rigid, stylized, and unforgiving space --- or it can be thought of as mind-expanding and creative. I think it can be a means of *discovering* a solution, of finding the "right" description of the problem, not just a matter of encoding machine instructions. Learning- by-survey promotes this thoughtfulness, and I think it's an excellent idea. As an aside: the ACM back in 1968 or so made a "suggested" list of CS course offerings. I noticed a while back when I was applying to grad schools that 80% of the schools in the country had just adopted that list, with but trivial variations. When you speak of creative thinking, CS departments would seem to come in last. Changing their whole approach to first-year courses is not going to be easy :-( garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu)
cavrak@uvm-gen.UUCP (Steve Cavrak) (01/19/87)
> In a recent article bzs@bu-cs.BU.EDU (Barry Shein) wrote: >>... >>Actually, I am more and more drawn towards the concept of surveying >>programming languages in a first 1-year course, possibly getting a >>little proficiency in one but touching upon more than just one or two. >>... This approach certainly has a lot to recommend it. It especially works nicely in the "Computers for Poets" course. Teaching LISP is definitely more fun than teaching Basic, and assembly language avoids the "math anxiety" reaction that FORTRAN tends to evoke. Vladimir Zwass's "Introduction to Computer Science", Barnes and Noble Outline Series, tends to follow this approach also, and even talks about operating systems and files. CS department, like math and physics departements, are often under the restraint to offer a service course that will teach students "how to program". Like most service courses, the entry level skills and commitment ("I just want to be an X!") add to the difficulties. Luckily, no one ever promised that teaching would be easy work. -- Stephen J. Cavrak USENET: ...!decvax!dartvax!uvm-gen!cavrak Academic Computing Services CSNET: cavrak@uvm The University of Vermont OtherNET: cavrak%uvm@csnet-relay Burlington, VT 05405 MABELL: (802) 656-3190
UH2@PSUVM.BITNET (01/22/87)
Gerald Weinberg, who may or may not be famous depending on what field you are in, is often cited as proposing that Intro Programming courses should teach two languages simul- taneously. Basically, he is trying to avoid the strong commitment people tend to make to their first language.
barber@rabbit1.UUCP (Steve Barber) (01/23/87)
Garry Wiegand writes that the course he took in comparative programming
languages was a positive experience, and I'm sure it was: for a CS major.
The issue here is what to teach a "beginner", so that they learn what
they "need" to learn. I don't think that the multiple-language approach
in a beginning class is the way to go, as it is far better to be proficient
in something, than to be acquainted with everything, at least when dealing
with such "fundamental" engineering/science skills as programming.
--
Steve Barber Rabbit Software Corp.
...!ihnp4!{cbmvax,cuuxb}!hutch!barber ...!psuvax1!burdvax!hutch!barber
(215) 647-0440 7 Great Valley Parkway East Malvern PA 19355uh2@psuvm.bitnet.UUCP (01/25/87)
barber@rabbit1 argues that we should only teach ONE language to beginners because it is better to be proficient at one thing than to be aware of many different things (my paraphrase). I agree that proficiency is a good thing--but what's the best way to produce proficiency. Maybe comparing TWO languages will lead to superior proficiency. (Hmmm. There's a research project in that statement.) For example, I recently had to discard my "modern" principles and teach FORTRAN. As a lecture device, when about to introduce a new feature such as character manipulation or complex numbers or recursion or double precision, I would have the students "guess" at what the correct syntax or semantics might be. Often, there guess would be a very good one, except that they would guess the Pascal or Simula convention instead of the FORTRAN one. Then I'd get to explain that there were multiple choices that a language designer might make, and thet the FORTARN folks had made sch and such a choice whilethe XYZ designers had made the opposite choice. I wrote a short article about this, but Never published it. I think "Comparative Languages" is a good way to teach beginners BECAUSE it makes them more proficient in the medium and long run--and maybe in the short run too. lee
fouts@orville.UUCP (01/25/87)
Actually, what you teach a beginner depends a whole lot on what the beginner's going to do with it in the end. If you've got grade school kids and you still believe in CAI, you probably ought to teach them LOGO, because you want them to get the interactive/experimentation pardigm. You should probably also have a turtle robot, it's much more fun to paint on the floor. If you've got high school kids or continuing education students and you want to make them computer literate, go ahead and teach them BASIC, after all it's just LOGO for adults (:-) If you are running a body shop to produce application programmers for BofA, teach them COBOL and make them read Jame Martin. Don't even mention electrons to them, they've got enough problems. If their managers, just let them read James Martin. If you are teaching social scientists, teach them SPSS or SpeakEasy and give them Disspla or some such for their graphics. If they are engineers or scientists, give them FORTRAN (shudder) and stay out of their way. (Well, maybe a numerical analysis class if you are brave.) If they think they are going to be software engineers when they grow up, teach the ADA first, and then teach the one's that are left PL/1. Then let the survivors know they have to program in JOVIAL. If they want to be computer scientists, don't teach them any languages, concentrate on concepts and give them programming assignments. It doesn't really matter, the ones that were born to it will do good despite your best efforts, the ones who don't belong here will do poorly no matter how hard you try, and the ones in the middle will respond about the same way to any first language.
trent@cit-vax.UUCP (01/25/87)
Shouldn't this subject be in comp.ai? :-) -- "...always begins with a single step." ../ray\.. (trent@csvax.caltech.edu, rat@caltech.bitnet, ...seismo!cit-vax!trent)
melissa@cca.UUCP (01/27/87)
[Doesn't the line eater ever get full?] In article <269@rabbit1.UUCP> barber@rabbit1.UUCP (Steve Barber) writes: >Garry Wiegand writes that the course he took in comparative programming >languages was a positive experience, and I'm sure it was: for a CS major. I think we are talking about two kinds of courses here. For a CS major, I agree with Mr. Wiegand: I would much prefer a comparative programming course. A non-CS major could be taking the course for a number of reasons, ranging from trying to decide whether to go into CS, taking it because he/she is entering a related field, wanting to know something about computers, or because it fit into his/her schedule. For these students, I think a course based upon one language, and basic programming skills, is more appropriate. So, if both courses are offered, the first being a required course for CS majors, and the second being a general course, geared towards non-CS majors, the students could pick and choose. In this scenario, those thinking of becoming CS majors would have to make a choice, since in taking the non-CS major course, if they then decided to go into CS, the class wouldn't count for CS credit. When I went to Boston University, they had two d coursesifferent, except that the first CS class wasn't a comparative class; it was plain old Pascal. -melis -- ---- The debris of thoughts grown stale, and platitudes too often repeated...
tlh@arthur.cs.purdue.edu.UUCP (01/28/87)
Steve Barber didn't think that a multiple language approach was the way to go in a beginning class because "it is far better to be proficient in something, that to be acquainted with everything..." with regard to programming. I am only speaking from my own experience, but I feel that being exposed to unconventional languages in an undergraduate programming languages course IS the way to go. It breaks undergraduates out of their Pascal (and gads BASIC) mindsets and introduces the fact that first problems are solved then a choice is made in what language to implement the solutions. Also, I think that when the time comes for comparative programming languages, students are generally quite proficient in a conventional language. Tom
dam@uvacs.UUCP (01/28/87)
[Who taught the line eater to eat lines?]
Here's a semi-facetious comment on How To Avoid Instilling 1st-Language
Preference In Our Students....
Make their first programming course use FORTRAN on punch cards.
--
Dave Montuori (Dr. ZRFQ) -- Central Va. State Home for Professional Students
NSA line eater food: terrorist, DES, drugs, cipher, secret, decode, CIA, NRO.
dam@uvacs.cs.virginia.edu "My Maserati does 1E+5;
{allegra|cbosgd|ncsu}!uvacs!dam I lost my license - now I don't drive...."jk3@psuvm.bitnet.UUCP (01/28/87)
I sort of agree with aspects of both sides of the arguments, but let me mention a course that I have developed this year which has gained considerable popularity (<20 students in Fall, >70 students this Spring). The course is designed to teach students something about computers, but without going through the typical programming route. After covering traditional computer concepts (what is a CPU, I/O devices, etc.) we concentrate heavily on becoming competent computer users by learning applications software. We cover WP,Spreadsheets, Database, Graphics, and Communications. Also, I throw in a little on programming concepts, at the end. The course is primarily taught on PC's (IBM, or compatibles) using ENABLE (tm). To allow them exposure to similar integrated packages on other machines, we are also using JAZZ (tm) on the MAC and a package on the mainframe. The students seem quite receptive to this type of 'Intro to Computers'. We are trying to persuade most students generally interested in computers toward taking this course before any programming courses (unless, of course, programming courses are required for their major). Well, that's my $.02 worth (don't typewriters have a CENTS key?!?!?!)
brad@looking.UUCP (01/29/87)
In article <882@arthur.cs.purdue.edu> tlh@mordred.cs.purdue.edu (Thomas L. Hausmann) writes: > > I am only speaking from my own experience, but I feel that being exposed > to unconventional languages in an undergraduate programming languages > course IS the way to go. It breaks undergraduates out of their Pascal > (and gads BASIC) mindsets and introduces the fact that first problems > are solved then a choice is made in what language to implement the > solutions. I think this is the right attitude -- that you attack the problem first -- but I don't think this "algorithm first, then choose language" approach is used much in the real world. 99 times out of 100, the language chosen for a project will be one of a) The language best known by the programmer b) The official language designated by the company c) The language of the course (for students) d) The language the boss likes best e) The language you happen to have a good compiler for (in Unix, everything is done in C, so you do it in C even if that would not be the perfect choice) None of these considerations have much to do with the algorithm. How often have you coded something up in C when a language like snobol, apl, lisp or even Basic would have gotten the job done faster? The language is chosen second in the real world only when the project is large enough to justify the cost of re-familiarizing everybody with a more familiar language. I even suspect that the most common 'second language' for a project is assembler. Small portions of a project will get coded in assembler from time to time for speed considerations. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473
scott@gitpyr.UUCP (01/30/87)
I once heard an idea from a professor of mine: teach them the
theory first, save the programming till later. The more I think of this
the better I think it is.
In a typical beginning computer science course, you are given
a programming language and taught how to use it. Usually by examples of
particular problems solved in the language. Basicly, you are being
taught `this is how you do such and such in this language.' I think
a much better approach would to first teach them what types of things
are typicly done. Teach them the basics of problem solving, algorithms
problem decomposition, etc. Once they know how to formulate solutions to
problems, they will begin to ask the question `how can I implement this
solution in this language?'. Then give them the programming language, or
maybe even their choice. Then they can see languages for what they
are worth, they will be able to see the strong and weak points of the
different programming languages. They will begin to see programming as
a tool and not a discipline ... and will be able to chose the best tool
for the job they want to do, not just the one they are most familiar
with.
- Scott Holt
------------
--
So this is the earth...big fat hairy deal.
Scott Holt at Ga. Tech.
ARPA: scott@pyr.ocs.gatech.edu BITNET: ccastsh@gitvm1
uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!scottdant@tekla.UUCP (01/30/87)
In article <1212@uvacs.CS.VIRGINIA.EDU> dam@uvacs.UUCP (Dave Montuori) writes: >Here's a semi-facetious comment on How To Avoid Instilling 1st-Language >Preference In Our Students.... > >Make their first programming course use FORTRAN on punch cards. On an IBM 360, as well. This will also prevent "Instilling 1st-Computer Preference In Our Students". I knew there must have been a reason all intro CS classes (including the business oriented one) at school taught programming this way. Those professors were smarter than I thought. --- Dan Tilque dant@tekla.tek.com I taught my computer how to roll over and play dead. Now that's all it does.
lou@hoxna.UUCP (01/31/87)
In article <2980@gitpyr.gatech.EDU>, scott@gitpyr.gatech.EDU (Scott Holt) writes: > > < Teach problem solving, analysis, etc. Then programming> Yeah, well, the problem I have with this approach is that : A. It's no fun. I know all the reasons why school shouldn't be fun, and why discipline is good for ya' , but frankly, I got into computers as a profession because of a programming course. To me, the fascinating part is making the machine do things, and I learned all the other stuff only because it made it possible to make the machine do more. If they'd started me with 2 or 3 semesters of paperwork, *then* showed me a keyboard, I'd probably have become a lawyer. B. I feel it's much harder to learn the theories, or at least learn them well, just on paper. I feel that the basics of decomposition, etc. , should be taught at the same time (concurrently) as basic programming. These skills are synergistic; the better you understand the theory, the better you program, but programming makes you understand the theory better. Teaching both at the same time steepens the learning curve. Also, many people get more of a sense of accomplishment out of producing an actual working program, no matter how trivial ( print*,'hello, world' :-) then from passing exams. > They will begin to see programming as a tool and not a discipline I disagree with this sentiment - I am a p_r_o_g_r_a_m_m_e_r_, in the same sense as someone is a psychologist, or whatever. It is too a discipline. lou @ hoxna
bzs@bu-cs.UUCP (02/02/87)
Brad makes a valid point that in "the real world" one rarely looks at an algorithm and then decides on the best programming language. That many other factors (availability, familiarity etc) will come first. No real argument but I think there is another point to be made that is more important: Once exposed to a language like Snobol (as an example of a language that prompts wonderfully innovative solutions to problems) many good programmers can (more or less) write Snobol in C. Or Lisp in Pascal or whatever. It won't be pure, it will be in fact trivialized, but having seen how these languages handle certain problems those problems really do become much easier to think about whatever the language of implementation is, wouldn't seeing a comment in a C program like: /* * Having consed the new string structure into the list * we'll now do a span/break match finally calling the * garbage collector to get rid of the deletions, the * car should be a picture-like format specifier to dump * the result with. Parameter passing to this routine can * be best described as similar to call-by-name. */ be more confidence building than thinking a person had just made up their solutions out of whole cloth? Gee, I'd almost believe a person who wrote a comment like that might actually know what s/he's talking about and knows how to steal good ideas where another is just inventing with every new line of code (gee, are they really as bright and creative on the fly as the whole rest of the CS community's combined 30 year efforts were...maybe.) Obviously we have to assume that something like that above is really a good solution to the problem at hand and not just a show-off. I am, in practice, far more disturbed by all the programs which don't realize they are just solving a well understood problem, such as garbage collection or string manipulation. -Barry Shein, Boston University P.S. Comments in my programs often look like that, often starting with the caveat "this only looks like a FOO program...".
bob@cald80.UUCP (bob) (02/04/87)
In article <2980@gitpyr.gatech.EDU> scott@gitpyr.UUCP (Scott Holt) writes: > > I once heard an idea from a professor of mine: teach them the >theory first, save the programming till later. The more I think of this >the better I think it is. > In a typical beginning computer science course, you are given >a programming language and taught how to use it. Usually by examples of >particular problems solved in the language. Basicly, you are being >taught `this is how you do such and such in this language.' I think >a much better approach would to first teach them what types of things >are typicly done. Teach them the basics of problem solving, algorithms >problem decomposition, etc. Once they know how to formulate solutions to >problems, they will begin to ask the question `how can I implement this >solution in this language?'. Then give them the programming language, or >maybe even their choice. Then they can see languages for what they >are worth, they will be able to see the strong and weak points of the >different programming languages. They will begin to see programming as >a tool and not a discipline ... and will be able to chose the best tool >for the job they want to do, not just the one they are most familiar >with. BRAVO!! I was wonering if anyone out there thought the way I do. I remember the very first project that I was given in my first computer class: Write down the instructions for tying your shoes (no pictures). Most of the answers came in at about 2 paragraphs. The correct answer is done in about a page and a half. The idea was to show that computers are actually very stupid; they only do what you tell them; no more, no less. You could tell the students that would be good programmers by the amount of ambiguity and the number of assumed steps. We then proceeded to learn about problem solving on the computer. We were taught to solve problems by hand first (how would I rearrange these numbers if I only have one extra spot to put them?). Making the code to do that wasn't much more than "how do I tell the computer to do what I just did?". We didn't even get accounts on the system for about 2 weeks. The first language that we used was APL (ouch! no flames) but the lessons learned weren't lost when I moved to other languages (BASIC, FORTRAN, C). I later took a PASCAL course a local University and was surprised at the number of people who couldn't even solve a basic bubble sort or check for a series of numbers in a list without *LOTS* of help from the instructor. I better get out of here before I write a book. My command of the English language is not nearly equal to programming (too many ambiguities for me). -- Bob Meyer Calspan ATC seismo!kitty!sunybcs!cald80!bob decvax!sunybcs!cald80!bob
rb@cci632.UUCP (Rex Ballard) (02/05/87)
In article <2980@gitpyr.gatech.EDU> scott@gitpyr.UUCP (Scott Holt) writes: > > I once heard an idea from a professor of mine: teach them the >theory first, save the programming till later. The more I think of this >the better I think it is. > - Scott Holt I would agree. I also agree with a subsequent poster that it is important to get them involved with the machine as well. I used to teach 8-18 year olds about computers. Rather than jumping immediately into a programming language, we had a "logo-like" interactive system which taught the concepts of sequential instructions, stored programs, variables, iterations, conditionals, procedures, and funtions. By teaching them what I call "macro thinking", ie. breaking the problem down from the top down then building the solution from the bottom up, it became a simple matter to move them into even BASIC without them learning bad habits as part of the language. Several students made the transition from BASIC to Pascal to even assembler or FORTH in a matter of a few weeks simply because they knew how to express themselves in terms of macros. I chose the "logo-like" language because it was relatively easy to learn, interactive, and gave immediate feedback with reguard to the results of a program. They could see the pieces execute and put them together. In addition, graphics were well supported and made the course more interesting. I wasn't wild about BASIC because it is possible to learn some very bad habits with this language, but because it was interactive, and was preceeded by the earlier background, students were less prone to commit them. Again graphics was also important. We chose FORTH because it was again interactive, and forced one to completely understand the problem since the solution HAD to be built from the bottom up. Even the Assembler was really a debugger with a "save" capability. In each case, graphics and sound routines were used to improve the interaction and immediate feedback. The key to these language choices was that it made the computer "teachable" rather than "programmable". There were few "magic functions", so the students were able to understand how each piece worked. In addition, they were able to build on previous work without having to recompile everything. It was also possible to "unit test" each piece of code, and gradually test the various levels of integration. Many of my students had difficulty with Pascal because they not only had to write each routine, but they also had to write the "unit test" calls into their mainline routines. Once they got past the semantics, and learned the "workbench" however, they had little difficulty getting working code in the relatively short time available (45 mins of class, no lab work). After working on and debugging "top down implementations" where the aim was to start with the mainline and "fill in the stubs", and "discovering" bugs in code that had never been executed before (for example code that destroys the stack), I am glad I taught "bottom up implementation". One of the things I found especially interesting was the way the more "artistic" (musicians, artists, writers) students began to do their programming when they were allowed to try some "free style" assignments. They would simply build the primatives and combine them in various creative ways. In these assignments, there was no "set problem" to be solved, just a program that would do something interesting without breaking. One of my students even came up with a commercially marketable product. Rex B.
michael@crlt.UUCP (02/21/87)
[nybble, nybble, nybble...] In article <843@hoxna.UUCP>, lou@hoxna.UUCP writes: > In article <2980@gitpyr.gatech.EDU>, scott@gitpyr.gatech.EDU (Scott Holt) writes: > > < Teach problem solving, analysis, etc. Then programming> > > Yeah, well, the problem I have with this approach is that : > A. It's no fun. [] > B. I feel it's much harder to learn the theories, or at least > learn them well, just on paper. [] I must agree. Hands-on is the way to go, and the sooner the better. I'd say I learned the most about computer programming (in order of decreasing amount learned): - From "Playing" with the machines. - From reading or disassembling other people's code. - From trade journals and conferences. - From formal classes. - From writing programs for work assignments. (With classes and trade journals about even.) This is not intended to slam the formal courses - I got a lot of stuff I'd never have encountered any other way there. But it was the hands-on, fun stuff (much of which I did before becoming eligible to >take< the classes) that really taught me, and stuck with me. It >IS<, however, intended to slam a now-mostly- defunct (finally!) policy at the university I attended: "No 'Frivolrous Use' of the Computer!" I'm leading edge of the Baby Boom, and had an advantage that many of my generation didn't: some access to machines and resources. I grew up in and near Ann Arbor, and was able to sneak into University of Michigan facilities while still in Junior High - auditing Galler's nighttime lectures on MAD and MESS, using a keypunch and card-sorter to make typewriter-picture QSL cards, sneaking access to an ASR35 and long-distance line to Dartmouth and learning BASIC and TSAP by looking over shoulders and reading online documentation. I got a part-time job in an electronics lab during high-school, and got to play with and old IBM vacuum tube machine and patchboard-wired dynamic logic. By the time I hit conventional courses I knew more about programming than many of the teaching fellows, and used to annoy counselors by answering questions that they couldn't (while waiting for a chance to ask a toughie of my own). I was transferred to my first official programming assignment because I was the only guy in the lab that knew FORTRAN, and put in charge of a computer when the Dartmouth environment emulator I wrote while waiting for my machine-access time slots made me look like some kind of wizard. These days I make a fine living as a consultant despite having dropped out of college short of a degree. (In those ancient days it was still thought that one needed a foreign language and a stack of humanities courses to program computers. After completing everything else, I had trouble with German, decided to take it outside and place out of the class, and never got around to returning.) If I'd encountered computers first on a purley-academic level, in courses that tought a great hunk of theory before letting the student touch a key, I'd probably have stayed in Electrical Engineering or switched to Chemistry, and be designing streetlight systems, remote sensing equipment, or new forms of toxic waste. =========================================================================== "I've got code in my node." | UUCP: ...!ihnp4!itivax!node!michael | AUDIO: (313) 973-8787 Michael McClary | SNAIL: 2091 Chalmers, Ann Arbor MI 48104 --------------------------------------------------------------------------- Above opinions are the official position of McClary Associates. Customers may have opinions of their own, which are given all the attention paid for. ===========================================================================
gilbert@aimmi.UUCP (Gilbert Cockton) (03/04/87)
In article <648@crlt.UUCP> michael@crlt.UUCP (Michael McClary) writes: >I must agree. Hands-on is the way to go, and the sooner the better. >I'd say I learned the most about computer programming (in order of >decreasing amount learned): > > - From "Playing" with the machines. > - From reading or disassembling other people's code. > - From trade journals and conferences. > - From formal classes. > - From writing programs for work assignments. > Whilst there's no doubt that the only way to learn to WRITE programs in real languages under real operating systems, is to WRITE programs, and READ other people's prorgams, this process is very time intensive. I have been told that it has taken 2-3 months for a production team to get used to GEM for example, and this team was not short on talent at all. There is a real need for a set of core language and system software principles, based on an agreed vocabulary of concepts, which can be used to accelerate the learning process. System developers could then be encouraged to stick to these core principles, abandoning them only when the principles were DEMONSTRABLY inadequate for a specific problem. Such departures would have to be documented clearly - usual trade-off here between individual ego-bruising and social benefits of standardisation. Some formal approaches to languages and systems are definitely bankrupt, and students do not really seem to benefit from them. The problem boils down to poor EDUCATIONAL technique - if courses are not evaluated properly by assessing students skills before and after the course, the quality of the course will never be known. As far as I know, there is little serious research in this area, and too many students are victims of half-hearted course development which can largely be attributed to the fact that few higher education institutions have their teaching tested by outside independent bodies. The old-boy network of external examiners which operates in some countries is not the best way to monitor the quality of university teaching. I'd be interested to hear how course-work and exams are validated in different countries/insititutions. In Britain, we have an absurd situation where far far less work is required to get a new single-institution masters course off the ground than a single-institution single-subject secondary school leaving examination (16 year olds). The quality control on the latter is far superior to the former, far more than is warranted by the difference in numbers (perhaps up to 200 students a year for the latter as opposed to 10-40 on a British MSc). When you look at the cost differences (thousands of pounds for MScs, tens for secondary school pupils), the amateur nature of course development becomes even more scandalous. This should not be be taken as a personal attack on lecturers - it is an attack on the poor educational standards of higher education INSTITUTIONS, which good staff only affect for the time they are there. Nor is there any implied criticism of technical subject ability either. The problem is one of EDUCATIONAL skills, which generally get poorer as the consumers get older, largely because sufficient resources are not allocated to course development (for ballpark figures try 0.05 man years per hour of lecture, plus 0.005 man years per minute of exam-question - once a course is developed, these figures drop substantially). Some tested teaching training would help as well, after all that is part of what lecturers are paid to do. P.S. I have a degree in education, and two years school experience. This gives me a good feel for how courses should be planned - I await correction that higher-education is so different that none of this applies. I have a little MSc/industry lecturing experience as well, and have generally had to rush the preparation of the former, so I'm not holding myself up as an example. -- Gilbert Cockton, Scottish HCI Centre, Ben Line Building, Edinburgh, EH1 1TN JANET: gilbert@uk.ac.hw.aimmi ARPA: gilbert%aimmi.hw.ac.uk@cs.ucl.ac.uk UUCP: ..!{backbone}!aimmi.hw.ac.uk!gilbert