Wir nutzen Cookies, um das allgemeine Benutzerelebnis zu verbessern. Mit der Nutzung unseres Wikis stimmst du der Nutzung von Cookies zu.

GP (Programmiersprache)

Stub.png Dieser Artikel (oder Abschnitt) ist noch sehr kurz (oder unvollständig!). Hilf mit, ihn ausführlicher zu gestalten, indem du Informationen, Bildmaterial oder Texte hinzufügst.
GP Beispiel

Hier soll ein Artikel über die neue Programmiersprache "GP" entstehen, die -#Jens Mönig, -#John Malony und -#Yoshiki Ohshima (CDG Labs US mehr infos geleitet von -#Alan Kay) auf der Scratch2015AMS zum ersten Mal öffentlich vorgestellt haben.

Unter en:GP (programming language) entsteht gleichzeitig eine englische Version dieses Artikels, die zum Teil schon weiter ist, so dass Teile davon hierher übertragen werden könnten, bzw. ein umgekehrter Abgleich ebenfalls Sinn macht. Diese beiden Artikel sind zur Zeit scheinbar (laut Google) wohl die einzigen Infos die es zu GP gibt, wenn irgendwo weitere auftauchen bitte zumindest den Link unten einfügen...ansonsten hoffen wir auf die Scratch@MIT2016 auf der hoffentlich schon eine Beta gezeigt werden kann...

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

Erster Workshop mit GP

Im total überbuchten Scratch2015AMS -Workshop am Samstag 15.08.2015 konnten ca. 30 Interessierte am eigenen Laptop (Mac, PC oder auch Linux) erste Erfahrungen mit der nicht öffentlichen Pre-Alpha-Version von GP sammeln. Unter anderem konnte eine Reihe von GP-Beispielprogrammen ausprobiert werden, die mit der Installation kamen. Dabei stellten sich schnell Erfolgserlebnisse und Begeisterung ein, so dass viele dem ersten offiziellen (Alpha-)Release von GP mit freudiger Erwartung entgegensehen.

Auch die "Macher" von GP freuten sich offensichtlich, dass ihre Konzepte so gut bei den ersten Anwendern ankamen.


Konferenz Video dazu: https://vimeo.com/140660699


GP at ScratchAMS2015 workshopfoto2.jpg

