Follow my new blog

Sonntag, 6. Februar 2011

Spielend programmieren

imageBesser wird es nicht durch Klagen. Besser wird es nur, wenn man sich überhaupt vorstellen kann, wie es besser sein könnte. Dafür muss man sich manchmal frei machen von dem, was ist. Einfach alle Begrenzungen hinter sich lassen. Mal frei fabulieren, wie die Welt aussehen sollte, und beherzt eine Antwort finden auf die Frage: “Ja, wie hätte ich es denn gern, wenn ich mir etwas wünschen dürfte von einer Fee?”

Heute habe ich mir gegönnt, diese Frage für die Programmierung mal für mich zu beantworten. Geplant hatte ich das nicht. Eher bin ich ohne zu fragen über meine Antwort gestolpert.

Wie wünsche ich mir also die Programmierung?

Ich wünsche mir die Programmierung spielerisch(er). Ich wünsche mir, dass Programmieren so funktioniert wie TinkerBox von Autodesk.

TinkerBox ist ein Spiel, in dem man “Maschinen” baut bzw. vervollständigt, um eine Aufgabe zu lösen. Zugegeben, das sind sehr, sehr, sehr einfache Aufgaben im Vergleich zu einer Warenwirtschaft oder einem Compiler oder einer Stellwerkssteuerung.

Aber auch Druckpressen, Autos, Fahrstühle sind sehr viel komplizierter als die TinkerBox-Maschinen und doch funktionieren sie letztlich nach denselben Gesetzen.

Hier ein paar Impressionen von TinkerBox:

Als ich mit TinkerBox angefangen habe auf meinem iPad zu spielen, habe ich einfach das Gefühl gehabt: “Wow, so sollte auch die Programmierung laufen!” Ich möchte Programme visuell zusammensetzen. Ich möchte sie sofort probeweise laufen lassen. Dabei möchte ich zusehen, wie die Teile zusammenspielen.

Natürlich kann das nicht ganz so simpel sein wie bei TinkerBox. Aber warum muss es denn sooooo anders aussehen? Warum muss es aussehen wie heute, wo ich eigentlich nur wie vor 30 Jahren Text in einer imperativen Sprache in einen Editor klopfe? Das kann doch nicht das Ende der Fahnenstange sein. Wir können doch nicht ernsthaft der Meinung sein, mit einer textuellen IDE (und ein bisschen Visualisierung drumherum) die Spitze des Möglichen in der Softwareentwicklung erklommen zu haben.

Nein, ich möchte, dass das anders aussieht. Ich will Software aus Bausteinen aufbauen. Ich will sie zusammenstecken. Ich will sehen, wie sie funktioniert – zum einen, indem ich am Code die Funktionalität ablese, zum anderen, indem ich den Code dabei beobachte.

Manche der Bausteine sind dabei Standardbausteine, andere sind Bausteine, die ich noch “zuhauen” muss, wieder andere setze ich aus anderen zusammen.

image

Bei TinkerBox gibt es nur Standardbausteine. Die Kunst besteht darin, sie in zielführender Weise zu kombinieren. Für die Softwareentwicklung reicht das natürlich nicht. Wir brauchen Bausteine, die wir “parametrisieren” können. In die gießen wir mehr oder weniger normalen Quellcode. Das finde ich ok. Denn die Menge des Quellcodes ist dann überschaubar.

TinkerBox hat in mir den Gedanken verstärkt, dass wir in der Softwareentwicklung Konstruktion und “Kreation” strikt trennen müssen. Wir brauchen beides, aber es sind grundsätzlich verschiedene Tätigkeiten.

Bei der Konstruktion nehme ich Bausteine und setze aus ihnen etwas Größeres zusammen.

Bei der Kreation denke ich mir neue Bausteine aus (oder “parametrisiere” Standardbausteine). (Ob “Kreation” der beste Begriff dafür ist, lasse ich mal dahingestellt. An dieser Stelle wollte ich aber nicht Implementation schreiben.)

Bausteine zusammenstecken, sie zu einem funktionierenden Ganzen fügen, das ist etwas ganz anderes, als Bausteine zu entwickeln, zu kreieren.

In der Softwareentwicklung trennen wir aber bisher nicht sauber, sondern sind im Grunde ständig mit der Kreation beschäftigt. Die jedoch ist viel schwieriger als die Konstruktion. Der einfache “Beweis”: Selbst Kinder können mit Legobausteinen tollste Dinge konstruieren – kreiert haben aber nicht Kinder die Legobausteine, sondern Erwachsene.

Genauso ist es mit Excel. Millionen von Poweruser können aus den Standardbausteinen in Excel tollste “Rechengebilde” konstruieren. Kreiert haben diese Standardbausteine jedoch Programmierer.

