Warum ist programmieren nicht grafisch?

giftigerWilli

Hallo

ich habe noch nie irgendetwas programmiert. Jedoch habe ich mit Audioprogrammen wie Cubase oder Photoshop schon Sachen hergestellt. Und Programme wie diese haben im Gegensatz zu Programmiersprachen diese grafische Oberfläche, warum haben dies Programmiersprachen nicht? Ich meine angenommen ich möchte eine Audiospur in Cubase laden, da muss ich doch keinen Code irgendwo reinschreiben damit das Programm dies tut. Oder wenn ich in Photoshop einen einfachen Filter wo drüberlaufen lasse muss ich keine Codes wo einfügen. Meine Fragen an euch Profis hier ist also, wo ist mein Denkfehler, dass es noch keine Programmiersprache gibt welche so einfach zu bedienen wäre wie die oben genannten Programme, sozusagen per Knopfdruck erledigt sich ein Code irgendwo und du musst nichts mit deiner Tastatur programmieren. Würde so etwas gehen?

Hier: http://blockly-demo.appspot.com/blockly/demos/maze/index.html

Viel Spaß damit...

PS: Vielleicht solltest du dir mal ein Programmierbuch in die Hand nehmen und dir selbst ein Bild machen, wie komplex das ist. Willst du dieselben Programmiermöglichkeiten graphisch haben, braucht es ungefähr dieselbe Komplexität, ergo kann man es gleich bleiben lassen.
Um Komplexität zu verstecken, geht man ganz andere Wege:
- Frameworks
- Neue Programmierparadigmen
- Patterns
- Neue Programmiersprachen
- etc.

Mechanics

Man sieht doch schon am Nickname, dass es ein Troll ist.

Ein Troll der sich registiert?

redrew99

Die Komplexität dürfte in der Tat der Grund sein, warum das nur sehr schwer umzusetzen sein wird.

Aber wenn man mal anfängt zu spinnen und sich vorstellt in ferner Zukunft mit
Hologrammen und Gestensteuerung arbeiten zu können ist "grafisches" Programmieren
in 3D vielleicht durchaus möglich.

rüdiger

Gibt es doch: LabVIEW und Simulink sind sogar relativ weit verbreitet. Aber die eignen sich eben nur für bestimmte Problemstellungen. Versuch mal mit denen ein gewöhnliches Programm zu entwickeln und du weißt, warum das ganze nicht funktioniert.

dot

giftigerWilli schrieb:

Und Programme wie diese haben im Gegensatz zu Programmiersprachen diese grafische Oberfläche, warum haben dies Programmiersprachen nicht?

Aus dem selben Grund, aus dem du als Musiker heutzutage immer noch Noten liest/schreibst und kein Videotutorial darüber, welche Taste, wann, wie schnell und für wie lange gedrückt werden muss

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?