Aus Das deutschsprachige Scratch-Wiki

Dieser Artikel ist veraltet, bleibt aber aus geschichtlichen Gründen bestehen.
Es gibt (noch) keinen aktuellen Artikel.

Die Entwicklungsumgebung von Scratch 1.4 und früher wurde mit Squeak hergestellt. Die Laufzeitumgebung für Scratch-Programme ist entweder der Online Player, der die Projekte im Webbrowser ausführt und auf Java bzw. Flash (nur für angemeldete User) basiert, oder alternativ die Scratch-Entwicklungsumgebung selber. In dieser Scratch-Entwicklungsumgebung (der Einfachheit halber im Folgenden als "Scratch" bezeichnet) werden die Scratch-Programme entwickelt, getestet und ausgeführt.

Was ist Squeak?

SqueakWikipedia.jpg ist eine Open-Source-Implementierung der Programmiersprache Smalltalk samt der für diese Sprache üblichen Entwicklungsumgebung. Vereinfacht kann man sagen: Squeak ist das für Smalltalk, was Linux für UNIX ist. Smalltalk ist eine objektorientierte Sprache, dynamisch typisiert, mit einer minimalen Syntax, die in fünfzehn Minuten gelernt werden kann. Ein wesentlicher Vorteil der Smalltalk-Sprache ist ihre Kohärenz:[1]

  • Alles ist ein Objekt: Klassen, Methoden, Zahlen, etc.
  • Es existieren nur eine sehr sehr kleine Anzahl von Syntaxregeln und keine Ausnahmen.
  • Smalltalk läuft auf einer virtuellen Maschine. Die Entwicklung erfolgt in einem Image, in dem alle Objekte “leben" und modifiziert werden können.

Welche Eigenschaften bezieht Scratch von Squeak?

Viele der faszinierenden Eigenschaften von Scratch sind auf diesen Squeak-Hintergrund zurückzuführen. Beispiele:

  • die Multimedia-Elemente von Scratch sind typische Squeak Eigenschaften
  • die Eigenschaft, dass während der Laufzeit von Scratch-Programmen parallel am Programm selber weiterentwickelt werden kann (das ist Smalltalk-typisch: zwischen Laufzeit, Entwicklungs- und Debuggingzeit gibt es keinen "Systembruch" es ist quasi alles das Gleiche)
  • die Eigenschaft, dass Scratch im Prinzip nicht nur auf Windows und Mac sondern vielen anderen Plattformen wie Linux, mobile Betriebssysteme oder Wii läuft (überall wo Squeak läuft und Squeak läuft quasi überall, denn die virtuelle Maschine ist selber im Squeak-Image enthalten und Squeak benötigt extrem wenig Betriebssystemfunktionen wodurch eine Portierung von Squeak mit minimalem Aufwand möglich ist)

Wie kommt man von Scratch nach Squeak?

so geht's seit Scratch 1.3:

Mit gedrückter Shift-Taste in das Scratch „R“ oben links klicken, dann kommt man im „Squeak-Image“ an, aus dem die Scratch-Entwicklungsumgebung besteht.

Eine Eigenart von Smalltalk-Programmen ist es, dass das Image, in dem eine Anwendung (wie hier Scratch) entwickelt wird, alle Objekte enthält und eine "publizierte Version" eines solchen Smalltalk-Programms einfach nur eine bestimmte "eingefrorene" Version eines solchen Images ist. Programmieren in Smalltalk bedeutetet also eigentlich: "Modellieren am Image" bis die gewünschte Anwendung entsteht. Aller Variablenzustände beim Anwendungsstart sind Bestandteile des Images. Ein Smalltalk-Image ist also der vollständige Objektspeicher, der beim Start von der Festplatte von der virtuellen Maschine geladen und ausgeführt wird. Häufig wird das Image vor der Auslieferung einer Anwendung "gestript", d.h. es werden Objekte entfernt, die zur Ausführung der publizierten Anwendung nicht mehr benötigt werden, was bei Scratch jedoch nicht vollständig erfolgte. Dadurch enthält das Scratch-Image viele - nicht mehr zu seiner Ausführung benötigte - Objekte wie z.B. die gesamte Smalltalk-Entwicklungsumgebung, zu der es allerdings eigentlich in Scratch keinen Zugang gibt, da alle Einsprungmöglichkeiten von den Scratch-Entwicklern verschlossen wurden. Wie Jens mit seinem Projekt Source sehr anschaulich gezeigt hat, wurde aber zumindest bei Scratch 1.1. eine Einsprungmöglichkeit übersehen, wodurch man von Scratch nach Squeak kommen kann. Es ist problemlos möglich (wie Jens zeigt), Scratch als ein Unterfenster in Squeak auszuführen und aus Squeak auf alle Scratch-Objekte zuzugreifen, denn es sind im Grunde alles Smalltalk-Objekte.

