Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!edcastle!cs.ed.ac.uk!mikef From: mikef@cs.ed.ac.uk (Mike Fourman) Newsgroups: comp.edu Subject: Re: Language Use Summary: _If_ you understand programming, you can program in ML or Scheme Message-ID: <8446@skye.cs.ed.ac.uk> Date: 4 Apr 91 09:41:36 GMT References: <1150@ra.MsState.Edu> Sender: nnews@cs.ed.ac.uk Reply-To: mikef@lfcs.ed.ac.uk (Mike Fourman) Organization: Laboratory for the Foundations of Computer Science, Edinburgh U Lines: 104 In article 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: [ 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