Hi Richard
In my experience, as a home-educating parent, and occasional tutor, is that kids (especially boys) are really hot for programming, so teachers, schools and exam boards should respond. If they don't then parents should start asking them (and their MP) why.
I agree absolutely that kids also need some sort of application domain (library access), like music or graphics. (My eldest spends a lot of time with Unity, programming in _javascript_ (sadly).)
The security concerns undoubtedly point to stand-alone micros, which can now be bought for as little as £10. An alternative is to allow kids to bring their own laptop/netbook.
I'd strongly recommend the Transterpreter. But this desperately needs some sort of national scheme to create comprehensive free-to-use program and programming environments.
As a tutor, and former lecturer, concurrency can be far easier to master than pointers (which have been known to be unnecessary and dangerous for several decades). And it is as natural (or more so) than sequential behaviour, though it does imply mastering communication at the same time. Like life.
Good luck! Ian
On 1 Oct 2012, at 12:21, Richard Dobson wrote: Hello, this is my first post here, having lurked for some time now. It would be really good to have this discussion on the Computing At School online forum**, where the debate about teaching programming "as a part of CS" is still fairly heated. The majority of subscribers are teachers, or university-based specialists in Education/CS. A few, such as myself, are externals with a deep interest (in my case, to promote Sound and Music Computing in schools*). There are apparently many in the schools ICT community who see no point or need to teach programming, and regard it more or less as an unknowing and interfering government diktat. There is a thread on CAS discussing this now. There are a few general aspects to note with respect to introducing any new element into the curriculum. School networks are typically locked down very solidly, so neither students nor teachers can arbitrarily install anything. Often, there is no permitted access to a command line. Exam boards specify a certain set of allowed languages for exams; these include Java, Pascal, Python, and Visual Basic, and these can all be assumed to be available on school machines. The scripting languages are especially popular as they don't involve anyone running a newly compiled binary which might be a risk. Other languages can be taught in-class of course, so long as the above restrictions are met or, hopefully, overcome. The Raspberry Pi is also widely discussed, the main problem of course simply being getting hold of them in enough numbers to base a class on. There has been essentially no discussion of the topic of concurrency, certainly no suggestion it might be a critical component of contemporary CS. The graphic-based language Scratch*** from MIT (targetted at primary level upwards), intended very much to be a child's first experience of computing, includes a very rudimentary form of concurrency via a "broadcast" block, which sends a parameterless message that can be received by any number of others. I can use this to play a chord, where otherwise there is just one command block to play one note for a given duration. However, there is no synchronisation mechanism other than a somewhat free-running timer block (which I have yet to test properly with a music project). Moving the Scratch window is sufficient to suspend processing. Suffice it to say, timing-critical tasks such as polyphonic music performance can easily run out of sync. The current version of Scratch is 1.4, written in Smalltalk. A "Scratch 2.0" is apparently in an advanced stage of development, and will apparently be based on Flash. There is a widely used derivative of Scratch called BYOB ("Build Your Own Blocks")**** which supports more advanced idioms including recursion. I get the impression that it has far less penetration in schools than Scratch. Richard Dobson * http://people.bath.ac.uk/masrwd/** http://community.computingatschool.org.uk/door*** http://scratch.mit.edu/**** http://byob.berkeley.edu/On 01/10/2012 10:45, Ian East wrote: ..
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.
I don't agree. First, kids are smart, often too smart. They'll happily
accept something ridiculous. What they don't do is reflect, especially
when they're smart. Give them C or (worse) Java and you'll /never/ get
it away from them again.
If it's simple enough for kids to learn, even when they're /not/ smart,
it'll then be safe in the hands of engineers. If it challenges even the
most able engineers, as concurrency does when attempted with C++. C#
/etc./ then I for one will not board that aeroplane. (It's rather like
energy. If it works in the 3rd world then it's probably sustainable,
and thus what /we/ should use too.)
I believe /transparency/ is king.
The answer to building on what pros need is surely to add layers of
abstraction, not to clutter up even the most simple programs with crap.
(I well recall how someone thankfully kept Java out of Year 1 by
pointing just what you had to do just to define a constant.)
Ian East Open Channel Publishing Ltd. (Reg. in England, Company Number 6818450)
|