Scratch - Programmieren nun kinderleicht!

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

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

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