Texteditor ist keine gute Idee

Wir sind aber auch aus einem anderen Grund ganz glücklich darüber, komplexere Programme nur ergänzen statt sie komplett schreiben zu müssen.

Als wir am Anfang merkten, dass es sich beim Editor tatsächlich um einen richtigen Texteditor handelt und nicht um eine grafische Programmierumgebung wie Blockly, waren wir als alte Programmierprofis eigentlich ganz begeistert. Mit der Zeit merkten wir aber, wie unsinnig ein reiner Texteditor zum Programmieren auf einem Gerät und Betriebssystem ist, das komplett auf Touchbedienung ausgerichtet ist.

• 

Bei der Editoreingabe steht am Bildschirmrand eine Auto-Vervollständigung zur Verfügung, ... (Screenshot: Alexander Merz/Golem.de)

Zuerst verwendeten wir die iPad-Hardcover-Tastatur - bis wir die Autovervollständigung entdeckten. Die finden wir eigentlich gut, sie kann nicht nur Funktions- und Variablennamen ergänzen, sondern auch ganze Sprachkonstrukte und -elemente wie Klammern. Die Vervollständigung wird aber nicht wie bei IDEs üblich im Editor angezeigt und per Pfeiltasten und Enter ausgewählt - was schon an den fehlenden Pfeiltasten an der Cover-Tastatur scheitert. Die Vervollständigung ist stattdessen ein Teil der virtuellen Tastatur und zwingt uns deshalb, die Hand von der Hardwaretastatur zu nehmen und auf den Bildschirm zu tippen.

Mit einem Finger tippen statt mit zehn

So entscheiden wir uns, die reale Tastatur links liegenzulassen und die virtuelle zu nutzen, um unsere Arbeitswege etwas abzukürzen. Doch auch hier nervt schnell ein eigentlich praktisches Feature. Wer eine Funktion mit Parametern oder zum Beispiel eine "For"-Schleife nicht eintippt, sondern per Autovervollständigung einfügt, kann Integer-Parameter im Konstrukt einfach durch Antippen im Konstrukt eingeben. Dann öffnet sich ein kleiner Dialog zum Eingeben der Zahl. Ist aber dabei die virtuelle Tastatur offen, wird sie geschlossen.

Das ist an sich sinnvoll, denn sonst wäre vor Eingabemöglichkeiten der Code nicht mehr sichtbar. In der Praxis funktioniert das ganz leidlich bei Lektionen, in denen wir nur Parameter im bestehenden Code ändern sollen, bei freier Texteingabe macht es uns aber mit der Zeit wahnsinnig. Auf einen Parameter tippen wir auch dann häufiger, denn eine Cursor-Navigation per Pfeiltasten oder äquivalente Optionen stehen nicht zur Verfügung. Dass das Markieren und Kopieren von Codezeilen den iOS-Standards entspricht, dürften eingefleischte iOS-Nutzer hingegen eher begrüßen.

Freies Programmieren folgt dem Lernen

Trotz der Editor-Macken arbeiten wir uns durch die Lektionen. Nachdem wir schließlich so den ersten Kurs absolviert haben und auch wahlfrei diverse Lektionen des zweiten Kurses durchgegangen sind, werfen wir einen Blick auf die Herausforderungen. Dabei handelt es sich um fertige Programme, die wir ändern können und auch sollen. Echte Aufgabenstellungen fehlen hier, eher steht hier die Demonstration vollständiger Programme im Vordergrund.

Eher spielerischen Charakter und eine Art Miniaturreferenz der API erhalten wir, wenn wir einen neuen Playground öffnen - die Bezeichnung meint nichts anderes als ein neues Programmierprojekt. Dabei können wir neben einer leeren Datei auch Vorlagen aufrufen. Sie enthalten eine Reihe von Funktionsaufrufen, um insbesondere die Darstellung grafischer Elemente zu verdeutlichen. Diese Vorlagen sind deutlich näher an der klassischen Programmierung als der eher spielerische Umgang mit dem Avatar Byte in den Kursen.

Leider können wir unsere selbst erstellten Programme nicht als eigenständige Apps exportieren, was aus unserer Sicht technisch durchaus möglich wäre. In einem Menü finden wir die Möglichkeit, alle Quellcodes und Ressourcen des jeweiligen Playgrounds einzusehen. Die Playgrounds-App ist im Kern anscheinend nichts anderes als eine grafische Oberfläche für einen Swift-JIT-Compiler.