Visuelle Programmiersprachen

Die meisten von uns haben das Programmieren mit "textuellen" Programmiersprachen wie Basic, C / C ++ und Java gelernt. Ich glaube, es ist natürlicher und effizienter für den Menschen, visuell zu denken. Die visuelle Programmierung ermöglicht Entwicklern das Schreiben von Programmen durch Manipulieren grafischer Elemente. Ich denke, die visuelle Programmierung sollte die Qualität des Codes verbessern und Programmierfehler reduzieren. Ich kenne einige visuelle Sprachen wie App Inventor , Scratch und LabView .

Warum gibt es keine allgemeinen Bildsprachen für Entwickler? Was sind die Vor- und Nachteile der visuellen Programmierung?

Im Allgemeinen gibt es einen Kompromiss zwischen Benutzerfreundlichkeit und Ausdruckskraft (Leistung) bei der Gestaltung von Programmiersprachen. Das Schreiben eines einfachen "Hello, world" -Programms in einer Anfängersprache wie Scratch oder App Inventor ist im Allgemeinen einfacher als das Schreiben in einer universellen Programmiersprache wie Java oder C ++, in der Sie möglicherweise zwischen mehreren Streams wählen können Ausgabe in verschiedene Zeichensätze, die Möglichkeit, die Syntax zu ändern, dynamische Typen usw.

Bei der Erstellung von App Inventor (an dem ich beteiligt war) bestand unsere Designphilosophie darin, die Programmierung für Anfänger zu vereinfachen. Ein triviales Beispiel war, unsere Array-Indizes auf 1 anstatt auf 0 zu setzen, obwohl dies die Berechnungen für fortgeschrittene Programmierer etwas komplexer erscheinen lässt.

Die Hauptmethode, mit der visuelle Programmiersprachen in der Regel für Anfänger entwickelt werden, besteht darin, die Möglichkeit von Syntaxfehlern auszuschließen, indem die Erstellung syntaktisch ungültiger Programme unmöglich gemacht wird. Beispielsweise können Sie in den Blocksprachen einen r-Wert nicht zum Ziel einer Zuweisungsanweisung machen. Diese Philosophie führt tendenziell zu einfacheren Grammatiken und Sprachen.

Wenn Benutzer anfangen, komplexere Programme in einer Blocksprache zu erstellen, stellen sie fest, dass das Ziehen und Ablegen von Blöcken langsamer ist als das Eingeben. Möchten Sie lieber "a * x ^ 2 + b * x + c" eingeben oder mit Blöcken erstellen?

Diesem Thema kann (zumindest von mir) in einigen Absätzen nicht gerecht werden, aber einige der Hauptgründe sind:

1. Blocksprachen sind in der Regel für Anfänger gedacht und daher nicht so leistungsfähig.
2. Es gibt keine schöne visuelle Möglichkeit, einige komplexe Konzepte wie Typensysteme, die Sie in allgemeinen Programmiersprachen finden, auszudrücken.
3. Die Verwendung von Blöcken ist für komplexe Programme unhandlich.

Warum gibt es keine allgemeinen Bildsprachen für Entwickler? Was sind die Vor- und Nachteile der visuellen Programmierung?

Visuelle Sprachen neigen dazu, drei große Kategorien zu durchbrechen:

1. Tools, die keine Programmierer sind, um grundlegende Automatisierungsaufgaben auszuführen. Denken Sie an Automator auf dem Mac.
2. Lernumgebungen, in denen es nicht praktisch ist, viel zu tippen, oder in denen die Struktur des Programms, die den logischen Ablauf anzeigt, wichtig ist. Denk an Scratch, Alice usw.
3. Das angesprochene Problem ist ein Datenflussproblem, und die Lösung des Problems wird durch eine Art Datenfluss zwischen in sich geschlossenen Boxen, die die physische Welt imitieren, gut modelliert. LabView und Ableton kommen beide in den Sinn.

Der Vorteil der visuellen Programmierung besteht darin, dass Sie einen umfassenden Überblick über die Systemstruktur erhalten. Dies führt zu dem unmittelbaren Problem, dass Ihr Spaghetti-Code, wenn Sie detailliert werden, wirklich wie Spaghetti aussieht . Eine übliche Komponente visueller Sprachen ist eine Art Codeblock oder Konfigurationskomponente für das visuelle Element. Das Problem ist, dass der Programmierer getrennte Codeblöcke verstehen muss, die auf seltsame Weise miteinander verbunden sein können.

