Many teachers in the UK have had to retrain from ICT teachers to Computing teachers. This has involved trying to learn a programming language and so they have experienced at first hand what students have to go through themselves. In this "opener for discussion" Chris Roffey makes the case for taking another look at the programming environments we ask our students and pupils to use when learning programming. Perhaps a rethink is necessary? Follow the discussion on this article here: https://community.
Programmers know the frustration of writing code in a familiar and frustrating loop:
WHILE I get a compile error:
search for bug
fix a bug
compile program again
Programmers tell us, and new computing teachers have learnt, that an important skill in learning Computer Science is resilience, the fifth R (I lose count these days). Many teachers proudly pronounce that one of things students will learn when studying Computer Science is resilience!
Is it so surprising that so many students do not choose to take up Computer Science at GCSE?
Perhaps we should be selling the subject as being creative and fun. Perhaps programming should not require so much resilience. Perhaps we have fallen into the trap of believing that the only way to write real programs is by using a professional IDE in a darkened room with lots of unforgiving text and rude error messages. Perhaps the tools we are using ourselves and imposing on students are not fit for purpose?
Whenever there is a discussion on CAS about which language is the most appropriate to teach students, at some point Michael Kölling will intercede that it is not the language we should be worrying about but the environment. Michael has a lot of experience teaching programming and has, along with others, produced such an environment for teaching Java (Greenfoot). It is a fantastic tool! Michael and his team have now gone a step further and produced a more helpful way of writing programs in Java which goes a long way to reducing syntax errors and some of the frustration learning programmers meet. This has been done by developing a new language, based on Java, called Stride.
As much as a fan of Greenfoot as I am, I do not think it goes far enough. There is still a lot of resilience required by students. It presupposes that students have to always program in a text editor and provides support on their transition towards this aim. It also requires students to be taught Java from an Objects first paradigm. This is Michael's preferred approach but might not be right for everyone.
Now, the next bit of this short discussion item is going to raise the shackles of many professional developers in CAS. I am going to suggest we can do things much better. That they have been doing things wrong all their working lives and that a text editor is only one tool that should be in their IDE and it should be the tool of last resort. I am proposing that now is the time, in the UK, that we should develop one IDE for all secondary schools. This would be a similar decision to that which France have made - that all schools should teach only Python. However, I am neither suggesting that we should be deciding on Python, Java or any language at this stage. I think we should build a tool that all secondary school students are taught and that it should built with the assumption that students coming from Junior schools have experienced Scratch and should build on that assumption. It should have a similar disruptive influence to that of Scratch.
I have been a programmer for a long time now. I have also used a lot of visual tools to write interactive web apps and generally ended up foregoing their WYSIWYG fancy bits and hard coded in text! This was because it gave me the control of the code I needed, that the fact that the code that the visual editors wrote was often di?cult to understand at best and clumsy and bloated at worst. This is not an uncommon experience and often touted as a matter of pride: "I always hand code in a text editor as the other tools are crud!". I think this is not only the reason that many developers will not like what I am suggesting but it is also the reason that most professional IDEs have got stuck in a cul de sac.
I hope that this short discussion document is just an opener. We should be able to produce tools for students that do not require them to be amazingly resilient, tools that write neat, efficient, readable code that the students can understand and edit (when that is the most appropriate way of doing things). Just because tools developed for designers in the past have not produced great code does not mean that we cannot do it, if that is a fundamental aim of what needs to be developed. First we decompose the problem, then we …
Here is a great video explaining why we need to do better. It is also quite amusing:
