Scratch - Programmieren nun kinderleicht!

[Mog]

Ach, es gibt schon brauchbare, graphische Programmiersprachen. Gerade in der Elektrotechnik ist es sehr schön, wenn man auf Schaltungsebene seine Module zusammen klicken kann, und sie per Klick simuliert, und danach gleich seine Fabrik damit automatisiert.

Angeblich gibt es sogar Leute, die bekommen das übersichtlich hin, in dem sie die eigenartigen Modul-Funktionen einmal durchklickt haben. Mit den noetigen Tastaturkuerzeln, geht das bestimmt auch recht geschwind.

Programmieren kann man ja auch etwas über "Wenn, dann, springe" hinaus abstrahieren.

[Ineluki]

Natuerlich ist der Graphische-Nodes Ansatz der Programmierung moeglich. Ich persoenlich halte ihn aber fuer unuebersichtlich und der eigentlichen Textuellen Programmierung fuer unterlegen.

Begruendung:

Die Verknuepfung der Nodes unternander (also die Verknuepfung von Autput eines Nodes mit Input eines anderen Nodes) ist ja nichts anderes, als eine Variable, genauer zu sein, eine temporaere unbenannte Variable. Diese kann aber eigentlich nichts, was nicht benannte Variablen auch oder sogar besser koennen. Und gerade die Arbeit mit Rekursion, Operatoren, Functoren, Zeigern oder dynamischen Arrays etc ist in der Node-basierten Programmierung unglaublich verwirrend.

Die Node.basierte Programmierung ist einfach wesentlich einschraenkender als die textuelle Programmierung und ist zudem sehr unuebersichtlich. Mit entsprechenden Tools in IDEs ist die Arbeit mit Text nicht nur viel schneller (man schreibt einfach schnell, was man will, anstatt es sich zusammenzuklicken), sondern auch uebersichtlich, da man auch hier ganze Funktionsbloecke zusammenklappen kann, wenn sie einen nicht interessieren, oder die Verknuepfungen unter den Funktionen sehen kann, weil man eine Liste bekommt, von wo die Funktion aufgerufen wird, oder welche Aufrufparameter eine Funktion hat.

[Mog]

...

...

Ein Chemiker deines Ranges hat doch bestimmt schon einmal mit Rückkoppelungen in elektrischen Schaltkreisen zu tun gehabt, oder? So unübersichtlich ist das doch gar nicht

Gerade beim -- ich habe de Namen noch nicht genannt -- LabView ist der andere Zugang fuer eine sehr grosse Menge an Usern wichtig und entscheidend.

Je nach Background unterscheidet sich eben doch sehr stark, was gerade gut ist bzw. nicht gut.


Mir faellt allerdings nebenbei ein nettes Tool ein, dessen Namen mir aber entfallen ist: Damit kann man komplexe Multimedia-Pipes graphsich zusammen klicken, so wie div. Datenbankdiagramme, oder klassische RADs, und diese einfach im Programm flexibel laden, anstatt sie selber zu kodieren. Finde ich erstklassig. So etwas sollte es oefters geben, um gezielt Teilprobleme zu lösen. *Kratzt

[Ineluki]

Ein Chemiker deines Ranges hat doch bestimmt schon einmal mit Rückkoppelungen in elektrischen Schaltkreisen zu tun gehabt, oder? So unübersichtlich ist das doch gar nicht

Gerade beim -- ich habe de Namen noch nicht genannt -- LabView ist der andere Zugang fuer eine sehr grosse Menge an Usern wichtig und entscheidend.

Je nach Background unterscheidet sich eben doch sehr stark, was gerade gut ist bzw. nicht gut.

...

Nein, hatte ich noch nie was mit zu tun, und ich kenn auch keinen, der mit sowas zu tun hatte ...

Aber wo wir gerade bei Schaltungen waren ... VHDL hat auch seine Vorzuege gegenueber den Klicki-Bunti-Schaltplaenen, die man basteln kann. Diese sind zwar naehr am finalen Platinendesign, das ist aber ohnehin etwas, was computer viel besser designen/optimieren koennen, als Menschen ...

Hat alles Vor und Nachteile. Textuelle Programmierung hat eben idR eine hoehere Informationsdichte, als visuelle Programmierung. Daher ist sie fuer den Anfaenger vielleicht verwirrender, fuer den Profi aber flexibler.