Während an der visuellen Programmierung nichts auszusetzen ist, kann es sein, dass dies für die meisten Aufgaben einfach kein guter Ansatz ist.

Es gab zahlreiche visuelle Programmiersprachen, wie die folgenden zwei Bibliografien zeigen werden: vlib.org und oregonstate.edu .

IMHO haben sie es nicht geschafft, Fuß zu fassen, weil sie zwar gut für Spielzeugbeispiele sind, aber nicht die verschiedenen Ebenen der Abstraktion, Darstellung und Granularität verwalten können, die für große Projekte erforderlich sind. Sie müssen sich ein System wie AutoDesk Revit ansehen (ein Verwaltungssystem für Gebäudeinformationen, das von Architekten und Ingenieuren verwendet wird), um zu sehen, wie komplex die Verwaltung visueller Informationen werden kann.

Anstatt sich mit der allgemeinen Programmierung zu befassen, gelingt die visuelle Programmierung am ehesten als Konfigurationswerkzeug in speziellen Bereichen.

Text ist visuell.

Wir verwenden alle Arten von visuellen Hinweisen in unserem Code. Jede Verwendung von Leerzeichen (Einrückungen, neue Zeilen, Leerzeilen, Zeilenabstände) zielt darauf ab, visuelle Hinweise für die Funktionalität des Codes zu geben. Wir verwenden alle Arten von Syntax, um visuelle Informationen darüber zu liefern, was Code tut. Unsere Redakteure färben unseren Code, um ihn hervorzuheben.

Mathematik ist textuell. Es gibt alle Arten von Notationen, aber am Ende geht es im Grunde genommen um Text. Sie haben seit Hunderten von Jahren zu tun.

Mein Punkt: Die textuelle Darstellung von Code nutzt die visuellen Fähigkeiten, die Menschen haben. Wir können es wahrscheinlich besser nutzen, aber nicht, indem wir auf Text verzichten.

[Für die PDF-Version dieser Antwort sind die Abbildungen oder Diagramme interaktiv und dynamisch.]

Netzelemente und Anmerkungen: Eine visuelle Programmiersprache für allgemeine Zwecke

Ich verwende Grafiken, um JavaScript ™ -Programme zu organisieren, die die Acrobat® / JavaScript-API verwenden. Jedes Grafikobjekt repräsentiert ein Petri-Netz-Element (Ort, Übergang, Eingabe oder Ausgabe) oder repräsentiert mehr als ein Petri-Netz-Element. Jedes Grafikobjekt ist eigentlich eine Annotation des entsprechenden Netzelements. Wenn jedoch jedes Grafikobjekt einem und nur einem Netzelement zugeordnet ist, kann es zum Generieren des Netzelements verwendet werden. Wenn ein Grafikobjekt auf mehr als ein Netzelement abgebildet wird und das Mapping genau definiert ist, kann es auch zum Generieren der Netzelemente verwendet werden. Standard-Petri-Net-Elemente werden durch bestimmte Arten von Grafiken dargestellt: Ein Kreis ist ein Ort, ein Quadrat oder ein Rechteck oder eine Linie ist ein Übergang, ein Pfeil von einem Kreis zu einem Quadrat ist eine Eingabe und ein Pfeil von einem Quadrat zu einem Kreis ist eine Eingabe Ausgabe. Außerdem,

[Die Arten von Anmerkungen in einem "Standard-Petri-Netz" finden Sie in der PDF-Version dieser Antwort.]