Hintergründe von GP

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)Wikipedia.jpg (-#Seymour Papert) und Squeak#E-ToysWikipedia.jpg (-#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 Allan Kay geleiteten und SAP finanzierten CDG Labs und wird verstärkt durch weitere langjährige Squeak-Smalltalker wie (offfiziell) -#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.

Man kann gespannt sein, welche Folgen es haben wird, wenn mit GP der Übergang vom Scratch-Programmieranfänger hin zum Gelegenheitsprogrammierer und zum Profi immer fließender wird: Für immer mehr Menschen könnte Programmieren so selbstverständlich werden, wie Lesen und Schreiben, auch wenn nicht jeder gleich „Romanautor“ werden muss. Mit Sprachen wie Scratch kann jeder leicht lernen, was Programmieren überhaupt ist, aber mit Sprachen wie GP könnte Programmieren zu einem selbstverständlichen Bestandteil des Alltags von vielen werden.

(siehe auch:

Eigenschaften von GP

Name, Logo Status

  • GP ist eine graphische, blockbasierte, objektorientierte Programmiersprache
  • GP steht für General Purpose Blocks Programming Language
    • GP könnte stehen für Graphical Programming oder auch (holy) Grail (of) Programming ;-)...
    • GP ist laut Jens und John erstmal ein "Arbeitstitel", es gibt auch noch kein Logo für GP...obwohl...statt einer orangen Katze startet GP mit einem blauen Quadrat...
  • GP ist für performante, leistungsstarke, Anwendungen geeignet (viel schneller als Scratch und Snap! Es können z.B. hunderte oder sogar tausende von Sprites gleichzeitig animiert werden, wie eine "Vogelschwarmsimulation" eindrucksvoll zeigte, oder Soundsynthese direkt aus der Berechnung der Klangkurve als Sound abgespielt werden.
  • GP soll Multiplattform-fähig sein: Schon jetzt läuft GP auf Windows, Mac und Linux. An einer JavaScript-Version die im Webbrowser laufen würde, wird gearbeitet
  • GP ist zurzeit noch im Pre-Alpha-Stadium und nicht offiziell veröffentlich. Bisher gibt es kaum Material und keine offene Testversion
  • GP soll einige Zeit nach der Veröffentlichung OpenSource werden

Zielgruppe, Zweck

Zielgruppe sind "Gelegenheitsprogrammierer". GP soll helfen jedem, schnell und einfach Software zu erstellen, ohne sich Tief und zeitaufwändig einarbeiten zu müssen. John hat dies auch als "Casual Programming" bezeichnet. Mit GP wird es einfacher, einem Experten auf einem bestimmten Gebiet Programmieren beizubringen, als einem Programmierer das fehlende Expertenwissen zu vermitteln, um für den Experten eine bestimmte Anwendung zu erstellen. Dabei soll es keine Beschränkung bezüglich Anwendungsgebiet, Plattform oder Professionalität geben: Mit GP kann der Geschäftsmann schnell eine Geschäftsanwendung erstellen die ihm fehlt, der Physiker schnell eine Simulation, oder ein Schulkind ein selbsterdachtes Spiel.

GP ist damit auch das fehlende Bindeglied zwischen der Lernsprache Scratch und "professionellen Programmiersprachen": Es enthält dazu unter anderem Elemente, mit denen man zwischen textueller und blockbasierter Programmierung "überblenden" kann: Blockbasierte Programmierung per Tastatur (sehr schnell!) und das "symbolische" Verblassen der Blöcke, so dass nur noch der Sourcecode stehenbleibt. Dieses Features könnte dazu beitragen, Kritiker der blockbasierten Programmierung davon zu überzeugen, dass es sich dabei um "richtiges Programmieren" handelt, das nicht nur für Schulkinder geeignet ist.

Implementierung, VM

  • GP läuft auf einer virtuelle Maschine (bisher in C geschrieben, an einer alternativen JavaScript-VM arbeitet -#Bert Freudenberg)

Übergang: Anfänger, Nutzer, Profi

  • Im "normalen Modus" hat GP Ähnlichkeit zu Scratch oder Snap! Der Zugang ist einfach und intuitiv
  • Im "Expertenmodus" hat GP Ähnlichkeiten zu Squeak-Smalltalk. Nichts ist unmöglich!
  • Diese Ähnlichkeit bezieht sich jedoch nicht auf den Smalltalk-Syntax: Die Syntax von GP gleicht Scratch/BOY/Snap. An Smalltalk erinnern aber die Implementierung und die Werkzeuge: Im „Expertenmodus“ wird GP zur "professionellen Programmiersprache" mit Klassenbrowser, Debugger und Inspektor, mit denen man den graphischen Blockcode browsen und alle Instanzen des „lebenden Objektnetzes“ analysieren kann. Ähnlich wie man bei Scratch 1.x mit dem „Shift-R-Geheim-Trick“ in dessen Squeak-Implementierung kommt, gelangt man so bei GP ganz offiziell in dessen Entwicklungsumgebung. Man erkennt, dass die gesamte Implementierung/Entwicklungsumgebung von GP ebenfalls blockbasiert in GP programmiert ist. Damit ist die GP-Implementierung selber bereits das beste Beispiel dafür, dass damit professionelle Software erstellt werden kann. Man kann die GP-Entwicklungsumgebung sogar komplett nach Belieben interaktiv anpassen (wie SqueakWikipedia.jpg im Bezug auf Smalltalk_(Programmiersprache)Wikipedia.jpg). Laut Jens wird man auch das komplette GP-Objektimage abspeichern können, womit ein "Snapshot" des aktuellen Objektspeicher-Zustandes auf ein Speichermedium abgelegt und jederzeit wieder aktiviert werden kann, wie in Smalltalk üblich.
  • Damit hat die Art, wie GP implementiert ist, erhebliche Ähnlichkeit zu Squeak-Smalltalk: Man könnte sagen, GP ist eine Art Symbiose von Scratch, Snap! und Squeak, was beim Hintergrund der Macher kaum verwundert.
  • Es gibt zwar den "Expertenmodus" und den "Normalmodus", jedoch ist der Übergang vom Anfänger zum Alltagsprogrammierer viel fließender als das "Umlegen des Experten- Schalters"
  • Mit Scratch/Snap! Vorkenntnissen kann man GP intuitiv sofort bedienen. Die komplexeren Konzepte und unbegrenzten Möglichkeiten der Programmierung bleiben zunächst dezent verborgen, so dass man sie erst entdeckt, wenn man sie sucht, z.B. weil man sie benötigt: Wie Scratch selbst, unterstützt GP also den fließenden Übergang zu zunehmend mächtigeren Konzepten, ohne Anfänger durch "zu viel Komplexität auf einmal" abzuschrecken, lässt ihn aber viel mehr „Raum nach oben“ als Scratch.

Oberfläche, Klassen, Instanzen und graphische Objekte in GP

  • GP hat Klassen und Instanzen, aber keine Vererbung. Die Macher meinen, Vererbung sei zu schwierig für das intuitive Verständnis beim "Casual Programming". Stattdessen wird "Delegation" genutzt.
  • Wie in Scratch wird GP zunächst mit graphischen Objekten (Sprites) gearbeitet. Der Aufbau der Oberfläche im Normalmodus hat große Ähnlichkeit zu Scratch: Es gibt einen Bühnenbereich, einen Objektauswahlbereich und einen Medienbereich, der wahlweise für Block-Skripte, Grafik und Sound des ausgewählten Objektes genutzt wird. Der einzige offensichtliche Unterschied ist, dass der Objektauswahlbereich in einen "Klassen-Bereich" (Textliste der Klassennamen) und einen "Instanz-Bereich" (grafische Auflistung der Instanzen eine Klasse) unterteilt ist.
  • Bei GP ist das "Startobjekt" ein farbiges Quadrat, statt des "Katzen"-Sprites (bei Scratch) oder des "Richtungspfeils" (bei BYOB/Snap!). Dieses Startobjekt ist die grafische Instanz einer Startklasse ("My Class"). Dadurch wirkt GP zunächst so einfach wie Scratch/Snap!: Solange es eine grafische Instanz pro Klasse gibt, besteht der einzige Unterschied darin, dass man den Klassennamen anwählen muss, um zum jeweiligen graphischen Objekt zu kommen: Man könnte dann Klasse und Instanz als eine Einheit betrachten und ist sofort in der "Denkwelt" von Scratch.
  • Während in Scratch 2.0 weitere Instanzen eines Objektes per "Cloning" im Programmablauf erzeugt werden und bei Programmende sofort wieder verschwinden, können in GP neue Instanzen schon im Programmiermodus erzeugt werden und bleiben bestehen, bis sie explizit gelöscht werden. Auch die letzte Instanz kann gelöscht werden, da die Definition des Objektes in der Klasse erfolgt, während die Instanzen die individuellen Werte der Objekte repräsentieren.
  • Um zu erkennen, welche Klasse und Instanz angewählt ist, wird der Klassenname in der Klassenliste markiert: Damit werden alle Ihre graphischen Instanzen im Instanz-Auswahlbereich daneben aufgelistet und anwählbar, wie bei Scratch im Objektauswahlbereich. Eine dort angewählte Instanz wird durch eine Linie markiert, die vom Rand des Bühnenbereichs aus drauf zeigt. Das ist sehr praktisch, da die Instanzen sonst auf der Bühne oft kaum unterscheidbar sind, kann aber natürlich auch abgeschaltet werden wenn es stört.
  • Natürlich kann eine Klasse auch keine oder beliebig viele Instanzen haben und die Instanzen müssen auch nicht unbedingt graphische Objekte sein: Im Expertenmodus, kann man einen Klassenbrowser und einen Inspektor benutzen, wie in Smalltalk üblich.

[....]

GP schon jetzt online ausprobieren

Auf einer inoffiziellen Seite kann man GP bereits ausprobieren. Einige Funktionen sind schon implementiert. Manche davon funktionieren wirklich, andere leider noch nicht. Aber man kann schon das Prinzip und die Struktur hinter GP entdecken. [1]

Einzelne Features

Rekursive Berechnung der Fibonaccizahlen in GP
  • Benutzerdefinierte Wert-Blöcke: Benutzerdefinierte Blöcke werden durch Hinzufügen eines return-Blocks zu einem Wert-Block. Solche Blöcke sind Vorraussetzung um rekursive Funktionen sauber zu implementieren. Ein ähnliches Feature existiert für Snap!, jedoch nicht für Scratch.
  • GP hat "nested Sprites", d.h. die graphischen Objekte können miteinander verbunden werden. Ihre Eigenschaften wie X-, Y-Koordinaten, Drehung etc. beziehen sich dann also nicht auf das Koordinatensystem des Bühnenbereichs sondern auf das Sprite, mit dem sie verbunden sind. Wahlweise kann man einzelne Eigenschaften "entbinden", z.B. die Drehung unabhängig machen.

Wunsch-Features die (noch?) nicht existieren

  • Es wäre denkbar GP so zu konzipieren, dass es in einem "Easy/Scratch-Modus" exakt wie Scratch funktioniert und mit zunehmenden Verständnis des Anwenders für komplexerer Konzepte immer mehr darüber hinausgehende Features freigegeben werden.
  • Wichtig wäre, dass sich das Verhalten nicht etwa ändert, sondern das "Easy"-Verhalten immer als ein Spezialfall des jeweils komplexeren Verhaltns verstanden werden kann.
  • Dabei könnte dieser Modus als Teil des Projektes abgespeichert werden und beim Laden eines Projektes in einem höheren Modus vorm ersten Bearbeiten gewarnt und höher geschaltet werden.

Multiple Block-Slots

  • Am einfachsten ist das "Abschalten" der optionalen Block-Slots, die es bei Scratch nicht gibt

Jedes Sprite könnte eine Bühne + eine Leinwand sein

  • In einem der hier gelistenen Workshop-Videos wird John nach einem Feature in dieser Art gefragt und reagiert positiv: Das heißt aber natürlich noch nicht, dass es existiert! :-)
  • Wie die "Kostüme" bei Scratch, kann das farbige Quadrat, das ein Objekt zunächst darstellt, durch eine Bitmap oder Vektorgraphik ersetzt werden.
  • Außerdem kann man durch "nestable Sprits" ein Sprite zu einer Bühne eines anderen machen, auf der es sich in dessen Koordinatensystem bewegt.
  • Der Clou wäre aber, dass das Quadrat in Wirklichkeit eine eigenständige Bühne mit Leinwand ist, auf der sich nested Sprites bewegen können, und per Programmierung auch durch ein "nested Sprite" gemalt werden kann, wie in Scratch auf die Bühne. Alle Malbefehle eines Objektes beziehen sich natürlich auf dessen Koordinaten, Drehung und Skalierung.
  • Natürlich gibt es aber trotzdem einen "Bühnenbereich" auf dem sich die grafischen Instanzen befinden. Wenn man auf diesem malen will, kann man einfach ein ausreichend großes graphisches Objekt hineinlegen. Die Größe des Bühnenbereiches ist zunächst vorgegeben wie in Scratch, sie kann jedoch beliebig geändert werden.
  • Dann wird eine separate Objektart "Bühne" auch nicht nötig. Bei Start eines neuen Projektes extiert als "Vorbelegung" ein Objekt "Bühne", das den Bühnenbereich komplet ausfüllt und ein Objekt "Sprite" das sich auf dem Bühnenobjekt bewegt und darauf malen kann. Dann funktioniert alles wie in Scratch, solange das Bühnenobjekt nicht bewegt wird. Um das Leinwand-Konzept zu erklären, muss man nur das Bühnenobjekt aus dem Bühnenausschnitt lösen und bewegen.
  • Die Sprites könnten eventuell einen zusätzlichen Paramter haben, der angibt, ob sie auf "die Leinwand" des Sprites malen dessen direkte "nested Sprite" sie sind, oder gegebenenfalls auf die Leinwannd eins oder mehr Ebenen darüber (wenn das Sprite zu dem sie "nested" sind seinerseit nested sind).

vom "Scratch-Sprite" zum GP-Klassen/Instanzkonzept

  • Das Klassen/Instanz-Konzept das bei Scratch nicht exitstiert, kann leicht vereinfacht werden, mit einem Schalter: "teile Objekt in Instanzen/Klassen" auf: Ist dieser nicht gesetzt, so wird die Klassenauswahlliste nicht angezeigt und es existiert nur genau ein Sprite/eine Instanz pro Klasse. Der Klassenname wird zum Namen des aus Instanz und Klasse gebildeten "Einheits-Objektes", bei dem nun ein Unterschied zwischen Instanz und Klasse nicht mehr erkennbar ist, wie bei den Objekten in Scratch. Die Sprites aller dieser Einheitsobjekte werden dann einfach im gleichen Objekt-Auswahlbereich angzeigt. Clonen könnte man in diesem Modus erlauben, wie in Scratch, mit automatischen Löschen aller Clones bei Programmausführungsende.

Offene Fragen

  • Ähnlichkeiten und Unterschiede zu
    • Scratch?
    • Snap!?
    • Squeak / Smalltalk ?
  • Beziehen sich Medienobjekte auf Klassen oder auf Instanzen?
  • Gibt es Klassen-Methoden und Klassen-Variablen wie in Smalltalk?
  • Gibt es Globale Variablen wie in Smalltalk?
  • Wie wird "Vererbung" durch "Delegation" ersetzt? Wie wird redundanter Code ohne Vererbung vermieden?
  • Sehr gut wäre eine Feature-Tabelle in der Scratch 1.4, Scratch 2.0, BYOB, Snap! und GP einander gegenüber gestellt werden

Videos

Screenshots

GP Screenshot Beispiel2 stickman.png
GP Screenshot Beispiel3 Arrows.png
GP Screenshot Beispiel4 Block Text slider.png
GP Screenshot 11 Flock Example.jpg
GP Screenshot Beispiel8 Nested Sprites.png
GP Screenshot Beispiel5 Many Block have optional Arguments.png
GP Screenshot Beispiel6 Block Tastatur Editing.png
GP Screenshot Beispiel7 Boolena Darstellung.png
GP Screenshot 12 Stage Menu.jpg
GP Screenshot 13 Enter developer mode.jpg
GP Screenshot 15 in Developer mode.jpg
GP Screenshot 8 Debugging.jpg
GP Screenshot 9 Class Bowser Example IntegerToStringBase16.jpg
GP Screenshot 10 Class Bowser Example is This Rectangle == That Rectangle.jpg
GP Screenshot 14 Virtual Machine v165.jpg
Scratch ClickShift R Trick.jpg
Scratch plus Squeak equals Tom and Jerry.jpg

Workshopfotos

GP at ScratchAMS2015 workshopfoto1.jpg
GP at ScratchAMS2015 workshopfoto2.jpg
GP at ScratchAMS2015 workshopfoto3.jpg
GP at ScratchAMS2015 workshopfoto4.jpg
GP at ScratchAMS2015 workshopfoto5.jpg
GP at ScratchAMS2015 workshopfoto6.jpg
GP at ScratchAMS2015 workshopfoto7.jpg
GP at ScratchAMS2015 workshopfoto9.jpg

Einzelnachweise

  1. Scratch-Day 2009 in Bochum#Online-Konferenz mit Mitch Resnick und John Malony
  2. Jens Mönig am Scratch Day 2013