So ganz neu ist die Vorstellung, die ich hier äußere, natürlich nicht. Von Komponenten, die per glue code nur noch verbunden werden müssen, träumte man schon in der 1990ern oder gar davor. Realisiert ist diese Vision aber nur sehr begrenzt.

Mir geht es auch nicht darum, Laien zu Softwareentwicklern zu machen. Ich möchte den Softwareentwicklern nur das Leben erleichtern. Sie sollen sich mehr auf das Wesentliche konzentrieren. Das – so stelle ich mir in einem kühnen Traum vor – können sie aber besser, wenn Programme visueller machen. Die Anhaftung an Text als primärem Ausdrucksmittel für Software, ist anachronistisch und kontraproduktiv. Ich kenne keine andere Branche, in der Designdokumente primär textueller Art sind; nur die Softwareentwicklung beharrt darauf. Denn Programmierung ist Design.

Also: Befreien wir uns von der Last der Texte! Machen wir die Softwareentwicklung haptischer. Entlasten wir uns durch Trennung von Konstruktion und Kreation. Ich glaube, dann wird vieles besser in der Programmierung. Denn dann können wir besser über Software reden und wir können dann besser gemeinsam an Software arbeiten.

16 Kommentare:

Anonym hat gesagt…

Würde das nicht für das Konzept der modellgetriebenen Softwareentwicklung sprechen?

Ralf Westphal - One Man Think Tank hat gesagt…

Reflexhaft würde ich sagen, ja. Aber "modellgetrieben" ist inzw so aufgeladen als Begriff, deshalb möchte ich ihn eher vermeiden.

Mir geht es eben nicht um immer wieder neue DSLs, mir geht es nicht um komplizierte Metaframeworks. Mir geht es zunächst um ein fundamentales Umdenken in Richtung Sinnlichkeit. Ja, "sinnliche Programmierung" könnte ich das nennen, wonach ich suche. Programmieren mit allen Sinnen.

Wir sollten uns nicht in Formalitäten verlieren, sondern spielerisch herangehen. Und wer da sofort mit der Keule "Das geht doch alles nicht, weil viiiiel zu kompliziert" kommt, der hat noch nicht begriffen, was ich meine ;-)

Kompliziert und unwartbar haben wir heute schon zur genüge. Es kann also nur besser werden, wenn es sinnlicher wird.

Sinnlichkeit und Bewältigung von Kompliziertheit steht für mich nicht im Widerspruch - eher im Gegenteil. Ohne Sinnlichkeit, ohne Breitbandigkeit kriegen wir Komplexität gar nicht in den Griff. Und ohne Sinnlichkeit skaliert Softwareentwicklung nicht; wir kriegen zuwenige Leute an Bord, die die wachsende Nachfrage bewältigen, wenn wir nicht sinnlicher werden.

Unknown hat gesagt…

