Visuelle Programmierung ist eine Art von Programmiersprache, die es Menschen ermöglicht, Prozesse mit Hilfe von Illustrationen zu beschreiben. Während eine typische textbasierte Programmiersprache den Programmierer dazu bringt, wie ein Computer zu denken, lässt eine visuelle Programmiersprache den Programmierer den Prozess in Begriffen beschreiben, die für Menschen Sinn machen.
Wie groß die Kluft zwischen visueller Programmierung und traditioneller Programmierung ist, hängt von dem visuellen Programmierwerkzeug ab. In einem Extremfall schirmt das Werkzeug den Programmierer fast vollständig von der klaffenden Lücke zwischen menschlichem Denken und Computern ab, die Bits im Speicher umherschieben.
Hier ein Beispiel. Um eine To-Do-Liste mit einem visuellen Programmiertool zu erstellen, zeichnet der Programmierer den Ablauf der Anwendung auf. Das resultierende Flussdiagramm beschreibt Bildschirme, Benutzerinteraktionen und was mit den Daten in jeder Phase geschieht. Das Tool setzt dies dann in Software um.
Als Entwickler wissen wir, dass sich textbasierte Programmiersprachen ganz auf die Implementierung konzentrieren: Es geht um die genauen Schritte, die der Computer ausführen muss, um das Erlebnis zu schaffen, das wir dem Benutzer bieten wollen. Sicher, höhere Sprachen und moderne Frameworks bieten uns praktische Abkürzungen. Aber die Aufgabe des Entwicklers ist es, die menschlichen Bedürfnisse in Prozesse zu übersetzen, die zu den begrenzten Fähigkeiten des Computers passen.
Andere visuelle Codierungstools folgen denselben Prozessen und Paradigmen wie die textbasierte Programmierung. Stellen Sie sich vor, Sie zeichnen eine Klasse und ihre Beziehung zu den Objekten, die Sie instanziieren, anstatt alles in einen Texteditor einzutippen.
All das klingt großartig! Aber, so könnte man fragen, wo sind all die visuellen Programmierer? Warum schreiben wir den Code immer noch von Hand? Bedeutet das, dass visuelle Programmierung eine schlechte Idee ist?
Bevor wir diese Fragen beantworten und in den heutigen Stand der visuellen Programmierung eintauchen, müssen wir verstehen, was visuelle Programmierung wirklich ist: woher sie kommt, wie sie sich entwickelt hat und warum.
Entdecken Sie die nächste Generation von visuellen Entwicklungswerkzeugen
Eine kurze Geschichte der visuellen Programmiersoftware
Auch wenn die Geschichte es zu zeigen scheint, ist es nicht fair zu sagen, dass die visuelle Programmierung in den 1990er Jahren auf Spielentwicklungskits, Multimediatools und Datenbanken beschränkt war. Rational Software (das 2003 von IBM übernommen wurde) hatte seit Mitte der 1980er Jahre eine Ada-IDE ohne grafische Benutzeroberfläche entwickelt. Darüber hinaus beschäftigte sich das Unternehmen mit der Definition des Softwareentwicklungsprozesses. Die Arbeit an ihrem Rational Unified Process und verwandte Bemühungen führten schließlich zur Unified Modelling Language, die das Potenzial hatte, jeden einzelnen Teil eines Systems zu dokumentieren, ohne jemals eine Zeile Code zu schreiben. Sie ähnelte der visuellen Programmierung, ohne jedoch ausführbare Software zu erzeugen.
UML bot eine standardisierte und umfassende Sprache zur Beschreibung objektorientierter Systeme. Einige Architekten wurden jedoch vom UML-Fieber befallen. Der Mitautor von The Pragmatic Programmer, Andy Hunt, erzählt die Geschichte eines Softwareprojekts, bei dem ein Architekt zwei Jahre lang UML-Diagramme erstellte, bevor auch nur eine Zeile Code geschrieben wurde.
Gerade als die agile Methode an Fahrt gewann, schien UML all die schlimmsten Aspekte der alten Methoden der Softwareentwicklung zu ermöglichen: zu viel Planung und zu wenig Implementierung. Ausführbare UML war ein Versuch, das fehlende Stück hinzuzufügen – ausführbare Software. Es gab mehrere Implementierungen, die jedoch keinen großen Einfluss auf eine Welt hatten, die sich schnell auf PHP, Ruby on Rails und andere dynamische Skriptsprachen konzentrierte.
Interessanterweise kam eine Form der ausführbaren UML, die sich durchsetzte, ebenfalls von Rational Software. Rational Rose ist eine Reihe von Werkzeugen zur Erstellung von Software mit UML und zur Generierung von ausführbarem Code in einer Zielsprache wie C++ oder Java.
Back to the Future: Der Stand der visuellen Programmierung heute
Nach dem, was uns die Geschichte zeigt, werden Sie sich vielleicht fragen: Ist die visuelle Programmierung tot? Liebhaber der visuellen Programmierung werden Ihnen sagen, dass sie noch lange nicht tot ist. Fragen Sie sie, was visuelle Programmierung ist, und sie werden Ihnen zuerst ein obskures domänenspezifisches Tool nennen. Dann werden sie Ihnen sagen, dass dieses Tool der Beweis dafür ist, dass die visuelle Programmierung quicklebendig ist. In der Zwischenzeit werden Sie verzweifelt bei Google danach suchen. So lernen Sie nicht nur das erwähnte Tool kennen, sondern auch die hochspezialisierte Welt, in der es existiert.
Zweifellos hat die visuelle Programmierung ihre Berechtigung, sei es bei der Programmierung von Synthesizern oder um UML-Enthusiasten ein Erfolgserlebnis zu verschaffen. Für allgemeine Software ist die Welt jedoch einfach zu komplex, um sie rein visuell zu modellieren. Wenn Ihr „Code“ wie ein CPU-Schaltplan aussieht, ist es vielleicht an der Zeit, die Eignung der visuellen Programmierung für diese Aufgabe zu überdenken.
Auch visuelle Programmiersoftware ist in der Regel durch die Vorstellungskraft des Schöpfers in einer Weise begrenzt, die textuelle Programmiersprachen für allgemeine Zwecke nicht behindert.
Und doch haben uns Tools wie Visual Basic, Delphi und ihre Nachfahren gezeigt, dass die Erstellung von Software auf visuellem Wege enorm effizient sein kann; es gibt nur einen pragmatischen Kompromiss, bei dem manchmal handgeschriebener Code die richtige Lösung ist.
Superstars vs. Teams: Ein neues Leben für visuelle Programmiersprachen?
Die Anfänge der Programmierung waren hart, das steht fest. Aber eine einzige Person konnte alles verstehen und beherrschen, was für die Erstellung dieser Software notwendig war. Wenn Sie alt genug sind, denken Sie an die Softwaretitel der 1980er Jahre zurück. Damals war es üblich, dass ein einzelner Programmierer zu einer eigenen Marke wurde.
Sid Meier, Mitch Kapor und Jeff Minter erlangten ein gewisses Maß an Berühmtheit, indem sie im Alleingang oder höchstens mit einem weiteren Mitarbeiter bekannte Anwendungen oder Spiele entwickelten. Damals dauerten die Aktualisierungszyklen von Software und Hardware Jahre. Heute scherzen wir, dass es jeden Tag eine neue JavaScript-Bibliothek gibt. Dennoch ist an der Vorstellung etwas Wahres dran, dass die moderne Softwareentwicklung in einem Tempo voranschreitet, mit dem viele von uns nicht Schritt halten können.
Heute wird Software größtenteils von Spezialistenteams entwickelt. Während frühere Entwickler alles selbst gemacht haben, gibt es in einem modernen Software-Entwicklungsteam vielleicht nur noch eine Person, deren einzige Aufgabe darin besteht, sich um das CI-Tool zu kümmern. Entwickler verbringen ganze Karrieren damit, sich auf ein Framework oder eine Plattform zu konzentrieren. iOS-Entwickler sind iOS-Entwickler, keine Entwickler für mobile Geräte. Ein oder zwei Mal pro Jahrzehnt wechselt ein Webentwickler vielleicht sein bevorzugtes Framework. Nur sehr wenige Menschen schreiben professionell Assembler von Hand.
Es ist nicht nur so, dass sich der Umfang der Software verändert hat. Bis zu einem gewissen Grad haben sich auch die Entwickler selbst verändert. Software-Ingenieur ist heute ein ganz normaler Beruf. In den vergangenen Jahrzehnten war dies eine Leidenschaft einiger weniger Leute, die die Hingabe hatten, ein völlig neues System zu erlernen, um zum Beispiel die Atari ST-Portierung ihres erfolgreichen Amiga-Spiels zu schreiben. Aber das ist verständlich: Informatik ist keine Nische mehr.
Heute haben wir eine Welt, in der die Softwareentwicklung aus immer komplexeren Teilen besteht und in der die Entwickler gewöhnliche Menschen mit außergewöhnlichen Spezialisierungen sind. Diese Komplexität und Spezialisierung eignet sich schlecht für die rein visuelle Programmierung jener frühen Werkzeuge, macht es aber auch immer schwieriger, runde Softwareentwicklungsteams aufzubauen.
Wo reine visuelle Programmierumgebungen versagt haben, gibt es eine ganze Reihe ähnlicher Werkzeuge, die das Beste aus der visuellen Programmierung mit textbasierter Codierung kombinieren. Während die visuelle Programmierung „no-code“ war, sind diese neuen Werkzeuge „low-code“.
Werkzeuge wie OutSystems ermöglichen es Entwicklern, Software visuell zu erstellen, indem sie Interaktionsabläufe, Benutzeroberflächen und die Beziehungen zwischen Objekten zeichnen, dies aber mit handgeschriebenem Code ergänzen, wo es besser ist.
Diese pragmatische Mischung aus visueller Programmierung und textbasierter Programmierung ist gut für die Bedürfnisse der modernen Softwareentwicklung geeignet. Low-Code-Plattformen reduzieren die Komplexität der Softwareentwicklung und führen uns in eine Welt zurück, in der ein einzelner Entwickler reichhaltige und komplexe Systeme erstellen kann, ohne alle zugrunde liegenden Technologien erlernen zu müssen.
Nächste Generation der visuellen Programmierung: Delivering on the Promise
Die visuelle Programmierung war so vielversprechend und die Probleme, die sie lösen wollte, sind nicht verschwunden. Sie sind sogar aktueller denn je.
Aber die Probleme der realen Welt erfordern mehr Flexibilität, als die visuelle Programmierung bieten kann. Low-Code nimmt dieses Versprechen auf und wendet es an, um die Komplexität zu reduzieren, die wir in der modernen Softwareentwicklung vorfinden. Fragen Sie also nicht: „Was ist visuelle Programmierung?“ Fragen Sie stattdessen „Was ist Low-Code?“. Sie können auch eine Online-Demo vereinbaren oder OutSystems sogar ausprobieren (es ist kostenlos).