Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!mcvax!ukc!icdoc!inmos!wraxall!roger From: roger@wraxall.inmos.co.uk (Roger Shepherd) Newsgroups: comp.lang.misc Subject: Re: Coverage of multitasking Message-ID: <1869@brwa.inmos.co.uk> Date: 20 Aug 89 13:19:21 GMT References: <2592@aplcen.apl.jhu.edu> <1186@sequent.cs.qmc.ac.uk> <12126@orstcs.CS.ORST.EDU> Sender: news@inmos.co.uk Reply-To: roger@inmos.co.uk (Roger Shepherd) Organization: INMOS Limited, Bristol, UK. Lines: 58 In article <12126@orstcs.CS.ORST.EDU> rudolf@oce.orst.edu (Jim Rudolf) writes: >In article <1186@sequent.cs.qmc.ac.uk> jont@cs.qmc.ac.uk (JonTaylor) writes: >> ...Couldn't it be the case that teaching parallel programming >> second to sequential is putting blinkers on students. Is it not >> possible that by teaching them to think of parallel algorithms first you >> may get a whole new set of novel answers to programming problems? > I tend to believe that most people think sequentially, and have a difficult > time with parallel concepts. On the other hand, object-oriented design > can more closely model many real-life problems than imperative languages > can, so yes, I agree with Jon that maybe there is a better approach when > it comes to teaching fundamental concepts. At Inmos we have had quite a lot of experience in trying to convince people that it is sensible to use concurrent programming to implement their systems on our (transputer) products. It has seemed to me that the people who find the concepts of concurrency hardest to understand are those who have had a computer science education; electronic engineers seem to grasp the concepts very easily. I don't think this is because one group is cleverer than the other, I think it stems from two things: Firstly, electronic engineers deal with massively concurrent systems (32 wires changing at once on bus!) every day, and know of methods by which the design of such systems can be contemplated - why should concurrent programming be difficult? Many CS graduates seem to think that it is hard (mainly because they've been taught that it's hard). Secondly, one large part of the skill of the computer scientist, is taking a problem specification, and writing a program to implement it. Often in the problems given to CS students there is little ``inherent'' parallelism, and secondly, where there is, most programming languages do not allow parallelism to be expressed and a programmer is trained to become very skilled at seeing sequential solutions to parallel problems. Sometimes programmers become so skilled that they are almost blind to the fact that there is parallelism in their problem (``Where's the parallelism in a word processor?'') I think that concurrency/parallel programming should be taught very early in a CS course. The concepts of process, synchronisation, and non-determinancy are very simple and should be taught alongside other concepts such as procedural abstraction, iteration, conditional behaviour. This begs the question of what programming language should be used to teach these concepts and the only one that I know of which represents these concepts clearly and cheaply enough is occam. Of course, there are problems such as lack of availability of occam implementations, and the fact that occam lacks various facilities (such as recursion) which also need teaching to CS students. Roger Shepherd, INMOS Ltd JANET: roger@uk.co.inmos 1000 Aztec West UUCP: ukc!inmos!roger or uunet!inmos-c!roger Almondsbury INTERNET: @col.hp.com:roger@inmos-c +44 454 616616 ROW: roger@inmos.co.uk