[Mog]

Da habe ich mich wohl etwas verschätzt. Eine Kollegin von mir, Chemiestudentin, hat auch ein paar Grundlagen der E-Technik gelernt. Wahrscheinlich war das dann noch grundlegender, als ich dachte. ^^

Naja, VHDL ist doch schon wieder etwas ganz anderes. Mit LabView behandelt man eine ganz andere Klasse von Problemen. Um ehrlich zu sein ist LabView auch die einzig-sinnvolle graphische Programmiersprache, die ich kenne. ^^

[DFYX]

Naja, VHDL ist doch schon wieder etwas ganz anderes. Mit LabView behandelt man eine ganz andere Klasse von Problemen. Um ehrlich zu sein ist LabView auch die einzig-sinnvolle graphische Programmiersprache, die ich kenne. ^^

...

Na da kenne ich aber auch andere Meinungen. Ein Kommilitone von mir hat mal Automatisierungssoftware für Windkraftwerke in LabView geschrieben, weil der Kunde das so wollte. Ich muss mir heute anhören, wie chaotisch, langsam und instabil das ist. Mal davon abgesehen, dass der Interpreter selbst wohl verdammt verbuggt sein soll.

[Mog]

Na da kenne ich aber auch andere Meinungen. Ein Kommilitone von mir hat mal Automatisierungssoftware für Windkraftwerke in LabView geschrieben, weil der Kunde das so wollte. Ich muss mir heute anhören, wie chaotisch, langsam und instabil das ist. Mal davon abgesehen, dass der Interpreter selbst wohl verdammt verbuggt sein soll.

...

Es ist eher das nicht wirklich funktionierende Debuging, was stoert. Wenn man einen Fehler macht, muss man einfach den Fehler verstehen, um den effektiv finden zu koennen.

Da die einzelnen Module aber doch recht komplexe Uebertragungsfunktionen haben, macht das nicht wirklich einen Unterschied, ob man da auf Textbasis den Fehler sucht, oder eben auf graphicher Basis.

Gerade bei irgendwelchen Schaltungen kannst du ja ohnehin nicht einfach etwas rausstreichen, um zu sehen, was falsch ist, um mal schnell einen Verdacht zu pruefen.

Mmn. liegt das eher daran, dass man hier einfach auf einer anderen Ebene arbeitet. Schließlich baut man Schaltungen, und die meisten Bugs bedeuten, dass wo eine Sicherung fliegen würde, oder gleich ein Motor in die Luft geht, oder irgendetwas abdampft.

[Rewind]

Ein Grafikprogramm ist auch ein bisschen was anderes, als C oder C++.
Ein Grafikprogramm hat schon fest vorgeschriebene Algorithmen, die man sequentiell ausführt.
Programmiersprachen hingegen besitzen gar keine Algorithmen, sondern nur Befehle, die die Kommunikation mit dem Rechner möglich machen. Die Algorithmen schreibt der programmierer selbst.

...

Naja, ich finde, dass kann man schon vergleichen: Ob du nun im Grafikprogramm ein Multiply-Node für zwei Farben einfügst oder in einer IDE eine C-Funktion mit parametern aufrufst (sei es nun eine Funktion "Multiply" oder einfach nur printf) finde ich schon ähnlich. Die Nodes in Grafikprogrammen stellen ja letztendlich auch nur Funktionen dar. Bei C++ & Co könnte man das dann auf Klassen erweitern. Man muss auch nicht alles zusammenklicken. Ich dachte eher an etwas wie Nassischneidermann-Diagramme bzw. UML.

Ich hab das ganze mal spaßeshalber ausprobiert: Ich hab mir Webkit heruntergeladen und davon WebCore in Xcode geöffnet und ein Class Model erstellt (d.h. eine Übersicht aller Klassen im WebCore, Vererbung wird durch Pfeile dargestellt). Das Ergebnis ist leider etwas ernüchternd: Dem ersten Anschein nach sind Programme tatsächlich zu komplex für node-basierte Darstellungen! Ich fürchte, Grafikprogramme haben den großen Vorteil, sehr geradlinige Netzwerke abzubilden, während Computerprogramme mehr Querverbindungen haben.
Sieht also so aus, als hättet ihr mit der Unübersichtlichkeit doch Recht. Menno.... ^^