Wie "läuft" Scratch auf Squeak?

Scratch ist ein solches "Smalltalk-Image" (Datei: Scratch.image ), ein Objektnetz, das auf einer virtuellen Maschine (bei Scratch für Windows ist dies die "Scratch.exe" - Datei) ausgeführt wird. Scratch läuft also auf einer mit Squeak gebauten "virtuellen Maschine", die ihrerseits ein Smalltalk Image ist (Scratch.image), das von der virtuellen Maschine ausgeführt wird (scratch.exe), auf der Squeak basiert und die ihrerseits auf dem "Gastgeber-Betriebssystem" läuft.

Wann wird der Scratch Quellcode veröffentlicht?

Ergänzung 2/2011 Die Info in diesem Abschnitt ist veraltet.Inzwischen ist der Scratch-Quellcode längst veröffentlicht und es gibt eine Menge interessante Projekte, die darauf basierend. Unter anderem das, Scratch zu einer vollwertigeren Programmiersprache weiterzuentwickeln wie BOYB von Jens Mönig und Brian Harvey und viele weitere Modifikationen

Zu einem vollständigen Squeak-System gehört noch eine Datei, die bei Scratch bisher nicht mitgeliefert wird: Die "Quellcode-Datei", die zum Betrieb von Scratch nicht benötigt wird. Das heißt aber nicht, dass man den Quellcode nicht lesen kann wenn man Jens Rezept (s.o.) anwendet: Squeak nutzt - wenn die source-Datei fehlt - einfach den Bytecode des Images und zeigt diesen "decompiliert" an, was schon recht lesbar ist. Nur: Es fehlen hilfreiche Informationen wie Variablennamen und Kommentare. Ein Smalltalk-Image hängt mit der Sourcecode-Datei immer so zusammen, dass jede (Methoden- oder Objekt-) Definition referenziert wird, so dass ihr Quelltext im sog. "Smalltalk-Browser" (dem Standardeditor in Smalltalk-Systemen) angezeigt wird. Natürlich kann der Quellcode einer Squeak-Anwendung wie Scratch auch auf andere Art publiziert werden als durch Weitergabe der kompletten Image- und Sourcedatei: Zum Beispiel enthält die sog. "Changeset"-Datei einer Anwendung alle Objektdefinitionen , die zum "Ummodelieren" einer Squeak-Installation (z.B. die aktuelle Basisversion) in eine Installation, welche die Anwendung enthält, notwendig sind. Mit einem Scratch-Changeset könnte man also Scratch in jede kompatible Squeak-Installation hinein holen und es dort mit anderen Squeak-Anwendungen kombinieren.

Die Publikation des Scratch-Quellcodes ist schon lange angekündigt (siehe {{{2}}}) und aus Squeak-Lizenzrechtlichen Gründen wohl auch Pflicht. Auf Nachfrage schrieb John Maloney:

Zitat John Maloney at 08.11.2007
Hi, Martin.

Good to hear from you!

Yes, we do plan to make the source code for Scratch available by the end of this year. It will be released a few weeks after the official Scratch 1.2 release. (Scratch 1.2 is in beta now, scheduled for final release on December 1st.)

