GP (Programmiersprache)

Scratch: v1.0

v1.1

v1.2

Player: Squeak

Mods: Panther

GP

3D: Beetle Blocks

BlocksCAD

Roboter: Open Roberta

Enchanting

Text-coding: Tosh

Mobil: Pyonkee‎‎

Pocket Code

Analyse: Vergleich

Geschwindigkeit

Geschichte

GP Beispiel

-#Jens Mönig, -#John Maloney und -#Yoshiki Ohshima nach dem Workshop

Hier soll ein Artikel über die neue Programmiersprache "GP" entstehen, die -#Jens Mönig, -#John Maloney und -#Yoshiki Ohshima (CDG Labs US mehr infos geleitet von -#Alan Kay) auf der Scratch2015AMS zum ersten Mal öffentlich vorgestellt haben. GP ist eine graphische, blockbasierte, objektorientierte Programmiersprache, die sich momentan noch in der Betaphase befindet. Das Ziel ist es, eine erweiterbare, portable Plattform zu bieten, mit deren Hilfe sich Programmierneulinge, aber auch erfahrene Spezialisten Programme für ihre Bedürfnisse erstellen können [1]. Die offizielle Website zu GP findet sich hier: [2].

Eine Browserversion ist unter diesem Link verfügbar: [3].

Im Rahmen der Scratch2017BDX-Konferenz fand ein Workshop mit John Maloney, Jens Mönig und Yoshiki Oshima statt:

https://youtu.be/FamVvpVhI98 (6 min)
https://youtu.be/gsCoI1IhQjg (2:30 h)

Vereinfacht lässt sich über GP sagen: "Easy like Scratch, Powerful like Squeak"

Open-Beta-Phase

Seit Juli 2017 befindet sich GP in der Open-Beta-Phase. Es gibt ein entsprechendes Forum [4], das neben vielen hilfreichen Leitfäden zur Verwendung und Oberfläche von GP auch eine Sektion beinhaltet, in der Bugs gemeldet werden können. Außerdem finden sich hier Erklärungen aller wichtigen Versionen, Neuerungen, und Diskussionen.

Die öffentliche Beta-Phase soll ca. ein Jahr dauern.

Entwicklerteam

GP ist Ergebnis der Zusammenarbeit von -#John Maloney, der 11 Jahre lang der Scratch-Chefentwickler war und -#Jens Mönig, der seit seinem ersten Kontakt mit Scratch und den ersten Experimenten mit Chirp und der "Elements-Language", über BYOB und Snap!, seit 8 Jahre an blockbasierten Programmiersprachen arbeitet, die immer mehr Beschränkungen von Scratch aufheben. Für diese Idee, die auf der Arbeit des Scratch-Teams von -#Mitch Resnick und letzen Endes auf noch älteren Fundamenten wie Logo (Programmiersprache) (-#Seymour Papert) und Squeak#E-Toys (-#Alan Kay) aufbaut, fanden sich Förderer und Vordenker, wie -#Brian Harvey und -#Alan Kay. John und Jens sind langjärige Sqeak-Smalltalk Profis, aber während John seiner Scratch-Zeit langjährig direkt im Squeak-Entwicklungsteam gearbeitet hatte ^[1], war Jens erst aufgrund seiner Begeisterung für Scratch zu seinen Programmierer-Wurzeln zurückgekehrt und hatte dafür sogar seine Rechtsanwalt-Kanzelei aufgegeben ^[2]. Beide hatten vor der Entwicklung von GP für einige Jahre die Smalltalk-Welt verlassen: John für Scratch 2.0, dass er für die gewünschte weblauffähigkeit in Flash-Actionscript implementierte und Jens für und Snap!, das er mit dem gleichen Ziel in Javascript entwickelte. Das GP-Team ist Teil der von Alan Kay geleiteten und SAP finanzierten CDG Labs und wird verstärkt durch weitere langjährige Squeak-Smalltalker wie (offiziell) -#Yoshiki Ohshima und (inoffiziell?) -#Bert Freudenberg, der im Hintergrund bereits an einer Javascript-Version der virtuellen Maschine von GP arbeitet. GP wird zur Zeit in C und in GP selber programmiert, beim Projektstart war auch Squeak-Smalltalk genutzt worden.