Scratch ( http://scratch.mit.edu ) geht in diese Richtung.

mfg,
-Horst JENS
www.spielend-programmieren.at

Ralf Westphal - One Man Think Tank hat gesagt…

@Jens: Das Problem mit Scratch ist, dass es einfach nur bisherigen Quellcode "mit Kästchen umrahmt". Das Ergebnis ist zwar visuell - aber deshalb nicht besser handhabbar. Eher sogar schwieriger, finde ich. Scatch bietet sozusagen Flowchart- oder Struktogrammprogrammierung.

Nichtsdestotrotz ist es schonmal ein Schritt weg vom reinen Textquellcode zu etwas Sinnlicherem.

Markus Schaber hat gesagt…

Hallo, Ralph! Hast Du Dir schon mal die graphischen Sprachen aus der IEC 61131-3 Familie angesehen? Sehen auf den ersten Blick aus wie Schaltpläne. Ich programmiere jetzt seit ende der 80er textuell, und bin seit 1 Monat in einer Firma, die Entwicklungswerkzeuge für diese graphischen Sprachen herstellt.

Ralf Westphal - One Man Think Tank hat gesagt…

@Markus: Auf IEC 61131-3 hatte schon mal jmd hingewiesen. Sieht interessant aus - ist aber ja hardwareorientiert. Dennoch stecken darin sicher sinnige Anregungen.

UML-Tools, Function Block Diagrams, BPMN Tools geht bei allen Impulsen aus meiner Sicht noch das wirklich Sinnliche ab, auch das Spielerische. Sie kommen normiert und formal daher. Verständlich - doch für breite Akzeptanz in einer Branche, die von Autodidakten geprägt ist, hinderlich.

Deshalb schiele ich immer wieder zum iPad mit seiner Welt der Spiele.

Lars hat gesagt…

Hallo Ralf,

du hattest vor ein paar Tagen gefragt, was ich damit meinen würde, dass mir die Idee der optischen Darstellung von Abhängigkeiten zwischen Schritten und Zuständen nicht gefallen würde...ich denke, die Beschreibung "fehlende Sinnlichkeit" trifft es ganz gut.
Es fühlt sich einfach nicht natürlich an.
Tinkerbox ist hingegen ja eine große "Wenn -> Dann"-Maschine. Das ist ein Prinzip, das sogar ein Grundschüler versteht.
Und da man Zustände auch in einem "Wenn...Dann"-Kontext behandeln kann, sollte man es tun, eben weil der Mensch es von Haus aus versteht. Ein "A,B&C reagieren in abhängig von Ding X" ist immer erklärungsbedürftig. In einem Spiel würde man nie eine zweite Abhängigkeitsebene einziehen, die man zusätzlich bauen muss. Davon sollte man in der Tat lernen.
Man sollte eher das Prinzip das sowieso jeder versteht: "Wenn Zustand X dann los!" so einfach in einem Werkzeug realisierern, dass es eben auch wirkt wie das bauen einer Dominoreihe.

Ralf Westphal - One Man Think Tank hat gesagt…

@Lars: Vielen, vielen Dank für das Stichwort "wenn-dann": Ja, genau darum geht es mir, glaub ich. Nicht im Sinne von Flowcharts mit den Fallunterscheidungs"diamanten", sondern im Sinne von grundlegender Kausalität.

Sinnlichkeit und Kausalität; sinnliche Kausalität - das ist für mich die Zukunft der Softwareentwicklung.

Raus aus der Abstraktheit, so weit irgend möglich. Wir sollten und recken und strecken, um die Programmierung, den Code, die Softwaremaschine so sinnlich erfahrbar, so haptisch und kausal wie möglich zu machen.

Abstraktionsebenen sind dann kleinere Maschinen in größeren Maschinen. Subsysteme halt.

Nur Achtung jetzt: Ich behaupte damit nicht, dass damit dann wieder Substantive kreiert und konstruiert werden sollen. Nein, nein, das wäre zu simpel gedacht. Dann ist nämlich die Kausalität nicht mehr sofort sichtbar.

Das ist ja schon das Problem normalen Codes und jedes Abhängigkeitsdiagramms: der Ursache-Wirkung-Fluss ist nicht sichtbar. Das (!) macht allem voran Software so abstrakt, glaube ich.

Kriegen wir es allerdings hin, Kausalität sichtbar zu machen und Kausalitätsketten sinnlich erfahrbar, manipulierbar (im wörtlichen Sinne; lat. manus = Hand) zu machen, dann kommen wir einen echten Schritt voran.

Unknown hat gesagt…

Hallo Ralf! :-)

Du triffst den Nagel auf den Kopf!
Wir Menschen sagen immer zu schnell: "Es geht nicht anders! Punkt!".
Dabei fragt sich aber keiner, wie es anders gehen könnte.

Ein knuffiges Tool, was in die richtige Richtung geht, ist z.B. Kodu von Microsoft.

Tja, den Kindern versucht man wirklich spielerisch das Programmieren beizubringen.
Jede Wette: Wenn dann diese Kinder später mal Softwareentwickler werden wollen, läuft es denen kalt den Rücken runter, wenn sie sehen, mit was wir uns aktuell so rumplagen.

Von Spaß kann man bei unserer Tätigkeit kaum noch sprechen.

Es gibt komplizierte Spezifikationen für Spezifikationen (siehe UML) und jede Menge "best practices", an die man sich gefälligst zu halten hat, wenn man ein guter Softwareentwickler sein will.
Sowas gibt einen doch gar kein Gefühl mehr für individuelle Entfaltung seiner Ideen.

Die Softwarebranche ist so spießig und ernst geworden. Ja, sie ist zum Mainstream geworden. Im "Big Business" ist kein Platz für Spielereien. Man "muss" quasi Module von Dritten verwenden, weil die Eigenentwicklung zu lange dauern würde.
Daher sieht das alles aus, wie Einheitsbrei. Man muss sich mit Frameworks rumärgern, die man eigentlich gar nicht nutzen will ... aber irgendeine Anforderung zwingt einen dazu.
Dann gibt es wieder GUI-Richtlinien, usw.

Kann sich so überhaupt etwas Neues, Individuelles entwickeln?
Wie soll das nur weiter gehen?

mfg

Christian

Ralf Westphal - One Man Think Tank hat gesagt…

@ChinaFan: Ich finde nicht, dass 3rd Party Libraries und Spaß sich widersprechen. Und ich glaube ich auch nicht daran, dass "GUI-Guidelines" Spaß und Kreativität widersprechen. Die Kunst ist dafür ein Jahrtausende altes Beispiel: sie ist voll von Regeln - und alle haben Spaß dabei. Also: nicht Spaß trotz Regeln, sondern durchaus Spaß wegen und mit Regeln.