Although we will be making the source code available, Scratch is not becoming a community development effort. The Lifelong Kindergarden group at MIT will continue to develop and support Scratch. While we welcome feedback and suggestions, we do not seek code contributions.

The license agreement for using the Scratch source code will include several restrictions, including (a) that you do not use the word "Scratch" to refer to derived works, (b) that you do not use the Scratch logo or the Scratch cat in derived works, (c) that you do not implement or enable the ability to upload projects to the MIT Scratch website, and (d) that derived works retain the Scratch copyright notice and license. The purpose of these restrictions is to avoid potential confusion in our user community between the official version of Scratch, supported by the Lifelong Kindergarten group, and experimental variations. In short, we are happy the share our source code, but we want to protect the Scratch brand and user community.

I hope you and other Squeakers will appreciate the reasons for these restrictions and that they will not prevent you from doing great and wonderful things with the Scratch code base.

John

Warum ist Smalltalk so einfach, aber hat den Ruf schwierig zu sein?

Smalltalk ist - an sich - eine sehr einfach zu lernende und zugleich mächtige Programmiersprache. Nur: Wer traditionelle imperative Programmiersprachen kennt (Wie BASIC, C oder PASCAL), dem hilft dies kaum (oder schadet vielleicht eher) Smalltalk zu verstehen, denn es ist konsequenter objektorientiert als jede andere Programmiersprache. C++, Java, Visual Basic ... o.Ä. und auch Scratch enthalten ebenfalls Objektorientierung, machen aber viele Ausnahmen für traditionelle imperative Strukturen und/oder die Performance auf aktuellen Hardwareplattformen. Dadurch erreichen sie, dass sich der traditionelle Programmierer "wohl fühlt" aber die Gefahr besteht, dass er das Wesen und die Chancen der Objektorientierung nicht vollständig erfasst. Smalltalk kennt keine solche Ausnahme: Jeder Dateneinheit ist ein Objekt (auch z.B. Integerzahlen oder Booleans), jede Operation eine Nachricht deren Implementierung man in der Objektklasse nachlesen kann.

Die Menge der Syntaxregeln von Smalltalk ist verblüffend minimal: Es gibt z.B. nur sechs(!) reservierte Worte: true, false, nil, self, super, und thisContext und einige wenige Notationen, mit denen man Litarale aufschreibt (Literale sind Zeichenketten, die direkt ein Objekt darstellen, z.B. Strings oder Zahlen und insbesondere der "lebende Smalltalk-Anweisungsblock", ein Stück Quellcode, dass durch eckige Klammern zu einem Objekt wird, dass seine Anweisung ausführt, wenn ihm Nachrichten gesendet werden). Der Name "Smalltalk" ist also sehr treffend gewählt, denn es gibt kaum eine andere Programmiersprache, die mit so wenig auskommt (Java und C haben z.B. über 50 "reservierte Worte"). Kontrollstrukturen und Arithmetische Operationen für die es in anderen Programmiersprachen bestimmte reservierte Worte gibt (wie z.B. Bedingungen, Schleifen oder elementare Rechenanweisungen) werden in Smalltalk nicht als Syntaxbestandteil definiert, sondern sind einfach Bibliotheksfunktionen (in Smalltalk "Methoden" genannt), deren Implementierung als sehr verständlicher Smalltalk-Code im Image angeschaut werden kann.

Beispiele:

  • Die "IF-THEN-ELSE"-Struktur ist nicht etwa ein Smalltalk-Befehl sondern eine per Nachricht an die Objekte "True" oder "False" aufrufbare Methode, deren Implementierung man in der Klassendefinition der Objekte "True" und "False" nachlesen kann.
  • Auch "+" (wie auch "*","-", "/" und "=" ...) ist kein "reserviertes Wort" sondern eine nachlesbare Methode von "Zahlenobjekten" die, wenn ihnen die Nachricht "+" mit einem anderen Zahlenobjekt als Argument gesendet wird, mit dem Ergebnis als weiteres Zahlenobjekt antworten.

