Achtung
Die erste Version dieser Veröffentlichung erhielt eine großartige Resonanz auf Reddit in Form von mehr als 300 Kommentaren. Danach habe ich beschlossen, ein kleines Update hinzuzufügen, um einige Kritikpunkte der vielen erhaltenen zu beantworten.
Eine visuelle Programmiersprache ermöglicht es einem Programmierer, Programme durch Manipulieren grafischer Elemente zu erstellen, anstatt Textbefehle einzugeben. Ein berühmtes Beispiel ist
Scratch , eine visuelle Programmiersprache des MIT, mit der Kinder unterrichtet werden. Seine Vorteile sind, dass es das Programmieren für Anfänger und Nicht-Programmierer zugänglicher macht.
In den 1990er Jahren gab es eine sehr beliebte Bewegung für die Einführung der visuellen Programmierung in eine Unternehmensumgebung mithilfe der sogenannten
CASE- Tools, bei der Unternehmenssysteme mithilfe von
UML definiert und [ihr Code] generiert werden konnten, ohne dass geschulte Softwareentwickler angezogen werden mussten. Dies ist auf das Konzept der „runden Auslösung“ zurückzuführen, bei dem das System visuell modelliert werden kann, Programmcode aus den resultierenden Modellen generiert wird und alle Codeänderungen an das Modell zurückgegeben werden können. Leider konnten solche Tools ihre Mission nie erfüllen, und die meisten Experimente [zu ihrer Implementierung] werden derzeit weitgehend aufgegeben.
Daher hat die visuelle Programmierung bis auf einige sehr begrenzte Bereiche nicht an Popularität gewonnen. Diese Situation ist hauptsächlich auf die folgenden falschen Vorstellungen über die Programmierung zurückzuführen:
- Textprogrammiersprachen verwirren einen im Wesentlichen einfachen Prozess.
- Abstraktion und Entkopplung ( Entkopplung, Reduzierung der Konnektivität ) spielen bei der Programmierung eine kleine periphere Rolle.
- Tools, die zur Unterstützung der Programmierung entwickelt wurden, sind nicht wichtig.
Das erste Missverständnis besteht darin, dass die Softwareentwicklung eine hohe Eintrittsschwelle hat, da Textprogrammiersprachen die wahre Natur der Programmierung erschweren. Die Popularität von Scratch bei akademischen Pädagogen spielt mit diesem Missverständnis zusammen. Die Idee ist, dass das Programmieren eigentlich recht einfach ist. Wenn wir es nur in einem klaren Grafikformat präsentieren könnten, würde dies die Lernkurve und den mentalen Aufwand für das Erstellen und Lesen von Programmcode drastisch reduzieren.
Ich gehe davon aus, dass dieses Missverständnis auf die Unfähigkeit zurückzuführen ist, ein typisches Programm, das in der Standard-Textprogrammiersprache geschrieben ist, tatsächlich zu lesen und mir vorzustellen, wie es aus Würfeln und Pfeilen in grafische Elemente umgewandelt wird. Wenn Sie sich das noch vorstellen können, wird sofort klar, dass eine einzelne Codezeile häufig mit mehreren „Blöcken“ übereinstimmt. Da selbst für das einfachste Programm das Vorhandensein von Hunderten oder zwei Codezeilen nicht ungewöhnlich ist, wird der Code zu Hunderten oder sogar Tausenden von grafischen Elementen. Ein Versuch, ein so komplexes Bild mental zu analysieren, ist viel schwieriger als nur den entsprechenden Programmtext zu lesen.
Die Lösung für die meisten visuellen Programmiersprachen besteht darin, die „Blöcke“ komplexer zu gestalten, sodass jedes visuelle Element einem großen Textcodeblock entspricht. Die visuellen Werkzeuge des Workflows sind ein sofortiger Stolperstein.
Das Problem ist, dass der Code noch irgendwo definiert werden muss. Daher wird der Codierungsprozess [bei großen visuellen Elementen] zu „Programmierdialog-Eigenschaften“. Die visuellen Elemente selbst stellen nur die höchste Ebene der Programmbewegung während der Ausführung dar, und der größte Teil der Arbeit wird jetzt in Standardtextcode ausgeführt, der in visuellen „Würfeln“ versteckt ist. Infolgedessen haben wir das Schlimmste aus beiden Welten genommen und eine Textprogrammierung erhalten, die von modernen Tools nicht unterstützt wird.
Dialogfelder von Eigenschaften sind normalerweise nicht standardmäßige Entwicklungsumgebungen und erfordern eine bestimmte Sprachauswahl, normalerweise eine Skriptsprache eines bestimmten Typs. Die grundlegenden visuellen Elemente selbst können nur von erfahrenen Programmierern erstellt werden, und sie können nur durch Lesen ihres grundlegenden Codes gründlich verstanden werden, sodass die meisten angeblichen Vorteile der visuellen Präsentation hier verloren gehen.
Es gibt eine Impedanzfehlanpassung zwischen dem visuellen „Code“ und dem Textcode (eine
Reihe von konzeptionellen und technischen Schwierigkeiten ), und der Programmierer muss über die Schnittstelle zwischen ihnen navigieren und häufig mehr Aufwand für die Verbesserung des grafischen Programmierwerkzeugs selbst als für die Lösung der anfänglichen Aufgabe [des Schreibens des Programms] aufwenden.
Und jetzt kommen wir zu dem zweiten Missverständnis, dass Abstraktion und Dekuplikation eine kleine Rolle bei der Programmierung spielen. Die visuelle Programmierung basiert auf der Annahme, dass die meisten Programme einfache prozedurale Sequenzen sind, die einem Flussdiagramm ähneln. In der Regel denken die meisten Programmieranfänger, dass Software einfach so funktioniert.
Sobald das Programm jedoch mehr als ein eher triviales Beispiel ist, wird seine Komplexität den unerfahrenen Programmierer bald überwältigen. Anfänger finden es sehr schwierig, über eine große prozedurale Codebasis zu sprechen, und sind oft festgefahren, wenn sie versuchen, stabile und effiziente Software in großem Maßstab zu erstellen. Die Hauptinnovation bei Programmiersprachen war der Versuch, die Komplexität zu steuern, normalerweise durch Abstraktion, Kapselung und reduzierte Konnektivität. Alle Typsysteme und Konstruktionen objektorientierter und funktionaler Programmiersprachen sind eigentlich nur ein Versuch, die Komplexität dieser Sprachen zu kontrollieren.
Die meisten professionellen Programmierer werden den Code ständig abstrahieren und entkoppeln. Tatsächlich besteht der Unterschied zwischen gutem und schlechtem Code darin, wie sehr der Programmierer dies geschafft hat. Visuelle Programmierwerkzeuge verfügen sehr selten über wirksame Mechanismen für solche Dinge. Infolgedessen ist der „visuelle“ Entwickler in den verfügbaren Funktionen gefangen, was BASIC der 1970er Jahre entspricht.
Das letzte Missverständnis ist, dass visuelle Programmierer angeblich auf alle Programmierunterstützungswerkzeuge verzichten können, die über Jahrzehnte entwickelt wurden. Schauen Sie sich die lange Entwicklung von Code-Editoren und IDEs an. Beispielsweise unterstützt Visual Studio ein effektives Intellisense-Tool, mit dem Sie einen Blick auf die Tausenden von APIs werfen können, die allein in der Basisklassenbibliothek verfügbar sind. Das Fehlen einer guten Versionskontrolle ist ein weiterer großer Fehler in den meisten visuellen Programmierwerkzeugen.
Selbst wenn sie ihr Layout im Textformat speichern, haben „Unterschiede“ keine oder fast keine Bedeutung. Es ist sehr schwierig, in einem großen XML- oder JSON-Block eine Schuld zu geben (um das Commit zu finden und für das Ändern einer bestimmten Zeile verantwortlich zu sein). Dinge, die für die funktionale Ausführung eines Programms keine Bedeutung haben, wie die Position und Größe von Grafikelementen, führen ständig zu Änderungen der Metadaten, was das Parsen von Diff noch schwieriger macht.
Textprogrammiersprachen haben gelernt, die strukturellen Codeblöcke in separate Quelldateien aufzuteilen, sodass es einfach ist, eine Änderung in einem Teil eines Systems mit einer Änderung in einem anderen zusammenzuführen. Visuelle Werkzeuge speichern das Ergebnis normalerweise nach dem Prinzip „ein Diagramm pro Datei“. Dies bedeutet, dass das Zusammenführen problematisch und noch schwieriger wird, wenn die semantische Bedeutung von „diff“ schwer zu analysieren ist.
UpdateIch habe mich wahrscheinlich geirrt, als ich einen Scratch-Screenshot gemacht und ihn in meinem ersten Absatz als Paradebeispiel verwendet habe. Ich bin kein Lehrer und habe keine eigene Meinung über die Effektivität von Scratch als Lernwerkzeug. Viele Leute sagen, dass es im Programmierunterricht äußerst nützlich ist, insbesondere für Kinder. Alles, was den Menschen hilft, in die wunderbare und aufregende Welt des Programmierens einzusteigen, sollte nur gelobt werden. Ich wollte Scratch jetzt wirklich nicht speziell kritisieren, dies ist nur ein Beispiel für ein visuelles Programmiersystem, das, wie es mir schien, die meisten meiner Leser zumindest hätten hören sollen.
Ein weiteres von Reddit bereitgestelltes Gegenbeispiel waren statische Strukturwerkzeuge wie UI-Designer, Datenbankschema-Designer oder Klassen-Designer. Ich bin damit einverstanden, dass sie sehr hilfreich sein können. Alles, was zur Visualisierung der Datenstruktur oder der Skalenstruktur des Programms beiträgt, ist ein Bonus. Aber sie sind niemals genug. Dies wird durch den vollständigen Ausfall von Tools aus den 90er Jahren wie Power Builder belegt, die auf grafischen Visualisierungen basierten, um eine Entwicklungsumgebung zu erstellen, ohne mit Code arbeiten zu müssen.
Über den Autor:
Notizen, laute Gedanken, klares Lernen, Missverständnisse, Fehler, unverdünnte Meinungen. Ich bin Mike Hadlow, ein Predigerentwickler. Ich lebe in der Nähe von Brighton an der Südküste Englands.
Die Übersetzung wurde von EDISON Software, einem professionellen Softwareentwicklungs- und Testunternehmen , unterstützt.