Warum ist programmieren nicht grafisch?

Artchi

Es gab doch schon immer die Versuche grafisch zu entwickeln. Als ich damals (2000) von C++ nach Java gewechselt bin, wurde ich in der neuen Firma vor IBM VisualAge for Java gesetzt. Das Tutorial dazu war so aufgebaut, das man praktisch die Anwendung grafisch entwickelte. Weil die Komponenten in Java und Events doch sehr umfangreich waren, konnte man sich das zusammen setzen. Im Hintergrund wurde dann der Java-Code generiert.

Ich muss ehrlich sagen: ich habe diesen grafischen Editor gehasst! Und da ich wohl nicht der einzige war, gibt es diesen in der Form nicht mehr. Er wurde auf die bekannte GUI-Editor-Funktionen kastriert.

Was war das Problem? Ganz einfach: ich musste genauso viel wissen, wie und womit ich etwas zu entwickeln habe, als wenn ich es in Text verfasse. Dabei war das Mausschubsen und die ganzen Verbindungslinien umständlicher. Denn das grafische musste ich im Kopf logisch interpretieren. Und ich musste trotzdem Namen von Objekte, Listenern und Events als Schrift lesen und als Schrift vergeben.

D.h. ich habe am Ende nichts gewonnen. Für einfache Dinge ist ein grafisches Werkzeug gut geeignet. Aber sobald es komplexer wird, ist Text besser.

Ich kann mir auch nicht vorstellen, das man einen Spielfilm-Skript oder Cartoon-Skript grafisch "schreibt". Und das die Schauspieler oder Cartoon-Zeichner es dann grafisch interpetieren wollen. Die wollen bestimmt lieber Text lesen. Und der Drehbuchautor will es besser schreiben.

Für einen groben Ablauf sind aber Zeichnungen (UML) immer gut geeignet. Aber wie gesagt: grob.

dot schrieb:

Da es offenbar noch nicht deutlich genug gesagt wurde hier nochmal: UML ist keine graphische Programmiersprache...

Das habe ich doch bereits gesagt.
Es ergibt sich aus dem Kontext.

UML kommt am nähsten heran, und was man bei UML tun muss, würde auch auf eine grafishe Programmiersprache zutreffen.

Denn Bezeichner wird man wohl brauchen, wie ich auch zuvor schrieb.

dot schrieb:

Da es offenbar noch nicht deutlich genug gesagt wurde hier nochmal: UML ist keine graphische Programmiersprache...

Es ist aber scheinbar das einzige was er kennt.

dot

So siehts aus schrieb:

UML kommt am nähsten heran [...]

Öh, am nähesten heran an was?

So siehts aus schrieb:

[...] und was man bei UML tun muss, würde auch auf eine grafishe Programmiersprache zutreffen.

Um, bin mir net sicher was du meinst. Zeig mir doch mal, wie man deiner Meinung nach einen Bubble Sort in UML programmieren würde...

Vor allem ist UML nicht auf Klassenmodellierung begrenzt...

dot schrieb:

So siehts aus schrieb:

UML kommt am nähsten heran [...]

Öh, am nähesten heran an was?

So siehts aus schrieb:

[...] und was man bei UML tun muss, würde auch auf eine grafishe Programmiersprache zutreffen.

Um, bin mir net sicher was du meinst. Zeig mir doch mal, wie man deiner Meinung nach einen Bubble Sort in UML programmieren würde...

Doof?
Habe ich etwa gesagt, daß UML eine Programmiersprache wäre?
Lies nochmal oben.

Es geht darum:
Klassenzuammenklicken in UML -> geht

ABER

Klassen, Attribute usw. mit Bezeichnern bennennen in UML -> geht zwar, aber erfordert nen switch von Maus zu Tastatur und bei grafischen Programmiersprachen wird das nicht anders sein.
Es sei denn, wie vor Stunden vorher bereits gesagt, man muss keine Bezeichner geben und klickt alles zusammen, aber dann gibt's auch die nächsten Probleme, die ich bereits erwähnt habe.

Tim schrieb:

dot schrieb:

Da es offenbar noch nicht deutlich genug gesagt wurde hier nochmal: UML ist keine graphische Programmiersprache...

Es ist aber scheinbar das einzige was er kennt.

Du kennst gar nichts, wie du bereits mit deinem smily gezeigt hast.

So siehts aus schrieb:

Du kennst gar nichts, wie du bereits mit deinem smily gezeigt hast.