Smalltalk ist quasi "in Smalltalk geschrieben", was nicht nur heißt (wie bei anderen Sprachen), dass der Compiler von Smalltalk in Smalltalk geschrieben ist. Nein - auch die Dinge, die in anderen Sprachen zum Syntax gehören, sind in Smalltalk geschrieben. Nachdem man (in 15 Minuten :-) die Grundlagen gelernt hat, kann man alles andere prinzipiell autodidaktisch im Image nachlesen. Komplex ist "nur" das riesige Objektnetz, welches dieses Image darstellt, denn es enthält nicht nur das Anwendungsprogramm (hier Scratch) und die Smalltalk-Entwicklungsumgebung, sondern quasi ein vollständiges auf Smalltalk basierendes Betriebssystem.

Gleichzeitig kann man so auch alles in Smalltalk erweitern und umbauen: Von den Ablaufkontrollstrukturen über die Entwicklungsumgebung bis zur graphischen Oberfläche ist alles an die eigenen Bedürfnisse anpassbar. Da der Quellcode sehr gut lesbar ist, und mächtige Werkzeuge für das Navigieren im Objektnetzt zur Verfügung stehen, hat man gute Chancen, die richtige Stelle und notwendige Änderung dafür zu finden, ohne auf weitere Dokumentation zugreifen zu müssen. Smalltalk lernt man am besten durch Lesen im Quellcode des Images, der komplett zur Verfügung steht.

Warum sind Scratch und Squeak so leicht auf verschiedenen Betriebssysteme portierbar?

Das Smalltalk-Image ist quasi ein eigenständiges Betriebssystem. Daraus erklärt sich auch die leichte Übertragbarkeit von Scratch zwischen verschiedenen Betriebssystemen: Squeak spricht mit der sehr kleinen virtuellen Maschine, die das einzige "plattformspezifische" Element ist, nur wenige grundlegende Betriebssystemfunktionen (von Windows, Mac, Linux oder anderen Plattformen) an. Alles andere bringt das Smalltalk-Image von Squeak selber mit: z.B. ein Unterfenster innerhalb des äußeren "Betriebssystemfensters" (und damit also auch ein entsprechendes Scratch-Fenster) ist kein Windows- oder Mac- Fenster sondern ein "Smalltalk-Fenster", das vollständig aus Smalltalk-Objekten besteht.

Ein weitere Aspekt der Portierbarkeit von Squeak ist, dass auch die virtuelle Maschine in Smalltalk geschrieben ist und so auf höchst komfortable Art in Smalltalk weiterentwickelt und debugged werden kann: Dabei simuliert dann das laufende Squeak Image eine virtuelle Maschine in Smalltalk, während es selber auf der echten virtuellen Maschine auf der Hardware/Betriebssystemplattform läuft. Um aus dieser simulierten virtuellen Maschine eine echte, für ein bestimmtes Betriebssystem erzeugen zu können, wurde sie in einer beschränkten Untermenge von Smalltalk geschrieben. Dieses beschränkte Smalltalk heißt "Slang" und kann mit einem Slang->C-Compiler, der ebenfalls Bestandteil des Squeak-Images ist, in C-Quelltext übersetzt werden. Da es für quasi jedes Betriebssystem bzw. Hardware C-Compiler gibt, kann die virtuelle Maschine von Squeak so sehr leicht für jede Plattform verfügbar gemacht werden.

Warum ist Scratch etwas schwerer portierbar als Squeak?

Obige Aussage stimmt leider für Scratch nicht 100%, denn z.B. mit ScratchPlugin.dll (unter Windows) haben die Scratch-Macher (für Squeak Anwendungen untypisch) einige wenige systemspezifische Bibliotheken "eingeschmuggelt" die allerdings nur für einzelne, prinzipiell verzichtbare Funktionen zuständig sind. Diese müssen bei einer Übertragung auf ein anders Betriebssystem "nachgezogen" oder "entfernt" werden. Laut Aussage von Linux-Spezialisten ist das "Weglassen" dieser Funktionen kein Problem und sie können Scratch bereits heute sofort auf Linux nutzen. Dann fehlen angeblich nur "Drag & Drop" ins Scratch-Fenster und einige weniger wichtige Grafikeffekte. An "offiziellen" und uneingeschränkten Versionen für andere Systeme als MS Windows und Mac wird gearbeitet. Dazu auch {{{2}}} (englisch)

