pds@quintus.UUCP (Peter Schachte) (03/04/88)
In article <1016@its63b.ed.ac.uk>, cstjc@its63b.ed.ac.uk (A Cunnigham) writes: > But if you know HOW TO PROGRAM then it doesn't matter if you know C ( or any > other language for that matter ). All you need is the manual and a language > definition. To take you out of context, this isn't really true. If you take a skilled 20 year veteran assembly language programmer and give hime an ML or Prolog or Smalltalk manual and interpreter, it'll probably take him quite a while to get to the point where he can program comfortably in any of those languages. There are important (necessary!) concepts that he hasn't had to face (inheritance, backtracking, unification, recursion). It also works the other way. If you take a really good ML programmer that has never seen anything so low-level as Pascal, and give him an assembler and manuals, it'll be a while before he can make use of it. I still believe it is a good idea to teach a relatively pure language as a first language, but I don't think you can really get away without teaching a broad spectrum of languages. There are algorithimic issues that you just don't see in ML or Prolog (e.g., algorithms that rely on destructive operations). And as someone who has been struggling to become comfortable with C, let me add that if you can teach the specific languages that the programmer is going to need in the outside world, so much the better. There are two separate tasks: teaching programming TECHNIQUES, and teaching programming LANGUAGES. I think the former is much more important, and if it can be done more easily in a pure langauge (which I believe is true), then it should be. It'll be easier for a graduate to later pick up a language than a technique or discipline. But better he should have BOTH when he graduates. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
peter@sugar.UUCP (Peter da Silva) (03/06/88)
In article <1016@its63b.ed.ac.uk>, cstjc@its63b.ed.ac.uk (A Cunnigham) writes: > You can learn 'good programming habits' in any language providing they're > taught well. It just happens that some languages are better for teaching > them in ( eg ML, LISP, Modula-2 ) than languages that let you pull all sorts > of nasty tricks. Would you teach someone to drive in a Formula 1 racing > car ? Or a tank ? One driving course company I know of teaches people in Porsche 944s. Their costs are lower because the kids are a lot more careful about banging up the cars than they would if they were learning to drive in Buicks. They claim they produce better drivers because their students pay more attention to what they are doing. I'm not claiming that this means you should learn to program in 'C', BTW. I'm firmly in the Pascal-as-an-educational-language camp. Just thought your analogy was a bit weak. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
jpd@aiva.ed.ac.uk (Paul Dourish) (03/07/88)
In article <725@sandino.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >>In article <1016@its63b.ed.ac.uk>, cstjc@its63b.ed.ac.uk (A Cunnigham) writes: >> But if you know HOW TO PROGRAM then it doesn't matter if you know C ( or any >> other language for that matter ). All you need is the manual and a language >> definition. > >To take you out of context, this isn't really true. If you take a >skilled 20 year veteran assembly language programmer and give hime an ML >or Prolog or Smalltalk manual and interpreter, it'll probably take him >quite a while to get to the point where he can program comfortably in >any of those languages. There are important (necessary!) concepts that >he hasn't had to face (inheritance, backtracking, unification, >recursion). Yaay! Cheers! Applause! This is exactly the point. A programming language embodies a model of a machine and a model of the solution. The important thing in a CS education is that the student should be exposed to a wide range of such models. Remember, the models that the student encounters in his course will form that basis of his solutions to problems later. If the student is always tackling things in a C-like way, then he'll always produce C-like solutions, even when these are not appropriate. So, then, the student should learn a range of models, so that he can pick the one most appropriate to a given problem. Before I get flamed here, I should point out that I'm talking about models on the level of *understanding* a problem. I'm trying to divorce the understanding and conceptual modelling of the problem from its solution. There may be constraints upon the type of solution ("Sorry, John, it's got to be written in FORTRAN and interface to those COBOL routines over there...") but there's no need to place such constraints on the programmer's understanding of the problem to be solved. Not if you want a good solution, anyway. The idea of underlying models is important. It really bugs me when concepts in one language are explained in terms of those in a completely different language, but which look vaguely similar. Too often, the teaching of programming languages is done syntax-down rather than model-up. The right way to teach a language is from the base concepts up to the actual syntax. That way when new ideas are introducted, the student thinks "Oh, yeah, I'd guessed that there should be something like that; it fits" rather than "Hmm, I wonder how that relates to what I've already learned". So, what's the bottom line? Well, here are two quotes. I've seen them attributed to Dennis Ritchie and Brian Reid respectively, but I'm not certain about them: - "A language that doesn't change the way you think about programmming isn't worth knowing." - "When all you have is a hammer, everything looks like a nail." I guess that's all.... -- Paul Dourish, Speech Input Project, University of Edinburgh, 80, South Bridge, Edinburgh EH1, Scotland. (Phone: +31 225 8883 x279.) ARPA: jpd%ed.eusip@nss.cs.ucl.ac.uk UUCP: ...!uunet!mcvax!ukc!eusip!jpd JANET: jpd@uk.ac.ed.eusip "Ain't they got no barbers where you come from, boy?"