Grafische Programmierung mit Zukunft ?

Mahlzeit zusammen,

bin in der Pause mal auf diesen Artikel gestoßen:

Hab das als ich mit Arduino C/C++ angefangen habe eher als Einsteiger-Software/Sprache gesehen
wie z.B. Scratch. Hatte es nicht als praxis-/industrietauglich empfunden.

Wie ist Eure Meinung zum Thema "Klötzchen hin und her ziehen" ?

Gruß
grillgemuese :slight_smile:

Meine Meinung ist da recht klar!

Die Betonung auf den "Datenfluss" begrüße ich ausdrücklich!
Wird z.B. hier im Forum gnadenlos unterbewertet.
Auch die anderen Sichtweisen.

Die Programmfluss Sichtweise, welche wohl die natürliche in C/C++ ist, wird häufig völlig überbewertet. Ja, sie ist wichtig, da natürlich für unsere Systeme. Aber verstellt oft den Blick auf den optimalen Lösungsweg.

Klarer:
Ich begrüße die alternativen Betrachtungsweisen, empfinde aber das Klötzchen kleben als künstliche Behinderung/Einschränkung.

Insbesondere, wenn man keine eigenen Klötzchen entwickeln kann, oder das extremen Aufwand bedeutet, dann nagelt man sich mit einem solchen System eine Frikadelle ans Knie.

Hallo,

also ich kann den GUI basierten Programm Creatern nichts abgewinnen. Das liegt aber eindeutig daran. Das ich gerne weis was der Code wirklich veranstaltet. Sketsh zu verwenden ist schon recht einfach. Da die meisten Sachen eher simple sind. Hoch Komplexe Regelungsverfahren kann man sowieso nicht wirklich mit so einem kleinen AVR und co realisieren. Daher ist diese Verwendung wie mit Kanonen auf Spatzen schießen. Ich verwende die Arduino Architektur seid Jahren in der Lift(Aufzug/Elevator) Technik an. Nicht für Sicherheitsrelevante dinge. Das meiste ist eigentlich sogar ohne einen MC realisierbar. Aber es ist einfach und schnell umzusetzen. Ich sehe keine Grund das Programmieren in solch abstrakten Ebenen zu führen. Das einzige das dadurch bewirkt wird. Das der Blick vom wesentlichen abgelenkt ist. Alles grösser und umständlicher wird. Hast du schon mal gesehen wie groß die bin Dateien sind die solcher Tools erzeugen. Auch sketsh ist nicht gerade klein. Und die meisten sind sogar so dreist und wandeln Ihre Innovation erst in C Code um, um dann einen Standard Compiller verwenden zu können. (Mutmaßung, da ich es noch nicht analysiert habe)

Aber jede soll verwenden was er führ angemessen findet.

Gruss Temucin alias TFT

grillgemuese:
.....
Wie ist Eure Meinung zum Thema "Klötzchen hin und her ziehen" ?
...

Ist es nicht so, dass Kinder gerne mit Klötzchen spielen ? :wink:

Jeder Mensch kann ein Problem auf diese oder jene Art und Weise besser verstehen. Für den einen ist der Ablauf in Textform schneller verständlich, für den anderen in grafischer Version. Ich denke beides hat seine Daseinsberechtigung. Jeder muss da seinen Weg finden.

Danke schonmal fuer Eure Meinungen! :slight_smile:

MaHa76:
...Für den einen ist der Ablauf in Textform schneller verständlich, für den anderen in grafischer Version...

Selbes darf ich derzeit in der Berufsschule durchleben. Einer meiner Lehrer fuer Automatisierungstechnik (TIA) steht total auf Grafcet, S7-Graf, FUP,...
In einer Klassenarbeit sollten wird dann eine Schrittkette programmieren (Prog.Sprache nicht vorgegeben), meine Wahl fiel sofort auf SCL, da fuer mich die Textform eben viel verstaendlicher ist als ein "Klötzchen geziehe".
Bloed war nur, dass ich meine Klausur mit besagtem Lehrer korrigieren musste da der Berufschullehrer nicht mit SCL umgehen konnte. :smiley:

Es wurde auf vielen Wegen bereits versucht grafische Formen der Programmerstellung und Programmgeneratoren zu etablieren.
Nach meiner Erfahrung schränken sie im Endeffekt ein und schaffen einen gehörigen Overhead. Das gilt um so mehr, wenn sie den Anspruch erzeugen allgemeingültig sein zu wollen.

Für spezielle Fälle hann man sich Programmgeneratoren für einen definierten Aufgabenbereich schaffen.