Welchen Einfluss hatten die Ideen um Smalltalk auf die IT-Historie?

(ausschnittsweise und subjektiv!)

Smalltalk ist eine sehr fortschrittliche (auch heute noch!) jedoch gleichzeitig eine sehr alte Sprache. Die gängige Spezifikation heißt z.B. Smalltalk80 nach dem Entstehungsjahr. Jahrelang hieß es, Smalltalk sei zu modern und zu konsequent für die jeweils aktuelle IT-Welt, weil keine Rücksicht auf Hardwareanforderungen und traditionelles Programmiersprachen-Knowhow genommen wird.

Ein Ziel eines Ihres wichtigsten Mit-Entwickler, Alan Kay (http://de.wikipedia.org/wiki/Alan_Kay) war es, jedem Menschen und speziell Kindern den einfachen Zugang zur Computertechnologie zu ermöglichen. Zusammen mit Smalltalk wurde die Objektorientierung, die grafische Benutzeroberfläche und die Computermaus sowie das "Laptop" (damals hieß es "Dynabook") erfunden. Leider war das Xerox's Palo Alto Research Center, wo diese Forschung stattfand, nicht in der Lage, daraus schnell marktdurchdringende Technologien zu machen.

Dies übernahmen Steve Jobs, der sich seine Ideen für den Mac-Vorgänger Lisa dort holte und später Bill Gates, der das Kommerzialisieren noch besser beherrschte. Von Steve Jobs gibt es über seinen legendären Besuch im Xerox's Palo Alto Research Center - bei dem er zwar die graphische Benutzeroberfläche und ihre Zukunft erfasste, aber Smalltalk übersah - den Satz: "If I'd only stayed another 20 minutes,...". Immerhin "sponserte" seine Firma Apple einige Jahre später - wie im folgenden auch die Firma Walt Disney - die Entwicklung von Squeak, bevor es ganz an die freie Squeak-Community ging. Inzwischen basieren Apples Macs und iDevices auf der Programmiersprache "Objective-C", die eine sehr an Smalltalk angenäherte C-Variante ist. Weniger nett: Ende 2010 "verbannte" Apple eine Scratch Implementierung aus seinem "App-Store": Es war erstaunlich, dass diese "trojanische Katze" überhaupt in den App-Store schaffte, weil es ja wie Flash und anderer Umgebungen die "Hausmacht" Apples auf seinen iDevices außer Kraft setzte...na ja , Apple hat es nach ein paar Monaten gemerkt und Scratch leider vom iPhone etc. verbannt. 2012 gibt es mit Snap! jedoch eine Scratch-Variat die doch auf iOS - Geräten von Apple läuft: Und zwar indem sie JavaScript nutzt.

Wieso wurde Smalltalk keine Mainstream-Sprache und könnte Squeak das ändern?

Das Original-Smalltalk aus dem XeroX-Parc-Lab war das erste Smalltalk und viele der Squeak-Macher waren schon damals "an Bord". Einige sehen in Squeak ihren zweiten, besseren Wurf, der außerdem durch die OpenSource-Strategie für jeden verfügbar ist, während "ParcPlace-Smalltalk" am Anfang Insiderwissen und später ziemlich teuer war. Mitte der Neunziger wurde Smalltalk als er "heilige Grahl" der Softwareentwicklung gefeiert und neue Versionen und riesige Business-Projekte schossen wie Pilze aus dem Boden. IBM stieg ein und schuf sein VisualAge-Smalltalk. Diese Entwicklung fand Ende der 90er mit dem Durchbruch von Java ihr jähes Ende. Sicher war auch Missmanagement bei ParcPlace einer der Gründe: Während Java im Internet-Hype boomte, schlug man sich bei ParcPlace-Digitalk mit Fusionsproblemen mit dem größten Mitbewerber herum, von denen man sich nie erholte, so dass das Produkt VisualWorks-Smalltalk schließlich nach ettlichen Wirren bei Cincom landete. IBM stieg im Java-Hype um und nutzte VisualAge als geniale Entwicklungsumgebung für Java, die dann später in Java selber neu geschrieben wurde, was die Grundlage von Eclipse wurde. IBM verlor das Interesse an Smalltalk und am Ende landete VisualAge ebenfalls bei Cincom. Die vielen kleinen Smalltalk-Anbieter konnten, nachdem die beiden "BigPlayer" ihre Bedeutung für Smalltalk verloren hatten, keine wirklich große Beachtung finden. Smalltalk wurde wieder zum "Nischenprodukt" für Eingeweihte und die meisten Nutzer anderer Sprachen, die es nur flüchtig kennen, können nicht nachvollziehen was daran so toll sein soll: "Smalltalk is not dead, it just smells funny... :-)". Aber: Smalltalk ist "blumig gesprochen" so ein bisschen wie Jazz: Es hatte seine "große Zeit", gilt als "tot" und beeinflusst dennoch die gesamte Musik die danach kam bis heute: Java, Objective C, Ruby .. die Liste der Programmiersprachen - die Smalltalk-Ideen aufnehmen - ist lang und keine erreicht wirklich die Ideale des Originals. Der "zweite Wurf" - Squeak - könnte jedoch als OpenSource-Projekt langfristig große allgemeine Bekanntheit erlangen: Zur Zeit verläuft die Entwicklung von Squeak-Projekten sehr dynamisch. siehe:

Einen umfangreicheren Abriss der Smalltalk-Historie gibt: http://en.wikipedia.org/wiki/Smalltalk

Warum hat Squeak als "IT-Lehr-Plattform" noch keinen Durchbruch erzielt?

Es gab viele Versuche (z.B. mit "E-Toys" für Squeak) das ursprüngliche Ziel Alan Kays zu verwirklichen. Ein echter Durchbruch in das Massenbildungswesen wurde jedoch bisher noch nicht erreicht, was sich ggf. in nächster Zeit durch die Bereitstellung von Squeak auf dem OLPC (="One Laptop per Child"-Hardware) ändert. Möglicherweise musste aber auch die Komplexität viel weiter heruntergesetzt werden, bis man Kinder und Lehrer ernsthaft im großen Stil an Bord holen konnte. Squeak ist einfach zu weitläufig und unbeschränkt für Anfänger. E-Toys startete ja auch nicht als Forschungsprojekt über kindgerechte Programmierumgebungen (wie Scratch), sondern als kleine Beispielanwendung für Squeak.

Ein Problem bei Squeak war zunächst auch die unzureichende Dokumentation: Smalltalk-Code ist einerseits für erfahrene Smalltalk-Programmierer - bis auf ein par Kommentare - quasi selbstdokumentierend; die Ähnlichkeit zu natürlicher Sprache erscheint wesentlich größer als bei anderen Programmiersprachen, man verwendet intensiv "sprechende" Objekt, Variablen und Methodennamen. Dies ist ggf. der Grund, dass dem Thema "externe Dokumentation" leider aber zu wenig Beachtung geschenkt wurde: Squeak litt zu Beginn an mangelnder Dokumentation für "IT-fernere" Zielgruppen (speziell für Lehrer). Im Verhältnis zum Umfang (der ja beim bewusst "beschränkten" Scratch um Dimensionen geringer ist, als beim "offenen" Squeak) steht auch heute für Scratch viel mehr geeignetes Einsteigermaterial zu Verfügung als für Squeak.

Mit Scratch scheint ein Durchbruch einer "IT-Lern-Plattform" inzwischen eher möglich, wie die schnell wachsenden Anmeldezahlen http://www.scratch.mit.edu zeigen. Allerdings ist der Weg von Scratch nach Squeak weniger "offensichtlich" als von "E-Toys" nach Squeak, womit sich die Frage nach Aufstiegsmöglichkeiten für diejenigen stellt, denen die "Scratch-Welt" zu klein wird.

Könnte Squeak (Smalltalk) die Fortsetzung für Lernende sein, die an die Grenzen von Scratch stoßen?

Scratch ist zwar intuitiv lernbar aber nur "andeutungsweise" objektorientiert und erreicht schnell seine (gewollten) Grenzen. Viele junge Scratcher wollen mehr und fragen vehement nach zusätzlichen Funktionen und Aufhebung von Beschränkungen (häufig ohne sich dessen bewusst zu sein, dass unter der Oberfläche von Scratch bereits das quasi unbeschränkte Squeak "werkelt"). Eine erhebliche Erweiterung von Scratch würde allerdings den leichten Einstieg erschweren, der ja der Hauptaspekt von Scratch ist. Sinnvoller wäre hier vielleicht ein Schritt von Scratch hinauf zu Squeak. Dieser dürfte die jungen Programmierer aber nicht wie ein "Kulturschock" treffen, da sonst die durch Scratch aufgebaute Motivation zerstört würde. Man könnte vielmehr in einer speziellen "Advanced Scratch-Version" von Squeak nach und nach den "Vereinfachungs-Filter" den Scratch darstellt, reduzieren, bis der Blick auf die Smalltalk-Welt völlig freigegeben würde. In so einem "Aufstiegs-Szenario könnten z.B. Scratch-Sprites als durch Smalltalk steuerbare Objekte verwendet werden (wie z.B. die Smalltalk-Roboter in http://smallwiki.unibe.ch/botsinc). Die elementaren Smalltalk-Nachrichten könnten zunächst ebenfalls als farbige Blöcke dargestellt werden , wie in Scratch. Prinzipiell müsste der gesamte Quellcode eine Smalltalk-Images in dieser "Scratch-Block-Metapher" darstellbar sein (analog zum Syntax-Highlighting), nur dass die Anzahl dieser Blöcke eben nicht wie bei Scratch beschränkt ist, sondern selber neue geschaffen werden können) Wenn man so weit ist, könnte man dieses "Scratch-Block-Syntax-Highlighting" wahlweise abschalten und wäre dann bei Smalltalk angekommen.

Warum wäre ein Scratch->Squeak Aufstiegsszenario sinnvoll?

Einige aus der Scratch-Szene meinen, dass Scratch als Programmiersprache ja eigentlich nichts mit Smalltalk zu tun habe, bis auf die mehr oder weniger zufällige Tatsache, dass zu seiner Implementierung Squeak benutzt wurde. Lernende, die mehr wollen, könnten - nachdem sie mit Scratch den Einstieg ins Programmieren gefunden haben - einfach mit einer anderen gängigen Computersprachen z.B. Python oder Java weitermachen. Diese Argumentation ist nicht einfach von der Hand zu weisen. Es gibt aber auch einige Aspekte (neben der Wiederverwendung von Scratch Wissen und einem möglichst fließendem Übergang) die für den Aufstieg zu Squeak und Smalltalk sprechen:

Im Gegensatz zu vielen anderen Programmiersprachen ist Smalltalk konsequent aus der Sicht des Menschen konzipiert und nimmt auf die Bedürfnisse der "Maschine" kaum Rücksicht . Dieses "unausgeschöpfte" Potential ist sicher dafür verantwortlich, dass es sich schon 30 Jahre hält, während andere Programmiersprachen, die stärker an den Kontext ihrer jeweils aktuellen IT-Welt angelehnt sind, gekommen und gegangen sind. Da sich die Maschinen ändern und die Beherrschung von Komplexität (wozu Smalltalk gute Voraussetzungen bietet) häufig wichtiger wird als Performance-Optimierung, werden Sprachen wie Smalltalk wichtiger werden. Auch die Notwendigkeit, Wissen wiederzuverwenden, das aus historisch etablierten Programmiersprachen stammt, nimmt wahrscheinlich ab. Hierzu das geflügelte Wort: "Java ist eine verkrüppeltes Smalltalk für C-Programmierer"  :)". Es könnte sein, dass der Java-Hype, der Ende der 90er Jahre den Durchbruch von Smalltalk verhindert hat, notwendig für dessen Weiterentwicklung war. Die damaligen Schwächen von Smalltalk gegenüber Java wurden inzwischen beseitigt, ohne dass dafür der Syntax von Smalltalk80 nur um ein Zeichen geändert werden musste: Allein das Objektnetz (also die "Basisbibliothek") hat sich verändert, während Java bereits mehrerer ernsthafte Syntaxerweiterungen erfahren hat.

