Warum ist programmieren nicht grafisch?

giftigerWilli

Komplexität zu reduzieren ist wohl das Wichtigste, damit würden sich wohl noch mehr mit Programmieren beschäftigen, daher hätte ich eine einfache graphische Benutzeroberfläche für Anfänger traumhaft gefunden. Jedoch war es mit Cubase oder Photoshop auch ein Lerneffekt der nötig ist sich mit dem Prog auseinanderzusetzen. Ergo kann man sagen, wenn man das programmieren wirklich lernen will sollte es einem egal sein ob es grafisch ist oder nicht, denn das Ziel treibt dich an.

cooky451

Ich würde nicht sagen, dass das unbedingt etwas mit der Komplexität zu tun hat. Es bringt nur einfach keine Vorteile gegenüber Text. Wie willst du ein if darstellen? Schleifen? Funktionsaufrufe? Klassen und Variablen gingen noch, aber sobald man Code hat der etwas "tut" sehe ich da irgendwie keine Alternative..

Bashar

cooky451 schrieb:

Wie willst du ein if darstellen? Schleifen? Funktionsaufrufe?

Versteh ich den Witz nicht? Es gibt sogar eine versch... DIN-Norm, wie man diese Konstrukte in einem Programmablaufplan darzustellen hat.

Ansonsten siehe z.B. http://drakon-practic.ru/

cooky451 schrieb:

Ich würde nicht sagen, dass das unbedingt etwas mit der Komplexität zu tun hat. Es bringt nur einfach keine Vorteile gegenüber Text. Wie willst du ein if darstellen? Schleifen? Funktionsaufrufe? Klassen und Variablen gingen noch, aber sobald man Code hat der etwas "tut" sehe ich da irgendwie keine Alternative..

Die Frage des TS ist durchaus berechtigt.

Denn Flussdiagramme hat hier doch sicher jeder von uns schon einmal gesehen.
Und damit lassen sich Schleifen, If Anweisungen, Funktionsaufrufen usw. perfekt abbilden.

Problematisch könnte es bei Zeigern und Klassen werden.

Und der Grund warum man das nicht macht dürfte der sein, daß grafisches Programmieren in der Tat keine Vorteile bringt.
Denn selbst wenn man die Symbole wie man sie von Flussdiagramen kennt, zusammenklickt, muss man einen Funktionsaufruf ja trotzdem noch mit Parametern und Rückgabeweren füttern und bei Funktionszeigern wird's dann noch komplexer.

Ein Editor würde den Nutzer also ständig zwischen der Maus und Tastatur wechseln lassen, für jede Kleinigkeit.
Da ist es dann doch schon bequemer, einfach alles als Text niederzuschreiben.

Eine Programmiersprache deren Programme komplett grafisch erstellt werden, dürfte es also gar nicht zulassen, daß die Symbole Bezeichner tragen dürfen.
D.h. die grafische Oberfläche müßte intern dafür Sorgen, daß die Symbole automtisch bezeichnet werden.
Dann könnte man in der Tat nur noch mit der Maus herumklicken und Pfeile von A nach B ziehen.

Das eigentliche Problem dabei wäre nur, daß es dadurch auch nicht leichter wird, denn dann wüßte man auf den ersten Blick nicht, was das ein oder andere Flussdiagramm genau tut.

So siehts aus schrieb:

Das eigentliche Problem dabei wäre nur, daß es dadurch auch nicht leichter wird, denn dann wüßte man auf den ersten Blick nicht, was das ein oder andere Flussdiagramm genau tut.

Nachtrag:

Im Prinzip wäre das so wie bei elektrischen Schaltplänen, da sieht man zwar alle Bausteine, aber was der Schaltplan oder Bereiche daraus genau macht, ist auf den ersten Blick gar nicht ersichtlich.

Bei Programmcode hat man deswegen Bezeichner, dadurch ist klar, was ne Klasse oder eine Funktion genau macht.

Insofern Grafische Programmiersprachen bringen keine Vorteile.
Umsetzen könnte man das zwar, aber es wäre sinnlos und umständlich in der Anwendung.

Fedaykin

Es gibt genügend Frameworks die das Programmieren "Grafisch" machen. UML-Tools gibts mit Codeerzeugung, Struktogramme mit Codeerzeugung. In der Automatisierung gibts sowas wie MCC als mögliche "Sprachen" https://eb.automation.siemens.com/goos/Catalog/Pages/ProductData.aspx?tree=CatalogTree&region=ch&nodeid=10001189&language=de&activetab=&sc=True&regionUrl=/#activetab=product&
Man kann also nicht sagen das es dafür nichts gibt.
Für den Typischen Coder ist das ganze meist nur umständlicher als den Code direkt einzugeben. Ganz zum schluss kommt ohnehin nur ein Formaler Algorithmus raus. Egal ob der irgendwie Grafisch, Textuell oder Sonstwie beschrieben wurde.

So siehts aus schrieb:

Insofern Grafische Programmiersprachen bringen keine Vorteile.

Wieviele kennst du denn? Mit wievielen davon hast du bereits gearbeitet? Wie definierst du "Vorteil" in diesem Kontext?

Tim schrieb:

Wie definierst du "Vorteil" in diesem Kontext?

Einen Vorteil würde ich so definieren:

1. in dem man eine Zeitersparnis hat
oder
2. mehr Überblick hat

Fedaykin schrieb:

Es gibt genügend Frameworks die das Programmieren "Grafisch" machen. UML-Tools gibts mit Codeerzeugung,

UML Tools würde ich jetzt aber nicht als grafische Programmiersprache oder grafische Programmierung betrachten, denn auf die Codeebene in Textform muss man bei UML sowieso, insofern ist UML lediglich eine grafische Ergänzung.

Für den Typischen Coder ist das ganze meist nur umständlicher als den Code direkt einzugeben. Ganz zum schluss kommt ohnehin nur ein Formaler Algorithmus raus. Egal ob der irgendwie Grafisch, Textuell oder Sonstwie beschrieben wurde.

Genau so ist es.

So siehts aus schrieb:

Tim schrieb:

Wie definierst du "Vorteil" in diesem Kontext?

Einen Vorteil würde ich so definieren:

1. in dem man eine Zeitersparnis hat
oder
2. mehr Überblick hat

Und auf welcher Basis argumentierst du, dass dies nicht zutrifft?

Tim schrieb:

So siehts aus schrieb:

Tim schrieb:

Wie definierst du "Vorteil" in diesem Kontext?

Einen Vorteil würde ich so definieren:

1. in dem man eine Zeitersparnis hat
oder
2. mehr Überblick hat

Und auf welcher Basis argumentierst du, dass dies nicht zutrifft?

Das habe ich oben bereits beschrieben.

Also auf Basis von Annahmen und nicht Erfahrung. Oder anders ausgedrückt: Keine Ahnung kann durch eine dedizierte Meinung kompensiert werden.

Bashar

Tim, worauf willst du eigentlich hinaus? Hast DU denn Erfahrung in graphischen Programmiersprachen?

Tim schrieb:

Also auf Basis von Annahmen und nicht Erfahrung. Oder anders ausgedrückt: Keine Ahnung kann durch eine dedizierte Meinung kompensiert werden.

Also im Vergleich zu UML Programmen bin ich schneller, wenn ich die Klasse einfach so in den Editor reinhaue.

Insofern dürfte das übertragen auf grafische Programmiersprachen nicht anders sein und all das, aus den von mir bereits genannten Gründen, diese basieren nämlich auf Erfahrung mit UML Programmen.

dot

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

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...