Das habe ich mal für eine GUI gemacht. Da wurden aus der Datentabellenbeschreibung (Create table) die GUI-Elemente und die grundlegenden Funktionen (incl. SQL) für Insert, Update, Delete, Select nach Key, Suche generiert.
Damit kann man schon Zeit sparen, wenn man für das Schreiben des Generators nicht mehr Zeit braucht, als für die generierten Inhalte. Da ging es aber nur um simplen stupiden Code.

Gruß Tommy

Hallo,

vor bereits etlichen Jahren(20 ?? ) kam etwas später als das ALW, KOP, FUP basierte Step5 , Graph 5 heraus. Das war eine graphische Variante zur Programierung von Schrittketten. In der Automobil Industrie war das hin und wieder Betandteil des Pflichtenheftes. Aber eigendlich hat sich das mangels fehlender Frexibilität nicht wirklich durchgesetzt.

ich selbst hab logische Verknüpfungen gern in KOP programiert , ist letzlich im Status übersichtlicher als bei AWL 0 und 1 abzuzählen. Aber natürlich immer dann wenn´s um Daten ging war AWL gesagt.

Seit ein paar Jahren nun sind die grossen SPS Hersteller wieder mit dem Begriff graphische Programmierung unterwegs. Un da wird zum Teil auch ganz stark damit geworben das bereits im Vertrieb eines z.B Maschinebauers die Hardware und Software für eine Maschine mittels click auf bestimmte virituelle Funktionsmodule und Baugruppen entstehen kann.

Das hört sich natürlich für inkompetente Entscheidungsträger supi an , ein click hier, ein click da und die teuren Hardware und Software Konstruktion ist überflüssig . Und Überhaupt geht ja auch alles viel viel schneller. :wink:

Natürlich ist das heute noch Zukunft, aber vor 30-35 Jahren konnte sich auch keiner vorstellen das man Schaltpläne und Konstruktionspläne anders als mit Schablone und Tusche machen kann und zum ändern ein Kratzmesser unumgänglich war.

Es wird also so kommen, irgendwann , da bin ich mir eigendlich ziemlich sicher. Dennoch werden dann Entwickler und Fachlkräfte benötigt die diese Systeme ent- und weiterentwickeln. Man kann das Rad nicht anhalten und zurück drehen. Das versucht ja gerade der alte Blonde. :slight_smile:

Gruß Heinz

Ob man einen Algorithmus nun grafisch oder in Textform umsetzt - es ist in beiden Fällen eine gehörige Abstraktion nötig. Welche Form einem eher liegt, ist wahrscheinlich individuell unterschiedlich.

Als ich meinen ersten Computer gekauft habe (ZX 81, ich wollte damals eigentlich nur wissen, was an diesen geheimnisvollen Dingern dran ist), habe ich rund 1 Woche gebraucht, um wirklich zu verstehen, was „programmieren“ bedeutet. Alles Weitere ging dann relativ schnell. Und über eine Fehlermeldung wie „Bildschirm voll“ („Fehler 4 in Zeile x“) kann ich mich heute noch schlapp lachen.

Gruß

Gregor

Das Klötzchen schieben war der Grund dafür, dass ich die LOGO8 ganz schnell wieder gestrichen haben. Ich will nicht unpassende "Klötzchen" durch die Brust ins Auge verbiegen um dann eine recht und schlecht passende Funktion zu gennerieren. Ich habe in der Enwicklung bis vor 30 Jahren mit Assembler gearbeitet. Damit konnte man jede Funktion aufs Tüpfelchen genau nach vorgabe programmieren, ohne irgendwelchen Unsinn passend machen zu müßen. Und deshalb bin ich jetzt bei C/C++ gelandet, weil ich mit dem LOGO Zeug beim Programmieren nen dicken Hals bekam. Sogar VisualBasic ist besser als diese unsinnige Klötzchen Programmierung von Siemens Logo.

Franz

Hallo

ZX81 das war doch ein scharfes Teil. ich hatte während meines Studiums 75-79 gegen Ende einen Video-Genie gekauft das war ein Tandy 80 Verschnitt. Rechts mit einem fest eingebauten Cassettenrecorder. Nein nicht für die Musik der war zum Speichern von Programmen und Daten gedacht. 8)

Heinz

gregorss:
Als ich meinen ersten Computer gekauft habe (ZX 81, ich wollte damals eigentlich nur wissen, was an diesen geheimnisvollen Dingern dran ist), habe ich rund 1 Woche gebraucht, um wirklich zu verstehen, was „programmieren“ bedeutet. Alles Weitere ging dann relativ schnell. Und über eine Fehlermeldung wie „Bildschirm voll“ („Fehler 4 in Zeile x“) kann ich mich heute noch schlapp lachen.