Carl Adam Petri beschrieb die meisten dieser Ideen (einschließlich der Arten von Annotationen in einem "Standard Petri Net" in seiner Dissertation (Petri, 1966). Er wandte die Netzelemente und Annotationen auch auf die Beschreibung mehrerer Logikschaltungen an, wie z 6.

Vorteile und Herausforderungen

Eine visuelle Programmiersprache kann einem Computerprogrammierer helfen, Computerprogramme zu entwickeln (Menzies, 2002).

Ich habe mindestens drei Gründe, warum ich Netzelemente und Anmerkungen nützlich finde (Vorteile?).

Grund genug. Die Prozesslogik kann jeweils ein Element erstellt werden. Dies bedeutet, dass ein Netz durch Hinzufügen von Elementen zum vorhandenen Netz erweitert werden kann (Petri, 1966). Beispielsweise kann ein Modell eines Controllers in interne und externe Komponenten unterteilt werden. Die interne Komponente regelt das System. Die externe Komponente ist mit der Umgebung verbunden, indem sie Eingaben von der Umgebung akzeptiert. Abbildung 1 zeigt ein Petri-Net-Modell der internen Komponente. Sie können dem Petri-Net-Modell der internen Komponente ein Petri-Net-Modell der externen Komponente hinzufügen, indem Sie die entsprechenden Stellen und Übergänge hinzufügen (Abbildung 2).

Abbildung 1 Ein Petrinetzmodell einer internen Komponente eines Controllers (Halloway, Krogh und Giua, 1997)

Abbildung 2 Ein Petrinetzmodell einer internen und externen Komponente eines Controllers (Halloway, Krogh und Giua, 1997)

Zweiter Grund. Die jedem Netzelement zugeordneten Codes können aus mehr als einer „Programmiersprache“ stammen (Petri, 1973). Sie können aus einer Computersprache wie JavaScript, COBOL, ADA und einer Assemblersprache stammen. Sie können aus einer mathematischen Sprache wie algebraischen Symbolen stammen. Sie können aus Prosa stammen, die in Englisch, Deutsch, Französisch, Griechisch, Tagalog, Chinesisch usw. codiert ist. Sie können daher als Grundlage für die Kommunikation und Zusammenarbeit während des gesamten Lebenszyklus der Software- oder Systementwicklung verwendet werden. und unter verschiedenen Benutzern, Entwicklern und Interessengruppen (Petri, 1973).

Dritter Grund. Es ist möglich, sich auf bestimmte Grafikobjekte im Netz zu konzentrieren und die Code- oder Logikanmerkungen für die zugehörigen Grafikobjekte zu schreiben. Betrachten Sie ein Petri-Netz-Modell eines Kartenspiels in Abbildung 3. Wenn der Pfeil für die Eingabe P7  T4 eine Standardgrafik für eine Eingabe in einem Orts- / Übergangsnetz ist und wenn m_7 die Markierung für den Ort P7 ist, dann die logische Anmerkung für Das Aktualisieren der Marke des Eingabeorts ist m_7 = m_7-1. Wenn s_9 ^ - der Status des Eingangs ist, lautet die logische Anmerkung zum Aktualisieren des Status des Eingangs s_9 ^ - = ((m_7 <1)? False: true).

Abbildung 3 Ein Petri Net-Modell eines Kartenspiels

Ich habe mindestens drei Gründe, warum ich die Anwendung von Petri-Netzen als schwierig empfinde (Nachteile?)

Wenn zu viele Grafikobjekte vorhanden sind, ist es schwierig, das Netz zu erstellen oder zu lesen. Die Schwierigkeit kann gemindert werden, indem eine Teilmenge der Grafiken genommen und mit einem, zwei oder drei Grafiksymbolen dargestellt wird (Noe, 1973; Petri, 1966). Wenn beispielsweise das Petri-Net-Modell eines Kartenspiels in Abbildung 3 zu viele Grafikobjekte im Diagramm enthält, können einige der Grafiken kombiniert werden, und es bleiben immer noch genügend Informationen, um das Diagramm in ein Computerprogramm abzubilden. Betrachten Sie Abbildung 4, ein Petri-Net-Modell desselben Spiels aus Abbildung 3 mit Grafiken auf hoher Ebene (Chionglo, 2016a).

Abbildung 4 Ein Petri-Netz-Modell eines Kartenspiels mit High-Level-Grafiken (Chionglo, 2016a)

In einem anderen Beispiel können die externen Komponenten des Controllers in Abbildung 2 kombiniert werden, um eine übersichtlichere grafische Darstellung zu erstellen, wie in Abbildung 5 dargestellt.

Abbildung 5 Ein Petri-Netzmodell eines Controllers mit High-Level-Grafiken für externe Komponenten

Schließlich kann eine sich gegenseitig ausschließende Menge von Stellen oder eine sich gegenseitig ausschließende Menge von Übergängen auch unter Verwendung eines Grafikobjekts auf hoher Ebene dargestellt werden (Chionglo, 2015).

Zweiter Grund. Selbst bei Standardgrafiken kann es schwierig sein, Grafiken zu zeichnen und zu positionieren, insbesondere wenn erwartet wird, dass das endgültige Diagramm benutzer- oder leserfreundlich ist. Zu den Entscheidungen für die Erstellung eines benutzer- oder leserfreundlichen Diagramms gehören: die richtige Anordnung der Grafikobjekte, die geeigneten Abmessungen der Zeichenfläche und Formen, die Krümmung der Pfeile, die Art der Pfeilspitzen, die Größe und die Schriftart des Texts, und die Wahl der Farben für Grafiken und Text.

Dritter Grund. Es ist einfach, Anmerkungen von Netzelementen auf geordnete Weise zu erstellen, da jede Anmerkung direkt oder indirekt mit einem Netzelement zusammenhängt. Es ist jedoch möglicherweise keine gute Idee, jede Anmerkung zusammen mit den Grafiken aller Netzelemente anzuzeigen, da das Diagramm möglicherweise zu viele Informationen enthält. Betrachten Sie beispielsweise ein Diagramm eines Petri-Net-Modells einer Logikschaltung, das Verweise auf alle Eigenschafts- und Logikanmerkungen enthält (Abbildung 6). [Das ursprüngliche Modell enthielt eine Testbedingung für den Status von für jeden Ausgang (Abbildung 31 auf Seite 78 von (Petri, 1966)); Die Testbedingung wurde hier weggelassen, da sie dem Originalmodell für die angegebene anfängliche Kennzeichnung entspricht. Somit hat jeder Ausgang eine logische Annotation zum Berechnen der Markierung des Ausgabeorts.]

Abbildung 6 Ein Orts- / Übergangsnetz mit Anmerkungen - basierend auf Abbildung 31, Seite 78 einer englischen Übersetzung von Petris Dissertation (1966)

Eine Möglichkeit, diese Herausforderung zu mindern, besteht darin, die im Modell verwendeten Anmerkungstypen zu identifizieren und Grafikobjekte zu definieren, die Anmerkungen dieser Typen enthalten (Petri, 1966). Wenn sich ein Petri-Net-Diagramm aus Grafikobjekten aus den Definitionen zusammensetzt, sollte die Interpretation dieser Objekte die "unsichtbaren" Anmerkungen enthalten. Abbildung 7 sollte als Standard-Petri-Netz interpretiert werden (Definitionen siehe Anmerkungen zu einem Standard-Petri-Netz). daher kann die logische Anmerkung in dem Diagramm weggelassen werden.

Abbildung 7 Ein Orts- / Übergangsnetz - basierend auf Abbildung 31, Seite 78 einer englischen Übersetzung von Petris Dissertation (1966)

Eine andere Möglichkeit, diese Herausforderung zu mindern, besteht darin, Formularansichten der Anmerkungen zu verwenden, um die Diagramme zu ergänzen oder zu ergänzen (Chionglo, 2016b; 2014). Die Ansichten können weiter in kleinere Ansichten unterteilt werden, und jede Ansicht kann angezeigt und ausgeblendet werden.

Verweise

Chionglo, JF (2016a). Eine Antwort auf „Wie entwerfe ich einen Zustandsfluss für ein Reaktions- / Redux-Kartenspiel?“ Bei Stack Overflow. Verfügbar unter https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_at_Stack_Overflow .

Chionglo, JF (2016b). Zwei Formularansichten eines Petri-Netzes. Verfügbar unter http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf .

Chionglo, JF (2015). Reduzieren der Anzahl der Netzelementgrafiken in einem Petri-Netzdiagramm mithilfe von Grafiken auf hoher Ebene. Verfügbar unter http://www.aespen.ca/AEnswers/WjTpY1429533268 .

Chionglo, JF (2014). Netzelemente und Anmerkungen für die Computerprogrammierung: Berechnungen und Interaktionen in PDF. Verfügbar unter https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .

Halloway, LE; Krogh, BH und Giua, A. (1997). Eine Übersicht über Petri-Net-Methoden für kontrollierte diskrete Ereignissysteme [elektronische Version]. Diskrete ereignisdynamische Systeme: Theorie und Anwendungen. 7. Boston: Kluwer Academic Publishers, S. 151 - 190.

Menzies, T. (2002). Evaluierungsprobleme für visuelle Programmiersprachen. In SK Chang (Hrsg.). Handbuch von Software Engineering & Knowledge Engineering, Vol. 2 Neue Technologien. World Scientific Publishing co. Pte. Ltd., S. 93 - 101.

Noe, JD und Nutt, GJ (1973). "Makro-E-Netze zur Darstellung paralleler Systeme", IEEE Transactions on Computers, vol. C-22, Nr. 8, August 1973, S. 718 - 727.

Petri, CA (1973). Konzepte der Netztheorie. In mathematischen Grundlagen der Informatik: Proc. of Symposium and Summer School, Hohe Tatra, 3. - 8. September 1973, S. 137 - 146. Math. Inst. der slowakischen Acad. of Sciences, 1973.

Petri, CA (1966). Kommunikation mit Automota [trans. CF Greene, Jr.]. Beilage I zum Technischen Bericht RADC-TR-65-377 (Band I). Griffiss Air Force Base, New York: Rome Air Development Center, Abteilung Forschung und Technologie, Kommando Luftwaffensysteme, Griffiss Air Force Base. Abgerufen am 31. August 2011 von http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf .

Johne Percival Hackworth :

Während an der visuellen Programmierung nichts auszusetzen ist, kann es sein, dass dies für die meisten Aufgaben einfach kein guter Ansatz ist.

Vielleicht waren die bisherigen visuellen Programmiersprachen einfach zu unausgereift? Die Vorstellung, dass fortgeschrittene Visualisierungen nicht auf Software-Artefakte angewendet werden können und dass es völlig der "Vorstellungskraft" jedes Entwicklers überlassen ist, eigene Visualisierungen zu erstellen, könnte eine falsche Annahme sein. Eine einheitliche und automatisierte Erhöhung der Abstraktionsebene ist naheliegend, solange die Fähigkeit zur Ausführung von Abstraktionen auf niedriger Ebene und eine hohe Ausführungsleistung nicht beeinträchtigt werden. Dies könnte letztendlich zu einer "Programmierung" von Domain-Experten führen, die sich nicht wesentlich von der Art und Weise unterscheidet, wie Tabellenkalkulationen die Aufgabe von COBOL-Programmierern automatisiert haben, Zahlen zu manipulieren. Der Hauptunterschied besteht darin, Zahlen durch die Manipulation "allgemeiner Systeme" zu ersetzen.

Sie können sich Programmierung ohne Codierungstechnologie (PWCT) ansehen.

PWCT ist eine allgemeine visuelle Programmiersprache, die die Entwicklung von Systemen und Anwendungen ermöglicht, indem interaktive Schritte generiert werden, anstatt Code zu schreiben.

Hier ist ein guter Ausgangspunkt und Open Source .

eine knifflige Frage. visuelle oder flussbasierte Programmierung wird zwar häufiger verwendet, ist jedoch im Vergleich zu allen Programmiersprachen nicht weit verbreitet. Wesentliche Faktoren sind Wartung und Standardisierung. Computercode kann auf Seiten gedruckt werden. Es ist nicht immer so klar, wie ein visuelles Programm gedruckt werden soll.

Im Gegensatz zur aktuellen Top-Antwort würde ich behaupten, dass es definitiv keine inhärente theoretische Einschränkung der visuellen Programmierleistung gegenüber Textsprachen gibt. Tatsächlich kann visuelle Programmierung als einfacher angesehen werden, wenn sie eines Tages auf der Grundlage einer schnelleren menschlichen Konzeptualisierung der vielen Abstraktionsebenen aufrechterhalten werden kann . es scheint also ein unverkennbares Element von sozialer / kultureller Trägheit / Konservativismus in seiner Aufnahme zu sein.

Die visuellen Editoren sind wahrscheinlich viel komplexer in ihrem Code, und dies ist beeindruckend, wenn man bedenkt, dass selbst textbasierte IDEs sehr komplex sein können, z. B. Eclipse . Beachten Sie, dass einige IDEs, wie z. B. Eciplse, Plugins für die visuelle Programmierung enthalten. Die visuelle Programmierung für die GUI-Erstellung ist mittlerweile ziemlich verbreitet.

Es scheint mir, dass der Einsatz von visueller Programmierung in ausgewählten Bereichen zunimmt und dass er in absehbarer Zeit häufiger wird.

Vergessen wir nicht, dass die visuelle Programmierung dem Design von EE- Chips seit Jahrzehnten inhärent ist, wo sie keine Abstraktion darstellt und (Sub-) Systeme in 2D-Designs genau wie vorgesehen angeordnet sind.

Das seit über einem Jahrzehnt verbreitete Lego Mindstorms-Kit verfügte seit jeher über eine Entwicklungssoftware, die auf visueller Programmierung basierte und nun in vielen Versionen erheblich optimiert wurde.

Hier ist ein interessanter aktueller Artikel, der die Geschichte und Perspektiven analysiert und darauf hinweist, dass dies bei der webbasierten Programmierung häufiger vorkommt. Das dynamische Layout von Steuerelementen / Widgets auf einer Seite ist eine Variante der visuellen Programmierung.

Ein weiterer Schlüssel- / aufstrebender Bereich, in dem es in vielen Tools weit verbreitet ist, ist BPM (Business Process Modeling).

• Wie eine arkane Codierungsmethode aus den 1970er Jahren die Vernunft von Webentwicklern überall retten kann (Fast Company)

• BPM, Geschäftsprozessmodellierung wikipedia

Ich vermute, der Grund, warum diese Lösungen nicht so beliebt sind, weil sie in den meisten Fällen unhandlich sein und zu einem Durcheinander werden können.

Fast alle heute verfügbaren visuellen Programmiertools sind Teil größerer Anwendungen und werden für einen bestimmten Zweck verwendet (z. B. Blueprint in UE4).

Jedenfalls ist Korduene ein neues Programm, das ich kürzlich für die allgemeine Programmierung kennengelernt habe. Es ist wirklich kein allgemeiner Zweck, da es sich eher um die Erstellung von Windows-Anwendungen handelt.

Ich denke, dass @Raphael und andere falsch liegen, wenn sie sagen, dass ein Programm Text ist. Ist es nicht. Es sind viele Dinge. Es sagt dem Computer, was zu tun ist oder wie es zu tun ist. (imperaktive, deklarative Programmierung) Die Assoziation der Programmierung mit der Textbearbeitung ist ein historisches und kontraproduktives Dogma. Welches durch die begrenzten Texteingaben / -ausgaben der frühen Computer verursacht wurde. Leute sind keine Textparser!

Während ich denke, dass die Leute Recht haben, dass eine vollständig visuelle Sprache (bei der Sie alles visuell tun, indem Sie Elemente mit der Maus verbinden und so weiter) für eine Allzwecksprache unpraktisch ist, denke ich, dass alle aktuellen Sprachen zu einer Zwischenstufe verschoben werden könnten und sollten Niveau. Wobei Sprachelemente eine visuelle Darstellung haben, die in einer binären Sprachdatei gespeichert wird. Der Programmierer würde keinen verrückten Text schreiben oder im Bann von Linien und Einrückungen leben.

Fügt jedoch Elemente über die produktivste Kombination von Tastenkombinationen / Befehlen / Benutzeroberflächenelementen ein. Und nur Zeichenfolgen und andere Daten und Bezeichner eingeben. Dies würde Syntaxfehler unmöglich machen und Sprachen mit Blick auf Sicherheit und Korrektheit (z. B. ADA) produktiver machen. Und würde auch andere sicherer und weniger fehleranfällig machen, indem ganze Klassen häufiger Fehler unmöglich gemacht würden. (Wie die, die ADA verhindert, indem sie umständlich ist)

Bis zu einem gewissen Grad gingen die Dinge in diese Richtung. Durch automatische Einrückung und Syntaxfärbung. Leider hat niemand gemerkt (oder sich genug darum gekümmert), dass es das Kernkonzept des "menschlichen Textparsers" ist, woran es liegt. Die Argumente zwischen Emacs und Vim sind lustig, weil beide falsch sind. Sie sind "Lösungen" für ein künstlich geschaffenes Problem.