Warum ist die grafische Darstellung eines Algorithmus bei Programmierern so unbeliebt?
Unbeliebt? Wieso unbeliebt? Alles in der heutigen Zeit läuft auf visuelle Programmierung hinaus und angefangen mit einem einfachen Flußdiagramm, die man zum Beispiel sehr professionell in LaTeX
herstellen kann, Blockdiagramme und letzten Endes ganzen Sprachen, die sowas beschreiben wie UML, über Sprachpakete wie Visual Basic, VisualC++ von Microsoft, über Jugend- und Lernsprachen wie Scratch
, Stencyl
, Blocky
und anderen Projekten bis runter zu Lego Mindstorms.
Alle arbeiten visuell.
Dazu kommen Node-Systeme wie bei Game-Engines wie Unity, bei Unreal, in Shadern wie beim 3D Programm Blender und vielen vielen mehr.
Diese Darstellung und diese Handhabung ist von Pädagogen und der allgemeinen visuellen Darstellungs-Industrie von Büchern und Videos völlig beliebt.
Nur ich hasse sie. Und mit mir eine Menge anderer Programmierer und Informatiker.
Ich weiß nicht, warum andere diese Sprachen hassen, aber ich hasse sie aus zweierlei Gründen. Naja, hassen ist vielleicht ein zu großes Wort dafür, aber ich sehe den Nutzen äußerst kritisch. Erstmal die Pro-Punkte dieser Darstellung.
Das läßt sich medial super vermitteln. Das läßt sich prima in Vorträgen darstellen, bewerben und vermarkten, denn es macht Strukturen schön bunt und sichtbar. Das läßt sich gut verkaufen an Pädagogen, die große bunte wertvolle haptische Erfahrungen vermittelnde Lego-Bausteine, glückliches Kinderlachen und Kleinkinder, die fröhlich mit einem Block WHILE Schleife auf einen Funktionsaufruf einschlagen und kucken, ob das Ding wieder dieses lustige Geräusch macht wie letztes mal. Und es ist waschecht und kann nicht verschluckt werden und toll bunt in Primärfarben.
Es verkauft Programmierung als etwas, was es nicht ist. Diese kognitive Dissonanz führt zu nichts gutem.
Contrapunkt ist, dass Programmierung nun mal nicht einfach ist und diese Darstellungsmethode die Dinge verkompliziert. Sie ist langsam, umständlich, man verliert schnell die Übersicht bei größeren Projekten, man hat nur schwer die Chance das Projekt zu zerteilen, zu organisieren, zu kommentieren, zu strukturieren und im Teamwork zu modularisieren, außerhalb der Grundidee der kleinen bunten Blöcke.
Das gilt für Flussdiagramme und Blockdiagramme eigentlich genauso. Das ist alles sehr schön in einem Vortrag an einem Overheadprojektor oder Beamer, in einem Youtube Clip, aber wenn man wirklich am Bildschirm daran arbeitet, stellt man schnell fest: es ist die Hölle.
Während ich mit einem
for i=1,10 do print(i) end 
In Lua zum Beispiel eine Schleife in wenigen Sekunden getippt habe, eine Variable definiert und eine Ausgabe produziert habe, bin ich mit der Maus noch nicht mal durch die Menüs, in denen die Blöcke für Flusssteuerung angeboten werden durch.
Jeder kann das gern mal versuchen, diese Zeile tippen oder sie in Scratch oder Stencyl oder dem Blocky von Google programmieren und dabei mal die Zeit messen. Dann ansehen, wieviel Prozent des Bildschirms diese Lösung dann verbraucht. Also kurz gesagt, wieviel Code, wieviel Algorithmus kann man auf einer Bildschirmseite übersichtlich unterbringen?
Übersichtlichkeit ist auch Kompaktheit der Darstellung. Die ist im Visuellen nicht gegeben. Bei weitem nicht. Und die Gründe dafür sind offensichtlich.
Programmierung ist eine langwierige und teilweise frustrierende Erfahrung. Und meine Erfahrung, wie man damit am besten umgeht ist, dass man sich immer in regelmäßigen Abständen kleine Erfolgserlebnisse beim Programmieren gibt, indem man Teilprobleme löst und ausprobiert und dann weiter bastelt, Stück für Stück.
Dass über den visuellen Weg das Programmieren allein schon ein vielfaches der Zeit kostet, steht diesem Motivations-Feedback schon direkt entgegen. Dass man außer in trivialen Problemen mit einer unübersichtlichen riesigen Masse an Blöcken, Verbindungen und Leitungen, virtuellen Kabeln und der gleichen kämpfen muss, ist ebenfalls nicht hilfreich.
Ich habe als Lehrer gearbeitet und hatte den direkten Vergleich der Schüler, die erst in Lua eingeführt wurden und dann in Lego Mindstorms. Während sie in Lua auf Textbasis sehr schnell sehr komplexe Probleme lösen konnten, haben sie am Ende endlos Zeit verbraten an Trivialitäten mit Lego Mindstorms und haben überdies den abstrakten Zugang, den sie über Lua an sich schon erlernt hatten wieder vergessen. Das ist zerstört worden.
Visuelle Programmierung ist destruktiv, sie erodiert die gerade erst erlernten abstrakten Denkstrukturen. Programmierung ist nicht visuell. Ein Programm bildet sich nicht visuell in unserem Kopf, nicht in solchen Blöcken. Das bildet sich sprachlich, in Überlegungen wie WENN…DANN und sprachliche Abbildung ist nun einmal Text.
Und deswegen hasse ich sie.
Blockdiagramme funktionieren nicht, aber ich sehe den Wert von der visuellen Darstellung, wenn man Algorithmen an der Tafel oder am Beamer oder Whiteboard vermitteln will, rein visuell. Das Visuelle funktioniert auf diesem visuellen Übertragungsweg natürlich besser als Textzeilen.
Und das steht außer Frage. Aber wir sollten uns fragen, wo Programme entstehen? Am Whiteboard oder in der Impress-Demonstration über den Beamer oder in harter Arbeit am Bildschirm?
Und deshalb ist visuelle Programmierung im Wesen falsch und ein bedauerlicher aber hübsch anzusehender Irrweg, etwa wie ein drogenabhängiges Emo-Clubgirl. Hübsch und irgendwie Fashion aber kaputt und völlig auf dem falschen Dampfer und endet in einer traurigen Katastrophe auf der Intensivstation, im besten Fall. Und in der Programmierung landet es im intellektuellen Abgrund und in Frustration, verleitet durch falsche Imagekampagnen und verführerische Werbung für falsche Ideale und Methoden; Marketing und Propaganda gewinnt, wie fast immer. Die leise Stimme der Vernunft ist viel schwieriger zu verkaufen.
Hauptsache es ist bunt, funktionieren muss es nicht. Form over Function, wie es im Englischen heißt, das ist die Krankheit unserer Welt. Und dafür braucht man sich eigentlich nur mal eine moderne Kaffeemaschine ansehen, die super aussieht, wie ein außerirdisches Raumschiff und nach zwei Monaten auseinander fällt.
Und das können wir nicht in der Programmierung erlauben, zumindest dürfen wir es nicht fördern, sonst war's das nämlich bald für unsere moderne Informations-Gesellschaft.
Schon mal den visuellen Code eines anderen versucht zu debuggen?
Wenn ja, dann hasst du visuelle Programmierung genauso wie ich und wirst meine Einstellung dazu verstehen und sie aus ganzem Herzen teilen.
Die Frage nach dem Sinn der visuellen Programmierung ist durchweg eine philosophische: was ist das Wesen eines Programmes, des intellektuellen Konstrukts des Algorithmus, dem Ablauf von Regeln, dem Beschreiben eines Vorgangs - ist es verbal oder ist es visuell? Wie denkt man? Wie stellt man es sich vor? Wie erbaut man sich einen Algorithmus?
Jeder mag sich diese Frage selbst beantworten nach etwas Nachdenken. Und da ist dann die Antwort.