Das war damals mein erster Kontakt mit Computern. Da bin ich in einen Laden in München, an einen großen runden Tisch. Da waren so an die 10 ZX81 aufgebaut. An den Computern waren so 12 bis 14 jährige Burschen, die mir die ersten Basic Befehle beibrachten.
Also bin ich damit heim und es ging Schlag auf Schlag. Der Metalpapierdrucker, die 16k Speichererweiterung, größere Tastatur, paar Monate später die 64k Speichererweiterung, und damit der Ärger, wenn das Programm das man ja nur auf einer Musikkasette speicherte, nicht mehr leesbar war. Man musste sich dringend angewöhnen jedes Programm auf mehreren Kasetten zu speichern :slight_smile:

Dann kam der Tandy TRS80 Mod.II, Neupreis 13.000 DM gebraucht für 7.500 DM. Da gings dann mit Z80Assembler los. UNd dann kam bald der erste IBM kompatible, die XT´s dann die AT´s und ich sahs jeden Tag 10-16 Stunden an der Software Entwicklung. War eine Geile Zeit, aber lange her. Von da bis heute liegen zuletzt 26 Jahre schwere Krankheit die uns in den totalen finanziellen Ruin gebracht hat. Da war an Arbeit nicht mehr zu denken. Jetzt raple ich mich langsam wieder hoch, aber ich kann nicht mehr gewinnen, ich bin fast in Rente und wie die aussieht kann man sichvorstellen mit dieser langen Krankheit als Selbsstängiger :slight_smile:

Hi

... da wurde ich gerade erst materialisiert :o
Schneider CPC 464 mit Peek&Poke auf dem Bildschirm rumgespielt.
Eine Art Debug gab's Da auch zum Abtippen (hieß glaube Monitor), erste Berührungen mit Assembler :slight_smile:
Datasette war auch fest verbaut (Floppy, 3", gab's zum Monatslohn (oda so) - hat sich aber nicht durchgesetzt, die schlabberigen 5 1/4" waren mehr vertreten - wohl vom C64).

Aber: Wie auch schon geschrieben wurde: Wenn das Problem gelöst wurde, ist's recht egal, wie.
Auch ist's egal, wie viele Takte der µC wartet, solange Er die Arbeit schafft.
Wenngleich mir an Assembler sehr gut gefällt, daß jedes Bit gezielt bearbeitet wurde.
Was dort eher blöde ist, der Weg, bis man die Teilaufgabe durch hat, da man sich wirklich um jeden Furz selber kümmern muß.
Die Erfolge, Die ich in C++ auf dem Arduino bereits erzielen konnte, hätte ich in Assembler nie erreicht - naja, schadet ja nicht, wenn man weiß, daß das Steinchen intern etwas anders läuft.

Ob sich das graphische Programmieren durchsetzt, wird wohl zum Großteil daran liegen, ob die Industrie Das toll findet.

