Caveat – I am not a real programmer, so my views should be taken with a pinch of salt. I came to Occam from programming real time systems in assembler on 2-4k ROM memory systems. What I liked about the simplicity of Occam was that with PAR and PRI I was easily able to describe the things that I had had to write management routines to do previously – the typical car engine controller has foreground tasks driven by the engine turning and background tasks, such as engine temperature, throttle setting. If we want a parallel programming language for kids to learn with, in my view it should be simple and have the basic concepts – ideally we would have a language with two variants – a subset for learning and an enhanced version for serious programming. Tony Gore Aspen Enterprises Limited email tony@xxxxxxxxxxxx tel +44-1278-761000 FAX +44-1278-760006 GSM +44-7768-598570 URL: www.aspen.uk.com Registered in England and Wales no. 3055963 Reg.Office Aspen House, Burton Row, Brent Knoll, Somerset TA9 4BW. UK From: Mailing List Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Ian East Hi David I think the most important thing you said (slide 33) was that kids "should learn about Sequence, Concurrency and Event-handling (interaction) at the same time". This means getting in early, before the rot sets in. Once anyone has mastered all the nonsense and accepted it, and allowed their ego to profit from penetrating the obscure notation, you've had it. They never go back. The recent arrival of a far better GCSE Computing (OCR), where programming is at last included, and without reliance on any single PL, is an opportunity. There is instead a reliance on pseudocode. Simon Peyton Jones appears to have influenced things. Perhaps a nudge here might see the pseudocode extended to include a parallel and ALT construction, along with communication primitives. That leaves prioritisation, which IMHO is as important, and I've never felt happy with PRI PAR and PRI ALT, particularly with the combination. Badly missing prioritised vectored interrupts, which I grew up on, I proposed a 'when' construct for Honeysuckle, affording pre-emption. The trouble with that is that its component processes are more sequential than parallel, and must communicate somehow. All I could come up with was shared variables, with a little protection back from restricting assignment to one process each. There is some basis for this in Tony Hoare's original book, in his 'alternation' operator, but nowhere near enough. I'd really like to see a debate resume on what sort of prioritisation construct we need, and how to manage pre-emption. Theory is lacking, but I don't think we can wait for more. I completely agree we are facing an exponentially worse situation wrt software development given the exponential rise in core count. We must begin with the youngest, I think. Ian On 30 Sep 2012, at 11:42, David May wrote: Dear all, I've just noticed this email trail. It reminded me to post a keynote presentation I gave recently - it's here: It was given at a "Multicore Challenge" conference in Bristol last Monday. Unfortunately they lost the recording so you have to guess what I said! The main thing I've realised over the last year or two is that if you want to write efficient programs for huge numbers of cores, you have to think about the pattern(s) of communication. And of course, the language(s) have to be able to express them clearly; the compilers have to be able to analyse and optimise them; the architectures have to be designed to support them. David Ian East Open Channel Publishing Ltd. (Reg. in England, Company Number 6818450) |