Scratch, Nov 2009

Digital Natives können Lesen, aber nicht Schreiben

17 November 2009 | Beat Döbeli Honegger | Scratch
In der Novemberausgabe der Communications of the ACM ist die Programmiersprache Scratch (Biblionetz:w02030) Titelthema. Unter dem Titel Scratch: Programming for All (Biblionetz:t09978) erläutern die Entwicklerinnen und Entwickler von Scratch die Ziele und Kernüberlegungen, die hinter der Programmierumgebung für Kinder und Jugendliche stecken.

Der Artikel betont die Bedeutung des Programmieren-Könnens für das Verständnis und Gestaltungsmöglichkeit in einer digitalen Welt. Diese Idee ist keineswegs neu, aber der Artikel enthält einige sehr schöne Aussagen in prägnanter Form, die sich wunderbar als Zitate eignen:

It has become commonplace to refer to young people as "digital natives" due to their apparent fluency with digital technologies. Indeed, many young people are very comfortable sending text messages, playing online games, and browsing the Web. But does that really make them fluent with new technologies? Though they interact with digital media all the time, few are able to create their own games, animations, or simulations. It's as if they can "read" but not "write."

Sogenannte digital natives (Biblionetz:w01839) sind also aus Sicht des Scratch-Entwicklungsteams trotz eventuell vorhandener Web 2.0 Virtuosität eigentlich passiv Konsumierende: Sie nutzen nur bestehende Programme und Services, statt diese selbst (weiter) zu entwickeln.

Das Scratch-Team sieht deshalb Programmierkenntnisse (Biblionetz:f00114) als notwendigen Teil einer digital fluency :

As we see it, digital fluency requires not just the ability to chat, browse, and interact but also the ability to design, create, and invent with new media, as BalaBethany did in her projects. To do so, you need to learn some type of programming. The ability to program provides important benefits. For example, it greatly expands the range of what you can create (and how you can express yourself) with the computer. It also expands the range of what you can learn. In particular, programming supports "computational thinking," helping you learn important problem-solving and design strategies (such as modularization and iterative design) that carry over to nonprogramming domains. And since programming involves the creation of external representations of your problem-solving processes, programming provides you with opportunities to reflect on your own thinking, even to think about thinking itself.
Neben Designprinzipien und Grundsatzüberlegungen bietet der Artikel auch Zukunftsaussichten. Wohin soll Scratch gehen?

We plan to keep our primary focus on lowering the floor and widening the walls, not raising the ceiling.

[...]