Ein Beispiel für Zukunftspotential: Croquet

Ein Beispiel für das Potential von Squeak Smalltalk ist seine Verwendung als Plattform für ==Croquet== (http://www.opencroquet.org(englisch) ). Alan Kay - der seiner Zeit immer etwas voraus zu sein scheint - forscht mit seinem Team (und einer inzwischen ebenfalls wachsende Community) aktuell an virtuellen interaktiven 3D-Welten die sich auf verteilten Plattformen abspielen. Croquet hat auf den ersten Blick starke Ähnlichkeit mit der boomenden Internet-Community SecondLife (http://secondlife.com/world/de/whatis/), bei der weltweite Benutzer sich mit ihren virtuellen Körpern ("Avatare") in künstlichen dreidimensionalen Welten treffen, diese gestalten und ein Sozial- und Wirtschaftsleben dort entwickeln können. Croquet geht aber viel weiter: Während die "virtuelle Welt" SecondLife auf abgeschlossenen Server-Farmen läuft, ist sie bei Croquet frei als Squeak-Image + Source-Datei verfügbar und benötigt keinen zentralen Server. Die einzelnen "lebenden" Objektnetze der teilnehmenden Rechner verknüpfen sich über das Internet und schaffen die virtuelle Welt gemeinsam ohne Zentrale als "PearToPear-Architektur". Ziel ist eine 3D-webbasierte-multiuser-multiplatform-Benutzeroberfläche für beliebige, noch zu definierende Anwendungen. Dabei wurden natürlich Java als Programmiersprachen in Betracht gezogen, aber nach Prüfung wieder verworfen, weil selbstbezügliche Eigenschaften, perfektionierte Objektspeicherverwaltung (incl. Garbage-Collection) und der fließende "Design-Edit-Test-Debug"-Kreislauf unbedingt notwendig für ein solches Projekt erschienen (http://www.opencroquet.org/index.php/Help(englisch)). Weil Squeak die Basis für Croquet wurde, können alle vorhanden Squeak-Anwendungen (also theoretisch auch Scratch) in die Croquet-Welt "mitgenommen" werden: In der einfachsten Version werden sie auf "im Raum schwebenden" Fenstern ausgeführt. Über ein Scratch-Squeak-Croquet-Smalltalk-Aufstiegsszenario könnten interessierte Jugendliche also von den spielerischen Anfängen der Programmierung bis hin zu "state of the art"-Projekten kommen, also dahin, wo "die Zukunft schon heute gemacht wird" ;) .

Ein Aufstiegspfad von Scratch nach Squeak wäre somit eine interessante Chance für die Zukunft und wie Alan Kays berühmtes Zitat sagt:

„The best way to predict the future is to invent it.“ - „Der beste Weg, die Zukunft vorherzusagen, ist, sie zu erfinden.“

Referenzen

  1. ↑ A White Paper Overview, Harry H. Porter III, March 24, 2003
Code zum Einbinden ins Forum:
[wiki=de:Scratch Implementierung in Squeak Smalltalk]Scratch Implementierung in Squeak Smalltalk[/wiki]
Abgerufen von „https://de.scratch-wiki.info/w/index.php?title=Scratch_Implementierung_in_Squeak_Smalltalk&oldid=46756“
Cookies helfen uns bei der Bereitstellung von Das deutschsprachige Scratch-Wiki. Durch die Nutzung von Das deutschsprachige Scratch-Wiki erklärst du dich damit einverstanden, dass wir Cookies speichern.
Weitere Informationen