Warum ist programmieren nicht grafisch?

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.