Scratch - Programmieren nun kinderleicht!

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