Regeln brauchen allerdings einen gewissen Rahmen, damit sich durch sie Spaß entfalten kann. Und da kommt für mich das Haptische, das Sinnliche um die Ecke.

Unknown hat gesagt…

@Ralf:
Ich finde nicht, dass 3rd Party Libraries und Spaß sich widersprechen.

Naja, das sicher nicht. Aber sie nehmen einen den Reiz, etwas Neues zu schaffen. Auf Arbeit bin ich gezwungen, 3rd Party Libraries zu verwenden, weil keine Zeit für eigene Implementationen ist. (Ich meine da z.B. Diagramm-Komponenten, Tabellen, usw. Nicht etwa die Standard-Komponenten, wie z.B. die generische Liste oder so. ;-))
Und manchmal ist es auch einfach der Anreiz, zu überlegen, wie man selber sowas programmieren könnte. Da macht für mich Programmieren erst richtig Spaß. :-)

Wir befinden uns heute in einer Zeit, wo es nur noch heißt: "Gibt's schon ... warum nimmst du nicht das?" (Wo wir schon fast wieder bei der Frage nach dem "richtigen" Paradigma angelangt sind. *g*)

Die Kunst ist dafür ein Jahrtausende altes Beispiel: sie ist voll von Regeln - und alle haben Spaß dabei.

Wobei ich denke, dass es kein globales Regelwerk gibt, wo drin steht, wie etwas zu sein hat.
Es gibt verschiedene Stile. (wie z.B. bei der Musik)
Anhand bestimmter Regeln kann ich erkennen, welchen Stil ich gerade vor mir habe. Möchte ich selber diesen Stil repräsentieren, "muss" ich mich an diese Regeln halten.
Weiche ich aber von ein Paar dieser Regeln ab, ist das aber auch nicht richtig oder falsch, solange es mir so gefällt. Es ist dann ein neuer Stil entstanden. Und so kann das dann immer weiter gehen.

Ich bin vorhin auf ein paar interessante Seiten gestoßen, als ich folgendes gesucht hatte: "Hat Kunst Regeln?"

Pierre Bourdieu: Die Regeln der Kunst
Gibt es Regeln in der Kunst? (Eine interessante Diskussion, wo man sehr schön Querverbindungen zur Softwareentwicklung ziehen kann.)

mfg

Christian

Gerhard Völkl hat gesagt…

Hallo,

auf der Suche nach einem solchen Tool bin ich schon seit 20 Jahren.
Es gab Visuelle Progragrammierung
und ähnliches, aber etwas Allgemeingültiges, Produktives ist da nicht heraus gekommen.

Wenn man den Schritt von Microsoft von Winforms hin zu XAML bedrachtet, geht es doch eher weg vom Visuellen hin zu mehr Texten?

Mit der Idee "Spielend programmieren" ist das Ziel abgesteckt. Jetzt bräuchte man
nur eine Landkarte, wie man dort hin kommt. ;-)

Schöne Grüße

Gerhard

Thomas Gey hat gesagt…

Hallo Ralf,
ich denke solange noch in Klassen (Abstraktionen) programmiert wird ist es schwieriger die Software "spielend" zu konstruieren.
Ich denke, wenn Entwickler die Möglichkeit hätten die Objektwelt die sie während der Programmierung im Hinterkopf haben, in einer IDE umzusetzen, wäre dies ein Schritt in Richtung Konstruktion.
Ich selber empfinde das Bild des Software(LEGO)steins als eine sehr charmante Lösung. Mit einer einer handvoll Grundelementen lassen sich riesige (Software)Welten erschaffen.

Gruß Thomas

Carsten hat gesagt…

Ich werde das Gefühl nicht los, auf einer Verkaufsveranstalltung zu sein: wollen sie kreativ sein? Spielend programmieren? Mit Dokumentation auf Knopfdruck?

Ich habe so eine Ahnung, auf was das hinausläuft. Heizdecken werden es wohl nicht sein.

Ralf Westphal - One Man Think Tank hat gesagt…

@Carsten: Wenn ich denn nur etwas zu verkaufen hätte... Ich würd mich freuen und nicht so lang drumrumreden.

Hab aber nix. Kann dir leider kein Angebot machen. Außer Wunschtraum bisher nix gewesen.

Aber gute Idee. Ich muss mich wohl mal dran machen mit "TinkerProg" ne Million zu verdienen ;-)

Anonym hat gesagt…

Hallo,
für viele ist es ja keine Programmiersprache aber bei uns in der Firma programmieren wir fast alles mit LabVIEW.
Das ist das gleiche was bei Lego Mindstorm (einfache Version) zum einsatz kommt.

Könnt ihr euch ja mal anschauen.
Ich finde es klasse:
- Grfisch
- Datenfluss nachvollziehbar,
- Debuggen super Easy

Anschauen kann ja nix schaden.

Felix