Hinweis: Eine deutsche Fassung dieses Berichts findet sich auf meinem konzeptblog.

Preliminary remark: This is the unabridged version of my contribution to the book Scratch Tales. Celebrating 10 Years of Imagining, Prgramming and Sharing with Scratch.

When Scratch appeared 10 years ago, this was the trigger for a remarkable comeback of the programming language Logo. This approach to programming with graphical elements quickly found several imitators and offshoots with Turtle Art, Blockly, Snap! – to name a few. It is widely recognized that Scratch is an appropriate programming environment for (even small) children. On the other hand it is still being discussed, if block languages can be taken seriously because they look more like a child’s game than a programming language. It is often argued that, after an entry with Scratch, a transition to correct programming languages, i.e. text-based programming languages, is necessary. I can not share this opinion …

To the classification of my standpoint I have to say first: I am not a computer scientist nor a trained programmer and I am not a teacher. I’m just a retired educational technologist, now with a growing interest in programming projects in various areas, like computer art, simulations, and the visualization of mathematical phenomena. These are admittedly not large projects, but nevertheless quite demanding small projects.

Right at the beginning of my professional career I had the opportunity to get to know the language Logo as well as Papert’s approach to constructionism. The involvement with his theory as well as the application of the language Logo in projects of teacher training had quite some influence on my further activities.

Occupationally I had anyhow the necessity on several occasions to lead computer-based projects or even to program parts of them myself. So it was inevitable for me to adopt basic concepts of programming and apply them with at that time current programming languages (ranging from FORTRAN, BASIC to Pascal) – and it is remarkable in this context, that I have developed especially graphic interactive problem-solving tools (e.g. KOMPART for Pharmacokinetic Compartmental systems; GRIPS, MODUS for modeling dynamic systems). These tools enabled students (and professional users) to model and simulate dynamic systems, avoiding barriers in mathematics and in terms of programming. This approach is based on a tradition in applied sciences. It is perhaps no coincidence that Visual Programming has been particularly widespread in areas where interdisciplinary cooperation is being carried out and communication is crossed beyond the boundaries of the subject through appropriate visualizations. Examples are LabView (measurement technology), Vensim and iThink (modeling of dynamic systems) or iMODELER (project management).

The usual entry into programming with text-based programming languages, on the other hand, is associated with high hurdles – not only for children. This is true even with an education-oriented language such as Logo and how much more in production systems like Java or Python. All beginners have to learn at the same time many different things: syntax and semantics of the commands, formulation of algorithms, dealing with the development environment and the editor, dealing with errors and more. In the beginning, however, the concepts of programming should be at the forefront. Professional development environments often disguise the view of the essentials. This hurdle can be significantly reduced with visual programming environments.

There are now some studies (see e.g. Weintrop & Wilensky, 2017, Price & Barnes, 2015)) which show that visual programming makes entry-level programming easy for beginners with little prior knowledge. Even if visual programming languages ​​are often only accepted as a precursor of „real“ programming ​​(see, for example, Dorling & White, 2015) it is doubtful whether the majority of people interested in programming need the „right“ languages ​​at all for the development also of their applications (Modrow, 2013). A restriction of visual languages can be seen in the fact, that the graphic implementation of complex algorithms with many symbols can quickly reach a spatial limit. This is sometimes called the Deutsch limit, according to the computer scientist L. Peter Deutsch: More than 50 visual elements on the screen are difficult to comprehend. Fortunately, in Scratch et al. structuring elements are available in order to summarize command sequences, thus avoiding or significantly alleviating a potential space problem.

Anyway, after my retirement I rediscovered my love for art and programming. And with Scratch (and its descendants) I’ve found the tools, which allowed me the unproblematic re-entry, then even taking up my previous experiences in the development of learning environments. For my own application fields (computer art, visualizations, simulations) I see in any case no compelling need to use other tools.

Meanwhile I am committed to helping older people (60+, so-called Silver Surfer) to get access to the computer and the internet. Some of them are even interested to learn programming, frequently to keep their brains challenged, or simply to participate in current developments and to overcome their role as pure consumers. I have learned that especially in this case it is imperative to follow a learner-centered design, and to offer motivating issues. The best common starting point is for that to implement a specific hobby project idea (as in my case computer art).

With such an approach, a counterbalance can be created to common introductions to programming, which often suffer a lack of addressee-specific language and examples. The use of Visual Programming with Scratch is best for avoiding many frustrations with software installation and configuration, debugging syntax and run-time errors (see Guo, 2017). For my addressees it is especially important that they can concentrate on the development of the algorithms.

My experience and my conclusion is therefore that Scratch is not only suitable for children, but also for addressees at the other end of the age pyramid! I’m curious what the development of Scratch et al. will offer us in this regard in the next 10 years.