cstjc@its63b.ed.ac.uk (A Cunnigham) (03/07/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). >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. That was the point I was trying to make. Thanks for making it in a better way for me. I should have said How to program in an imperative style. Once you understand that you cn use an imperative model in any imperative language. What is important here is that there are some languages that are very good for learning the imperative style of programming. Pascal is a good example. I wouldn't use C to teach imperative programming because there are a number of defects in the language. What C does it does exceptionally well. Teach the principles first and then get down to the fine detail. >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. I couldn't agree more. >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." Could I add, "The limits of my language are the limits of my world" -- Anthony Cunningham, Dept of Computer Science, University of Edinburgh. ARPA: tjc%ed.ecsvax@ucl-cs.arpa UUCP: ...!{decvax,ihnp4,seismo}!mcvax!ukc!ecsvax!tjc JANET: tjc@uk.ac.ed.ecsvax I think of Sarah. The rest is easy.