Monday 15 February 2016

Keep it creative to get kids into coding

Keep it creative to get kids into coding

Andrew Manches, University of Edinburgh
A new subject is to be introduced in England to kick start our technological future. Instead of teaching ICT, the national curriculum published this week calls on schools to teach computing.
This new way of looking at information technology in schools embodies a significant shift that is taking place all over the world. There is much to welcome in the move to computing, which addresses widely voiced concerns that children are not learning the skills needed for an increasingly digital world. The intention is to empower children as creators of digital media rather than passive consumers.
Nevertheless, coding needs to be taught in a creative way to keep children interested and introducing it universally into classrooms needs to be approached with care.
As the electronics industry gets more powerful by the day, we have started to think of coding as inherently exciting and creative. Michael Gove had been extoling its virtues for a long time before finally introducing it into the curriculum this week.
Mathematics can also be exciting and creative, yet we know that many children would disagree. Making a robot move or an animation respond certainly can be an exciting experience. But for many, the subsequent steps of writing and debugging programs can be less so. We currently have a “self selection” bias: many of the children learning to code out of school have chosen to do so. Maintaining this excitement for all children as coding is translated to a compulsory curriculum subject will be a challenge. This is particularly pertinent when we consider how coding will be assessed. It is no secret that assessment procedures have diminished the potential for subjects such as maths to excite pupils.
Ultimately, the greatest influence in how children experience coding will be teachers. Being able to integrate coding creatively into the classroom will require confidence and a certain amount of subject knowledge. Yet it is not clear what support is on offer, particularly with the aim of introducing this curriculum in 2014. Whilst there are an increasing number of impressive learning tools such as Scratch, even these could lose their excitement if presented in a formulaic step-by-step style. It would be nice to see more creative solutions for how to support teachers with this major curriculum development, for example, drawing on the skills of older children.
With the emphasis on change, there also seems to be a lack of reflection on educational and research debates around programming from the past. For more than 30 years we have had tools such as Logo which offer children an accessible, creative, environment to program instructions to an onscreen (and floor) robot. One of the questions raised was the extent to which children’s learning generalised to other areas – such as mathematics. This concern is highly relevant when considering the various claims we currently hear for programming. Who would not want to develop children’s logical reasoning, communication, thinking skills, literacy, or creativity? Yet there remains limited evidence that these broader abilities are developed through learning to code.
It would be interesting, therefore, to see how coding is related to other subject areas: research has looked at the link to structuring a story for example. This is particularly important because we don’t yet know how the programming skills to be taught in schools will actually be used by children in their future lives and careers. Indeed, an increasing number of tools, such as web creation packages, are available that allow us to be digitally creative without needing to know how to code. Coding, of course, does offer a powerful way to re-engineer these tools, yet we should continuously evaluate the need for this to be a universally taught skill. Here I draw on my own experience creating a digital product. It was important to understand the principles of coding, and the ability to communicate effectively with coders, but in truth, I am still pushed to create the simplest “hello world” program.
My greatest concern is that the wrong curriculum approach to coding could minimise its most appealing feature. Children are increasingly immersed in a programmed environment: from audio books and games to streetlights, taps and automatic doors. What is exciting is understanding how these digital artefacts have been designed to respond to the actions of those that use them. And what is empowering is the confidence to think about how these artefacts can be re-designed and told to respond differently to different actions. Computing as a subject has great potential to give children the understanding and confidence to think of changing the world around them from their earliest years. But this means that programming has to be meaningful. What a shame if this opportunity is lost through too great a focus on learning the procedural building blocks.
The Conversation
Andrew Manches is ESRC Future Research Leader Fellow at University of Edinburgh.
This article was originally published on The Conversation. Read the original article.

Thursday 11 February 2016

Changing ATTR with DOIF

Altering ATTR with a DOIF command can be a very powerful way of governing that object's abilities when it is in the world.  The trouble is that there are so many different ways they can be combined that it is difficult to see what's going on!   The medlar uses changes in ATTR to make sure that creatures can't pick an unripe fruit, and that ripe fruit fall off the patch and allow new ones to grow. 

All the time, the BHVR is 48 - edible and pickupable, so it is only the ATTR that will change and govern how creatures interact with it - you can't mess with it if you can't see it.  It also has various physics properties at installation, which will be obeyed when the ATTR says they will.

When it is installed, the ATTR for the medlar is 80. It is invisible, and will collide with room boundaries.

80:

Invisible: Creatures don't see you - applies to ESEE and STAR on creatures, as well as internal creature code.
Suffer Collisions: Will collide with room boundaries, according to its PERM.


When the medlar achieves its ripened state by stepping through its poses, the ATTR is changed to 67.  It is visible, carryable, can be picked up by the mouse, and will collide with room boundaries. 

            doif attr eq 80
               attr 67
            endi


67:

Carryable: Can be picked up by things other than creatures, vehicles and the pointer.
Mouseable: Can be picked up by the mouse.
Suffer Collisions: Will collide with room boundaries, according to its PERM.


If it is picked (either by hand or creature), its ATTR changes to include suffering physics - being able to drop.  It will also automatically change to this, and drop, if it has been hanging around, ripe on the tree for a long time.
 
195:

Carryable: Can be picked up by things other than creatures, vehicles and the pointer.
Mouseable: Can be picked up by the mouse.
Suffer Collisions: Will collide with room boundaries, according to its PERM.
Suffer Physics: Agent falls with proper physics, including gravity, air resistance and friction. Otherwise, it simply moves with velocity.
 


   doif attr eq 67
      attr 195
   endi

 

The full coding of the medlar can be seen at Garden Box Central.