Vielleicht hast du den Smiley falsch interpretiert?

Tim schrieb:

So siehts aus schrieb:

Du kennst gar nichts, wie du bereits mit deinem smily gezeigt hast.

Vielleicht hast du den Smiley falsch interpretiert?

Das ist unwahrscheinlich, denn sonst wärst du dumm.
Bashar hat dir schließlich ne konkrete Frage gestellt und dann mit nem Smily zu antworten, wenn man etwas wüßte, würde von Dummheit zeugen.

Da ich dir aber keine Dummheit unterstellen möchte, interpretiere ich das korrekterwesie als eine Antwort die besagt dass du schlichtweg keine Erfahrung in grafischen Programmiersprachen hast.
Dies geht auch mit dem Rest deiner Beiträge hier in diesem Thread überein, denn anscheinend bohrst du mir und anderen Löchern in den Bauch, das zeugt von Neugier mit der du sagst, daß du keine Erfahrung mit grafischen Programmiersprachen hast und nun durch solche Fragen gerne mehr wissen würdest in der Hoffnung, daß es hier User gibt, die sich damit wesentlich besser auskennen.
Da bist du sehr durchschaubar, also mach dir keine falsche Hoffnungen daß ich von dir annehmen würde, daß du von grafischen Programmiersprachen viel Ahnung hättest.

Hint: Bashar hat durchaus eine Ahnung was ich beruflich so benutze.

Bashar

Tim schrieb:

Hint: Bashar hat durchaus eine Ahnung was ich beruflich so benutze.

Ja, aber ich meinte die Frage schon ernst. Ob du über Simulink hinaus -- was ich nicht als Programmiersprache ansehe -- Erfahrungen mit graphischer Programmierung hast.

Nö. Aber nun die obligatorische Frage: Warum ist SL für dich keine Programmiersprache? Ich fürchte ich kenne die Antwort schon.

Bashar

Naja, wie würdest du denn einen Bubble-Sort in Simulink realisieren? Vielleicht geht es ja sogar mit einem hirnkrebserzeugenden Gewirr aus Iteratoren und Assignmentblöcken, aber normalerweise nutzt man mit Simulink nur für spezielle Anwendungen (Signalverarbeitung.)

Bubblesort (oder ähnliche Konstrukte) würde ich logischerweise nicht in SL oder SF implementieren, sondern entsprechend einbinden (S-Function, Custom-Code, ...).
Sicher ist Simulink eine Sprache mit einem stark eingeschränkten sinnvollen Einsatzbereich, aber gilt sie deswegen nicht mehr als "Programmier"sprache?

Mechanics

Tim schrieb:

Bubblesort (oder ähnliche Konstrukte) würde ich logischerweise nicht in SL oder SF implementieren, sondern entsprechend einbinden (S-Function, Custom-Code, ...).
Sicher ist Simulink eine Sprache mit einem stark eingeschränkten sinnvollen Einsatzbereich, aber gilt sie deswegen nicht mehr als "Programmier"sprache?

Ich denke, das ist auch das typische Problem von grafischen Programmiersprachen. Es ist nicht leicht, eine sinnvolle allgemein verwendbare grafische Programmiersprache zu definieren. Man kann sehr gut spezialisierte Sprachen entwerfen, wo man Lösungen für konkrete Probleme sehr schnell und einfach zusammenklickt. Aber wenn die Sprache allgemein sein soll, wie C oder C++, gehen die Vorteile schnell verloren und es wird noch umständlicher, als den Code einzutippen.

Dem würde ich so zustimmen.

rüdiger

Wie ich bereits am Anfang der Diskussion gesagt habe, sind SL und LV wirklich nur für spezielle Dinge geeignet. Niemand würde damit "gewöhnliche" Programme programmieren. LabView ist halt praktisch für Laborassistenten, weil die da nicht groß programmieren können müssen und sie damit in Software das machen können, was sie beim Versuchsaufbau mit der Hardware schon machen: Fertige Komponenten zusammen stecken. Mit SL schaut es ja ähnlich aus, nur dass dies für Signaläffchen gedacht ist :p.

Also sobald es nur darum geht fertige Komponenten zu verbinden, kann man mit grafischer Programmierung einen Vorteil haben. Dabei muss es ja nicht unbedingt um die Entwicklungsgeschwindigkeit gehen, es kann auch einfach übersichtlicher bzw. der Domäne besser angepasst sein und es erlaubt je nachdem einen leichteren Einstieg.