Note for my English readers: You will find an English version of this blog post under Visual Programming with Scratch – not only for kids!
Vorbemerkung: Dies ist die ungekürzte Fassung meines Beitrags zum Buch Scratch Tales. Celebrating 10 Years of Imagining, Prgramming and Sharing with Scratch.
Als Scratch vor 10 Jahren erschien, war dies der Auslöser für ein bemerkenswertes Comeback der Programmiersprache Logo. Dieser Ansatz zur Programmierung mit grafischen Elementen fand schnell mehrere Nachahmer und Ableger mit Turtle Art, Blockly, Snap! – um nur ein paar zu nennen. Es ist weithin anerkannt, dass Scratch eine geeignete Programmierumgebung für (auch kleine) Kinder ist. Auf der anderen Seite wird diskutiert, ob Blocksprachen ernst genommen werden können, denn sie sehen eher wie ein Kinderspiel aus als wie eine Programmiersprache. Es wird oft argumentiert, dass nach einem Einstieg mit Scratch ein Übergang zu „richtigen“ Programmiersprachen, und als solche werden textbasierte Programmiersprachen verstanden, notwendig ist. Ich kann diese Meinung nicht teilen …
Zur Einordnung meines Standpunktes muss ich voraus schicken: Ich bin kein Informatiker und kein ausgebildeter Programmierer und ich bin kein Lehrer. Ich bin ein pensionierter Bildungs-Technologe mit einem wachsenden Interesse an der Programmierung von Projekten in verschiedenen Bereichen, wie Computer-Kunst, Simulationen und der Visualisierung von mathematischen Phänomenen. Das sind zwar alles keine großen, aber durchaus anspruchsvolle kleine Projekte.
Gleich zu Beginn meiner beruflichen Laufbahn hatte ich die Gelegenheit, die Sprache Logo sowie Paperts Ansatz des Konstruktionismus kennen zu lernen. Die Auseinandersetzung mit seiner Theorie sowie die Anwendung der Sprache Logo in Projekten der Lehrerausbildung hatte einen starken Einfluss auf meine weiteren Aktivitäten.
Beruflich war es für mich jedenfalls bei mehreren Gelegenheiten notwendig, computergestützte Projekte zu leiten oder sogar Teile selbst zu programmieren. So war es für mich unvermeidlich, mir grundlegende Programmierungskonzepte anzueignen und sie mit zu diesem Zeitpunkt aktuellen Programmiersprachen umzusetzen (von FORTRAN, BASIC bis Pascal). Es ist in diesem Zusammenhang auch anzumerken, dass ich insbesondere grafisch interaktive Problemlösewerkzeuge entwickelt habe (z.B. KOMPART für pharmakokinetische Kompartmentsysteme; GRIPS und MODUS zur Modellierung dynamischer Systeme). Diese Tools ermöglichten es Studenten (und professionellen Anwendern), dynamische Systeme ohne mathematische und programmiertechnische Barrieren zu modellieren und zu simulieren.
Dieser Ansatz basiert auf einer Tradition in den angewandten Wissenschaften. Es ist vielleicht kein Zufall, dass die visuelle Programmierung in Bereichen, in denen interdisziplinäre Kooperation üblich ist, besonders weit verbreitet ist und die Kommunikation über die Grenzen des Themas hinaus durch entsprechende Visualisierungen erfolgt. Beispiele sind LabView (Messtechnik), Vensim und iThink (Modellierung von dynamischen Systemen) oder iMODELER (Projektmanagement).
Der übliche Einstieg in die Programmierung mit textbasierten Programmiersprachen ist dagegen mit hohen Hürden verbunden – nicht nur für Kinder. Das gilt selbst bei einer bildungsorientierten Sprache wie Logo und um wie viel mehr in Produktionssystemen wie Java oder Python. Alle Anfänger müssen viele verschiedene Dinge gleichzeitig lernen: Syntax und Semantik der Befehle, die Formulierung von Algorithmen, den Umgang mit der Entwicklungsumgebung und dem Editor, den Umgang mit Fehlern und mehr. Am Anfang sollten aber eigentlich die Konzepte der Programmierung im Vordergrund stehen. Professionelle Entwicklungsumgebungen verstellen oft den Blick auf das Wesentliche. Diese Hürde kann mit visuellen Programmierumgebungen deutlich reduziert werden.
Es gibt einige Studien (siehe z. B. Weintrop & Wilensky, 2017, Price & Barnes, 2015), die zeigen, dass die visuelle Programmierung den Einstieg in das Programmieren besonders für Anfänger mit wenig Vorkenntnissen erleichtert. Auch wenn visuelle Programmiersprachen oft nur als Vorläufer der „echten“ Programmierung akzeptiert werden (siehe z. B. Dorling & White, 2015), ist es doch zweifelhaft, ob die Mehrheit der an der Programmierung interessierten Personen die „richtigen“ Sprachen für die Entwicklung ihrer Anwendungen überhaupt braucht (Modrow, 2013). Eine Einschränkung von visuellen Sprachen kann darin gesehen werden, dass die grafische Implementierung komplexer Algorithmen mit vielen Symbolen schnell eine räumliche Grenze erreichen kann. Das wird auch als Deutschgrenze bezeichnet nach dem Informatiker L. Peter Deutsch: Mehr als 50 visuelle Elemente auf dem Bildschirm sind schwer zu verstehen. Glücklicherweise stehen in Scratch et al. strukturierende Elemente zur Verfügung, um Befehlsfolgen zusammenzufassen und so ein potentielles Raumproblem zu vermeiden oder deutlich zu lindern.
Jedenfalls entdeckte ich nach meinem Ruhestand wieder meine Liebe zur Kunst und zur Programmierung. Und mit Scratch (und seinen Abkömmlingen) habe ich die Werkzeuge gefunden, die mir den unproblematischen Wiedereinstieg erlaubten und die Nutzung meiner bisherigen Erfahrungen in der Entwicklung von Lernumgebungen. Für meine eigenen Anwendungsfelder (Computerkunst, Visualisierungen, Simulationen) sehe ich auf jeden Fall keine zwingende Notwendigkeit, andere Werkzeuge zu benutzen.
Mittlerweile bin ich engagiert, älteren Leuten (60+, so genannte Silver Surfer) zu helfen, Zugang zum Computer und zum Internet zu bekommen. Einige von ihnen sind sogar daran interessiert, Programmieren zu lernen, häufig einfach als intellektuelle Herausforderung oder um an aktuellen Entwicklungen teilzunehmen und ihre Rolle als reine Verbraucher zu überwinden. Ich habe gelernt, dass es in diesem Fall besonders wichtig ist, einem lernerzentrierten Design zu folgen und motivierende Themen aufzugreifen. Geeignete Ausgangspunkte sind individuelle Hobby-Projektideen (wie in meinem Fall die ComputerKunst) und diese zu implementieren.
Ein solcher Ansatz bildet ein Gegengewicht zu üblichen Einführungen zur Programmierung, die oft an einem Mangel an adressatenspezifischer Sprache und Beispielen leiden. Die Verwendung Visueller Programmierung mit Scratch ist bestens geeignet, Frustrationen mit Software-Installationen und Konfigurationen und Fehleranalysen zu vermeiden (siehe Guo, 2017). Für meine Adressaten ist es besonders wichtig, dass sie sich auf die Entwicklung der Algorithmen konzentrieren können.
Meine Erfahrung und meine Schlussfolgerung ist also, dass Scratch nicht nur für Kinder geeignet ist, sondern auch für Adressaten am anderen Ende der Alterspyramide! Ich bin neugierig, was die Entwicklung von Scratch et al. uns in den nächsten 10 Jahren in dieser Hinsicht noch bringen wird.