(siehe auch:

Kernideen

GP baut auf vier Grundideen auf [5]:

‘‘extensible‘‘: Die idee bezieht sich auf die Vorstellung einer vollständig zugänglichen und modifizierbaren Plattform als Basis für die Sprache. Die Grundidee hierfür kommt wiederum von Scratch: der Quellcode (in Smalltalk) lässt sich einsehen, ist aber weder kommentiert, noch in irgend einer anderen Weise für den Leser dokumentiert, und daher eher unzugänglich und schwer verständlich. Das überrascht insofern nicht, dass die Option, den Quellcode zu sehen und zu modifizieren nicht vorgesehen war. Der Sachverhalt wirft die Frage auf, was passieren würde, wenn es dem Benutzer ermöglicht wird, das Grundgerüst einer Programmierumgebung zu modifizieren. Aus diesem Grund besteht GP bis hin zum untersten Level aus Blocks, um den eigentlichen Quellcode so simpel und zugänglich wie möglich zu machen.
‘‘portable‘‘: Hier geht es um die Anforderung, dass eine solche Sprache auf Laptops oder Smartphones benutzbar sein soll, als ob sie integrierte oder vom App Store heruntergeladene Apps wären.
‘‘general purpose‘‘: Es ist schwierig, sich festzulegen, was unter diesem Begriff zu verstehen ist, da die Anwendungsgebiete eben so breit gestreut sein sollen – die Sprache die erschaffen wurde, soll verwendbar sein für die verschiedensten Konzepte. Gleichzeitig sollen aber auch Anbindungs- und Verbindungsmöglichkeiten zu mobilen Geräten, Bibliotheken in C, Bilderkennungssoftware oder Datenbanken bestehen.
‘‘for casual programmers‘‘: Laut John Maloney würden viele Leute sehr wohl programmieren (Kinder, aber auch Erwachsene!), wenn sie nur das richtige Werkzeug dazu hätten; Scratch ist zwar in vielerlei Hinsicht dieses richtige Werkzeug, verfügt jedoch nicht über ausreichende Funktionen, um Jeden anzusprechen. Das Ziel sollte sein, dass Jeder programmieren kann, was er entweder benötigt, oder was ihn interessiert (z. B. wenn ein Astrophysiker ein Teleskop programmieren möchte, um Werte abzulesen, oder ein Biochemiker, der Daten analysieren möchte). In vielen Fällen besitzen solche Leute also eine Vorstellung dessen, was sie brauchen, und das nötige Fachverständnis, um zu wissen, wie es funktionieren würde (welche Algorithmen notwendig wären, o. Ä.). Andererseits besteht einfach oft nicht die Zeit oder Motivation, um Java, C, oder ähnliche Programmiersprachen zu lernen. Es besteht also Bedarf an einer Sprache, die Scratch ähnelt, aber „ernsthaftere“ Anwendungen ermöglicht, als Scratch sie bietet.

Features

GP bringt einige neue Konzepte mit sich, die teilweise aus Scratch, aus Snap, oder aus anderen Sprachen bekannt sind. Andere wiederrum sind nur in dieser Programmierumgebung vertreten:

Variablen

Variablen werden, genau wie in Scratch und Snap, nicht im Code deklariert und initialisiert; beides geschieht im Moment der Erstellung. GP kennt drei Arten von Variablen:

‘shared‘: globale Variablen, die jedes Objekt kennt,
‘instance‘: instanzspezifische Variablen, z. B. haben Objekte der Klasse „Auto“ verschiedene Werte für das Attribut „PS“,
‘script‘: ähnlich wie in Snap: temporäre Variablen, die nur in einem einzigen Skript existieren, z. B. zur Berechnung von Zwischenergebnissen

Dynamische Typisierung

Wie in Scratch und Snap sind Variablen nicht an einen bestimmten Datentyp gebunden, sodass z. B. die selbe Variable zuerst einen Integer, dann einen String, und dann etwa einen boolschen Wert speichern kann.

Eigene Blöcke

Wie Scratch und Snap, ist GP in der Lage, benutzerdefinierte Blöcke zu speichern und wiederzuverwenden. Es werden drei Arten von Blöcken und zwei Arten von Sichtbarkeit unterschieden:

‘shared‘: sind von jedem Objekt im Programm sichtbar und verwendbar
‘method‘: nur sicht- und verwendbar in der aktuell angewählten Klasse
‘initialize‘: nur sicht- und verwendbar in der aktuell angewählten Klasse; werden bei Erzeugung eines neuen Objektes sofort ausgeführt (diese Art von Blöcken ist somit funktional identisch mit einem Konstruktor z. B. in Java)

Nichtatomarer Interpreter

Hier handelt es sich um die Eigenschaft, dass Codeblöcke verzögert ausgeführt werden. Das bedeutet, dass bestimmte Skripte langsamer ausgeführt werden als die Umgebung (und der Computer) es eigentlich zulassen würde. Ohne diese Verzögerung (mit einem atomaren Interpreter) könnten Sprites sofort nach Programmstart die Grenzen der Leinwand verlassen, ohne dass für den Benutzer ersichtlich wäre, warum. Um Anfänger vor diesem Phänomen zu bewahren, wurde die Verzögerung für bestimmte Block-Arten eingeführt (und ein nichtatomarer Interpreter verwendet [6]. In GP unterliegt nur die Endlosschleife („animate“) dieser Verzögerung.

Klassen und Objekte

Das Konzept von Klassen und Objekten als Instanzen von Klasse wird in GP andersartig dargestellt, als in den nahen Verwandten Scratch und Snap!. Während Letztere den Prototyping-Ansatz vertreten, nach dem Objekte geklont werden und dadurch neue Objekte erzeugen, orientiert sich GP näher an textbasierten Sprachen, wie beispielsweise Java oder C. Hier werden vom Benutzer Klassen beschrieben, von denen dann Objekte erzeugt werden.

Interaktion mit Dateisystemen

GP ist, anders als Snap! und Scratch, in der Lage, mit Dateisystemen und Dateien in diesen Systemen zu interagieren, d.h. sie zu öffnen, zu ändern und abzuspeichern. Intern basiert diese Funktionalität aus der Verwendung von sog. Streams, wie sie z. B. von Smalltalk bekannt sind [7]. Es handelt sich hierbei um ein Format, das es es Benutzer ermöglicht, mit vielen Quellen (Dateien, Hardware, Internetseiten, ...) anhand eines standardisierten Interfaces zu kommunizieren. Scratch bietet diese Möglichkeit nur über die Modifikation Panther.

Entwicklermodus

Der Developer-Modus stellt eine optional zuschaltbare Erweiterung der Funktionalität der Programmierumgebung dar; er ist über das Kontextmenü der Leinwand anwählbar. Bei aktivem Developer-Modus werden einige Kategorien um neue Blöcke erweitert und neue Kategorien hinzugefügt (v.a. komplexere Funktionalitäten und experimentelle Features).

Class Browser

Der Class Browser verkörpert die Vision von GP, dass selbst komplexeste Projekte realisierbar sind. Im Class Browser sind alle Skripte gelistet, die in der Palette zu finden sind, und darüber hinaus alle Skripte, die das interne Verhalten der Umgebung beschreiben. Der Class Browser macht es möglich, nachzuvollziehen, wie die Funktionsweisen der Programmierumgebung bis zur untersten Ebene hin implementiert sind; so lässt sich die Implementierungshierarchie von Skripten bis zur primitiven Ebene hin verfolgen; Primitive Skripte sind solche, die nicht mehr weiter analysierbar sind, da sie ihrerseits auf C-Funktionen abgebildet werden. Nutzbar ist er dadurch beispielsweise, um vordefinierte Skripte zu ändern, ergänzen oder zu löschen, und somit eine eigene GP-Version völlig den eigenen Ansprüchen entsprechend zu erstellen. Dadurch stellt er eine direkte Unterstützung für Modifikationen und Erweiterungen dar (angelehnt an die große Moddingszene und vielen Modifikationen von Scratch).

Exportierung als App

GP unterstützt eine der Funktionen, die seit Scratch zu den am meist gefragten gehört: Eine Export-Funktion, die das Projekt in eine ausführbare, eigenständige Datei konvertiert. Während Scratch selbst keine solche Exportierung unterstützte, bildeten sich im Laufe der Zeit Third-Party-Programme, die eine Konvertierung ermöglichten – Scratch selbst bietet keine entsprechende Funktionalität an. Snap! bietet die Möglichkeit, Projekte zu XML-Dateien zu verwandeln, die dann beispielsweise mithilfe von Snapp! [8] zu eigenständigen Programmen konvertiert werden können. GP bietet diese Möglichkeit direkt auf der Oberfläche der Umgebung an. Die exportierte Datei ist völlig eigenständig und benötigt GP nicht, um ausführbar zu sein.

Nested Sprites

Nested Sprites („verschachtelte Sprites“) sind solche, die sich aus mehreren Teilen zusammenset zen und eine gemeinsame Verbindung besitzen. Ihre Rotationen und Bewegungen sind dadurch voneinander abhängig, aber auch auf Objektebene werden sie gesondert behandelt. In Snap! kann eine solche Beziehung zwischen Objekten durch Drag-and-drop erzeugt werden, doch momentan ist dies in GP noch nicht möglich. Die beiden Objekte müssen aufeinander platziert werden, dann wird per shift + Rechtsklick die Option ‘attach‘ ausgewählt. Die Teil-Ganzes-Beziehung kann durch detach“ über das Kontextmenü rückgängig gemacht werden, sodass die Teile wieder zu einer eigenständigen Instanz werden und vom Besitzer losgelöst existieren (ebenso wie in Snap!).

First-class-Objekte

Objekte „erster Klasse“ sind solche, die völlig uneingeschränkt in einer Sprache benutzbar sind; das bedeutet, sie müssen in Variablen speicherbar sein, als Input und Output von Funktionen verwendbar sein, anonym verwendbar sein, usw. In Java z. B. können Integer Input und Output (Parameter und Rückgabewert) einer Methode sein; eine Methode hingegen kann nicht als Parameter für eine andere verwendet werden. Hier sind also Methoden Objekte „zweiter Klasse“. In GP ist (ebenso wie in Snap) jedes Objekt ein Objekt erster Klasse: Alles soll uneingeschränkt verwendbar sein (z. B. Listen von Kostümen, Variablen, die Code speichern, usw).