As we develop future versions, our goal is to make Scratch even more tinkerable, meaningful, and social. With our Scratch Sensor Board (http://info.scratch.mit.edu/Sensor_Boards External Link), people can create Scratch projects that sense and react to events in the physical world. We are also developing a version of Scratch that runs on mobile devices and a Web-based version that enables people to access online data and program online activities.

Cool: Ein Scratch auf mobilen Geräten und ein Scratch, das im Internet Daten austauschen kann. Sozusagen Scratch für mobile learning und Scratch für Web 2.0.

Das Scratch-Entwickler-Team sieht die Herausforderung weniger bei der Technik, sondern eher im Bereich Bildung und Gesellschaft:

Probably the biggest challenges for Scratch are not technological but cultural and educational.10 Scratch has been a success among early adopters, but we need to provide better educational support for it to spread more broadly.

[...]

There needs to be a shift in how people think about programming, and about computers in general. We need to expand the notion of "digital fluency" to include designing and creating, not just browsing and interacting. Only then will initiatives like Scratch have a chance to live up to their full potential.

Lesen! und Los-Scratchen!


Richtig lesen können sie auch nicht... http://www.zeit.de/2009/47/DOS-Analphabeten?page=all -- Main.TorstenOtto - 16 Nov 2009

Scratch-Ableger und Erweiterungen

16 November 2009 | Beat Döbeli Honegger | Scratch
Da ich mich derzeit wieder etwas intensiver mit Scratch beschäftige (jaja, auch wenn man gegen aussen (noch) nichts sieht, wir arbeiten fleissig an http://iLearnIT.ch weiter), bin ich auf ein spannendes Ökosystem rund um Scratch gestossen.

w02030.jpg

Was ich bereits vorher wusste: Scratch (Biblionetz:w02030) baut auf Squeak (Biblionetz:w01597), was wiederum auf einem Smalltalk-Dialekt (Biblionetz:w01332) aufbaut.

Scratch ist Open Source, d.h. der Squeak-Quellecode kann frei heruntergeladen und verändert werden. Das MIT hat aber ein Interesse daran, dass möglichst viele mit der offiziellen Version von Scratch entwickeln, da nur so der Austausch von Programmen via Scratch sichergestellt ist. Entsprechend dürfen Scratch-Ableger weder den den Namen Scratch verwenden noch den Upload auf die Scratch-Community-Website ermöglichen.

Derzeit existieren mindestens folgende Scratch-Ableger:

  • Chirp ist eine auf Scratch 1.2.1 aufbauende Scratch-Weiterentwicklung von Jens Moenig. Sie bietet unter anderem die Möglichkeit, Programme als XML zu exportieren und zu importieren, Scratch-Programme als direkt unter Windows lauffähige EXE-Programme zu speichern, Windows-Screensaver zu programmieren und Programmblöcke per Kontextmenu zu verändern.
  • Mit BYOB (Build Your Own Blocks) bietet Jens Moenig eine weitere Scratch-Erweiterung an, die auf Scratch 1.4 aufbaut. Mit BYOB 2.0 ist es möglich, eigene Programmblöcke zu programmieren, d.h. Scratch wird um Funktionen und Prozeduren erweitert. Zudem ist es möglich, auf das darunter liegende Squeak zuzugreifen, womit sich ungeahnte Möglichkeiten (und Abgründe) auftun:
    byob.jpg

    Als dritte spannende Erweiterung ist die Zusammenarbeit in einem Mesh-Netzwerk möglich, womit Scratchprogramme via Netzwerk miteinander reden können.
  • Streak: Erweiterung von Scratch 1.3.1 vorwiegend um Dinge, die im offiziellen Scratch 1.4 auch eingeführt worden sind (z.B. Frage-Block mit Antwort als Variable). Eine detaillierte Liste der Erweiterungen ist in der Versionsgeschichte zu finden.

Alles in allem spannende Ansätze, welche die Potenziale von Scratch erweitern. Es ist zu hoffen, dass die sich bewährenden Konzepte dieser Scratch-Erweiterungen in spätere, offizielle Scratch-Versionen Einzug halten werden.

Des weiteren taucht regelmässig die Frage nach Scratch auf verschiedenen (mobilen) Plattformen auf: Scratch für Playstation, Scratch für das iPhone, etc. Derzeitiger offizieller und halboffizieller Informationsstand: Aufgrund fehlender Entwicklungsressourcen sind derzeit vom MIT keine entsprechenden Entwicklungen möglich.

Als dritte Erkenntnis habe ich anlässlich meiner Recherche gemerkt, dass Scratch per TCP/IP kommunizieren und so mit anderen Programmen Daten austauschen kann. Unter Scratch Connections sind verschiedene Anleitungen und Beispiele zu finden, wie Scratch z.B. RSS-Feeds verarbeiten kann oder man mit Scratch einen Chat programmieren kann.

Auslöser unserer Recherche war die Frage, ob man in Scratch Variablen einfach umbenennen könne. Dieses Ansinnen taucht auf, wenn man Beispielprogramme auf deutsch und französisch anbieten will: Wie nennen wir die Variablen? Deutsch - dann müssen wir aber für die französische Version nicht nur die Texte, sondern auch das Programm selbst anpassen - in Scratch eine mühsame Handarbeit. Benennen wir die Variablen stattdessen auf englisch, so entfällt dieser Übersetzungsaufwand, dafür sinkt die Verständlichkeit des Programms inbesondere für Primarschüler. Es ist ja einer der Vorteile von Scratch als Programmiersprache für Kinder, dass sich die Sprache der Programmblöcke im laufenden Betrieb ändern lässt, so dass ein mit deutschen Programmierblöcken geschriebenes Programm mit einem Mausklick in Französich oder Türkisch darstellen lässt. Da ist es dann schade, wenn die Variablen englisch sind. Wir sind nicht die einzigen, die auf der Suche nach einer Lösung für dieses Problem sind, aber bisher haben wir keine wirklich effiziente Lösung gefunden.

Sachdienliche Hinweise nehmen wir gerne entgegen... ,