Ob's dann was taugt, steht auf einem anderen Blatt - wohl ähnlich wie 'Schreiben nach Gehör' die ersten zwei Jahre ... halte ich für großen Quatsch, einige Pädagogen sehen Das wohl anders.
(Gott sei's gedankt - für den Quatsch bin ich wohl zu alt)

Für den Arduino gibt's ja auch diverse graphische Oberflächen, wo ich Mal ein/zwei antesten wollte.

MfG

PS: Jupp, geile Zeit damals!!

Ich denke das Programmieren mit Klötzchen ist für einfache Anwendungen schon brauchbar und ermöglicht einen leichten einstieg. Bei allem wird aber vergessen, dass alle Bastelrechner eigentlich dafür gedacht waren, die Programmierung zu erleichtern und der breiten Masse näher zu bringen (so auch mir). Wenn man nun eine grafische Oberfläche mit tollen bunten Bildern verwendet, ist das zwar für wirklich blutige Anfänger besser geeignet bringt allerdings nichts bei der eigentlichen Erlernung einer Programmiersprache. Fazit, es wird etwas erfunden wie man Programmieren erlernt um dann etwas zu erfinden damit man nicht mehr programmieren lernen muss!

Wie Ihr schon alle schreibt, ist das nicht der erste Versuch programmieren zu "vereinfachen".
Das ist aber nur bedingt Sinn und Zweck. Vielmehr definiert das eine andere Zielgruppe.

Stellen wir uns die Sekretärin vor, die dem Chef in Excel ganz tolle Auswertungen "programmiert". Wenn, Dann, Sonst :slight_smile:
Wir belächeln das wohlmöglich als Könner eine Hochsprache. Jedoch ist das genau das richtige Werkzeug zwischen Einfachheit und Effektivität.
Nun ziehen wir den Elektriker heran, der eine Alarmanlage "programmieren" soll. Er verschiebt Blöcke, Verbindet Aktuatoren mit Sensoren und klickt sich ein einfaches "Wenn" dazwischen.
Er kommt, nach etwas Übung, schnell zu seinem Ziel!

Mittlerweile kann man sogar Android-Apps erstellen, ohne auch nur eine Zeile Code dafür schreiben zu müssen: App-Inventor.
Noch beeindruckender finde ich PowerApps von Microsoft.
Dort baut sich, basierend auf einer Datenquelle die App praktisch von selbst. Dann habe ich allerdings die Möglichkeit Excel-ähnlich Programmierungen durchzuführen. Einfach bis ziemlich komplex!
Das holt sowohl die Sekretärin als auch den Programmierer ab, da die Möglichkeiten zwischen "nur klicken" bis hin zu komplexen Programmierungen möglich sind.

Die "Wahrheit" liegt wie immer dazwischen! Wenn es mir die Arbeit vereinfacht, sie visuell verständlich darstellt und mich schnell zu Ziel führt, ist das eine gute Lösung!

Im Speziellen auf den Arduino bezogen, würde es den Programmierer verlangsamen und Möglichkeiten nehmen. Den Anfänger aber unterstützen.

Daher mag ich persönlich gerne Wizards. Dort kann ich erst ein bisschen was zusammen klicken und das System nimmt mir die Arbeit ab, ein paar rudimentäre Dinge zu erzeugen. Ab da lege ich dann wieder selbst Hand an :slight_smile:

TriB:
Daher mag ich persönlich gerne Wizards. Dort kann ich erst ein bisschen was zusammen klicken und das System nimmt mir die Arbeit ab, ein paar rudimentäre Dinge zu erzeugen. Ab da lege ich dann wieder selbst Hand an :slight_smile:

Wenn Du den generierten Code hinterher generell bearbeiten willst (der sieht meist grausam aus), dann kommst Du besser, wenn Du es gleich selbst schreibst. Du kannst dann auch nicht mehr ins Tool zurück, ohne Deine Codeänderungen zu verlieren.

Solche grafischen Tools sind nur dann "brauchbar", wenn sie ausreichend sind, das Ziel zu erreichen.

Gruß Tommy

Jein, Tommy :wink:
Es gibt solche und solche Tools. Wenn ich mich an Frontpage zurück erinnere, gebe ich Dir zu 120% Recht!
Der Overhead war grausam und der Code praktisch manuell nicht änderbar.

Aber z.B. VisualStudio nimmt einem mit den Projekt-Vorlagen immens viel Arbeit ab.
Der SQL-Reporting Wizard erzeugt aus einer Datenbasis eine grafische Oberfläche. Die muss immer noch angepasst werden, aber der Grundstock ist gelegt.
Die SQL-Datenbasis kann man sogar auch größtenteils grafisch erzeugen und zusammenklicken. Auch das ist bis zu einem gewissen Grad schneller und effektiver als alle Spaltennamen zu tippen und jedes JOIN ist mit einem Mausklick erstellt.
Sobald es komplexer wird, wechselt man zum Code. Dass dann ggf. die grafische Unterstützung nicht mehr funktioniert, stört mich persönlich nicht. Mir wurde initial Arbeit abgenommen und das reicht mir.

Es gibt auch Tools um aus UML Diagrammen Klassen- und Methoden-Rümpfe zu erzeugen. Dabei kann ein Computer nichts falsch machen

Ich finde die UML Bildchen in der Entwurfsphase ganz Klasse.

Bei der weiteren Arbeit reicht es, wenn sie groß ausgedruckt, für alle sichtbar, an der Wand hängen.

Wie schon gesagt: Ich begrüße alternative Sichten auf die Dinge.
Aber bei der Implementierung wird man doch eher den Programmfluss im Auge haben.

Ich komme gerade in den Genuss vom PSoC Creator von Cypress. Hier hat man sowohl grafische als auch Textprogrammierung. Grafisch nimmt man die Konfiguration der Hardware-Module vor (Pinzuweisung, DAC, ADC, PWM, Clock, Opamp,...), in der main.c Datei wie gewohnt den Programmablauf im eigentlichen Controller. Ich finde diese Trennung von Hard- und Software so ganz geschickt gemacht, gerade wenn es um das Thema Effizienzverbesserung geht...