Scratch - Programmieren nun kinderleicht!

Hi Leute,
war am 24.2. in der Uni in Oldenburg und habe Teil an dem Informationstag genommen. Das Motto lautete "Informatik - Ja sicher!". Es war so wundersuper (hehe, kleiner Insider am Rande). Aber ich habe etwas gefunden, was bestimmt viele unter euch interessieren würde. Undzwar gab es ein Programm names "Scratch" - Naja, der Name sagt nicht viel aus, aber ich war echt erstaunt was man damit machen konnte. Es war eine Art Spiel, Animation und Powerpoint und Paint Mischung. Ich habe es mir heute geholt und hab mal so richtig die Sau rausgelassen :D. [Downloadlink am Ende]
Also eigentlich besteht das Interface aus kleinen Puzzlenteilen, die man hin und herschieben kann und die mit Bedingung, Folge, etc. belegt sind. Zum Beispiel: Wenn [Grüne Fahne gedrückt], dann [10 Schritte gehen] und [90° drehen].
Hab da mal so nen Screenshot vorbereitet.
http://www.imagebanana.com/img/n21yc...mb/scratch.jpg
Also hiermit gebe ich das Startsignal, tobt euch aus :D

MAN MUSS DAS FORMULAR NICHT AUSFÜLLEN!

http://scratch.mit.edu/download

Windows und Mac! \°O°/

Wusstet ihr bereits davon? Habt ihr schonmal gehört? Was sind eure ersten Eindrücke? Ist es nützlich?

MfG Paschu

I'm an attentionwhore! ES HEIßT SCRATCH!!!!!!
[Nicht Scrath -> C Taste klemmt]

Das erinnert optisch irgendwie an die Lego Mindstorms "Programmiersprache". Mit dem Unterschied, dass man damit was sinnvolles tun konnte. Was hab ich davon, wenn ich irgendwelche Tiere geskriptet über den Bildschirm laufen lassen kann?

P.S.: den Titel müsstest du selbst ändern können.

Hab ich probiert... geht nicht.

Also ich finds toll :3

Erinnert mich ein wenig an die Textur- und Effektprogrammierung von Autodesks 3dsmax. Zudem hat es gewisse Zuege von Autorensysteme. Insgesammt nicht viel anderes, als eine Visuelle Aufbereitung von If-Bedingungen, Schleifen und Functioncalls .. ich kann mir vorstellen, dass bei groesseren Projekten schnell die Uebersichtlichkeit verloren geht.

Hahahaha~
Ach welch herrliche Erinnerungen werden da an meine Schulzeit wach. Ein ähnliches Program hatten wir dort auch und sollte uns das Programmieren beibringen. Ich konnte mich schon damals mit den weniger Möglichkeiten nie wirklich anfreunden, für Leute sie es gerne verstehen würden aber nicht so richtig durchblicken isses aber toll imho.

Zitat:

---

Zitat von DFYX

Das erinnert optisch irgendwie an die Lego Mindstorms "Programmiersprache".

---

Daran dachte ich auch gerade^^

Prinzipiell erinnert es auch ein wenig an JavaKara, damit haben wir damals in der Schule angefangen als Einführung in Java. Ist im Prinzip ein kleiner Marienkäfer der über felder läuft und Kleeblätter aufsammeln und ablegen kann und sich an Hindernissen orientieren kann. Konnte man sowohl grafisch als auch mit Java programmieren. Sowas ähnliches gibt es auch mit einem Hamster.

Es gibt viele solcher Projekte, und finde das prinzipiell auch nicht schlecht, weil man keine Synthax lernen muss um damit was zu machen, was vermutlich besonders an Kinder schwer ranzubringen ist.
Das Prinzip, also die Denkstruktur ist allerdings die selbe. Das ist sicher gut, wenn man jemanden an das Programmieren heranführen will, aber ich frage mich, ob damit alle, die (noch) nicht in dem Schema denken, zurecht kommen würden.

Ich frage mich, was solche Spielereien mit Programmieren zu tun haben?
Für mich ähnelt das ein bisschen mehr an Adobe Flash mit einem sehr primitiven ActionScript.
Dabei lernt man vielleicht nur das Verständnis der Ereignisorientierter Programmierung aber nicht der Programmierung an sich.

Scheint zwar eine nette Spielerei zu sein aber helfen tut es keinem. Es erweckt nur einen falschen Eindruck, der in meinen Augen fatal ist. Programmieren wird tatsächlich so dahingestellt, dass man mit nur ein paar Mausklicks ein komplettes Programm schreiben kann. Genau dieses Bild hat sich auch in den meisten Köpfen der Menschen eingebrannt.

Schau dir die FHs/Unis an, die Informatik als Studienfach anbieten. Schau dir die Durchfallqoute an, weil viele kein Plan haben und unbedingt Spiele "programmieren" wollen.
Ich bin mal aus allen Wolken gefallen, als ein Erstsemester-Student zu mir meinte, dass Objektorientiertes Programmieren (OOP) tatsächlich sowas wäre, wie "man schiebe grafische Objekte zusammen und daraus entsteht ein Programm".

Was ist denn Programmieren?

Zitat:

---

Zitat von Kyuu

Was ist denn Programmieren?

---

;)

An dieser Stelle waere eine Abwaegung der Sinnlosigkeit angebracht. Dass viele Leute eine realitaetsferne Vorstellung von Programmierung (in Anbetracht der Nutzlosigkeit und Effizienz) haben, wurde bereits von Whiz-zarD erwaehnt. Auch wenn diese Vorgehensweise keine Empfehlung meinerseits waere - wenn sie hilft, an die Programmierung zu kommen, warum nicht?

Zitat:

---

Zitat von Kyuu

Was ist denn Programmieren?

---

Ich würde sagen, man Programmiert das Verhalten und die Operationen eines Prozessors durch Eingabe von Anweisungen und Befehle. Diese können einzeln oder auch sehr komplex mit vielen tausend Zeilen und Verzweigungen sein. Diese Anweisungen und Befehle werden in einer Programmiersprache geschrieben, die vom Menschen lesbar* ist, aber zum Ausführen für die CPU erst in Maschinencode übersetzt werden muss. (mittels Compiler, Linker etc).
So gesehen bedeutet Programmieren also, dass man das Verhalten und die Rechenoperationen eines Prozessors (muss kein PC sein, kann auch ein Geldautomat, eine Industriemaschine etc sein) steuert und mit bestimmten Eingabewerten bestimmte Ausgabewerte errechnen kann.
Das kann man so gesehen auch mit einer Scriptsprache oder einem Klick-System, denn auch damit steuert man das Verhalten der CPU, wenn auch viel eingeschränkter. Der Informatiker wird das aber wohl eher nicht als Programmieren durchgehen lassen, eher als Scripten oder "Rumklicken". Programmieren meint wohl eher das Schreiben von Programmzeilen in einer Programmiersprache, die dann in Maschinencode übersetzt wird.


*Lesbar ist sie zwar, aber nur demjenigen verständlich, der sich mit der Programmiersprache auskennt.

Zitat:

---

Zitat von Whiz-zarD

Ich frage mich, was solche Spielereien mit Programmieren zu tun haben?
Für mich ähnelt das ein bisschen mehr an Adobe Flash mit einem sehr primitiven ActionScript.
Dabei lernt man vielleicht nur das Verständnis der Ereignisorientierter Programmierung aber nicht der Programmierung an sich.

---

Ist die Frage, was der Sinn davon sein soll. Ich denke, das ist kaum zum tatsächlichen programmieren zu gebrauchen... Aber zum spielerischen heranführen vermutlich schon. Wie gesagt, wir haben in der Schule (damals, 8. Klasse oder so) mit Kreisen und Pfeilen angefangen in das Thema einzusteigen... Ich fand das ziemlich billig, andere hatten bereits damit schon Probleme. Als ich dann das erste mal mich mit tatsächlichem Quellcode und Syntax rumschlagen musste, stand ich davor wie eine Kuh wenn es donnert.
Aber zu mehr, als damit zu lernen, wie ein "Computer denkt" nutzt es mMn nicht. Darüber, ob das das beste Lernmittel dazu ist, lässt sich dann streiten.

Das mag in der Grundschule ja ne nette Idee sein, aber in Oberstufe und Studium hat sowas nichts verloren.

Zitat:

---

Zitat von Ineluki

Erinnert mich ein wenig an die Textur- und Effektprogrammierung von Autodesks 3dsmax. Zudem hat es gewisse Zuege von Autorensysteme. Insgesammt nicht viel anderes, als eine Visuelle Aufbereitung von If-Bedingungen, Schleifen und Functioncalls .. ich kann mir vorstellen, dass bei groesseren Projekten schnell die Uebersichtlichkeit verloren geht.

---

Schon mal ein Nuke-Projekt gesehen? Kleiner Tipp: Jeder kleine, bunte Punkt enspricht einem Node. ;)

Sowas ist immer eine Frage der Organisation. Scratch mag hier nur ein Spielzeug sein, aber wenn man sowas mal professionell aufziehen würde, wäre sowas durchaus denkbar.

Zitat:

---

Zitat von Whiz-zarD

Ich frage mich, was solche Spielereien mit Programmieren zu tun haben?

---

Bezogen auf Scratch: Jeder hat mal klein angefangen.
Bezogen auf grafische Oberflächen zum Programmieren: Hattest du schon jemals mit 3D Grafik zu tun? Dort gibt es die unterschiedlichsten Scriptsprachen und andere Anwendungsfälle für Programmierung. Die haben fast alle was gemeinsam: Sie werden fast alle in node-basierten Programmen erzeugt.

Klar ist das gezeigte Programm nur eine Spielerei, aber warum der Quarzcomposer die einzige professionelle Entwicklungsumgebung außerhalb der Film- und Spielebranche zu sein scheint, die eine node-basierte Oberfläche mit sich bringt, wird mir auch immer ein Rätsel bleiben. Xcode und Interface Builder ist bisher die einzige mir bekannte Entwicklungsumgebung, die mal wenigstens ein bisschen grafische Unterstützung anbietet, wenn es um Bindings geht oder im Model Editor und im Class Editor (wobei ich noch nicht herausgefunden habe, wie man im Class Editor eine neue Klasse anlegt - ich fürchte, das geht nicht.)

Ich kenne Eclipse, Netbeans und Qt Creator noch nicht so gut, aber vergleichbares habe ich dort noch nicht gefunden. UML Editoren gibt es wohl ein paar (meist relativ unansehnlich), aber ob diese Diagramme in beide Richtungen gesynct werden, sodass man auch nachträglich Klassen über eine UML Ansicht hinzufügen oder ändern kann? Mh, bisher habe ich so etwas noch nie gesehen - korrigiert mich, wenn ich da falsch liege!

Ein bisschen mehr Grafik würde Programmierern auch nicht schaden. Ich weiß nicht, warum sich diese Anwendergruppe so strikt gegen arbeitsvereinfachende, grafische Werkzeuge zu wehren scheint... kommt einem jedenfalls manchmal so vor.

Zitat:

---

Zitat von Whiz-zarD

Für mich ähnelt das ein bisschen mehr an Adobe Flash mit einem sehr primitiven ActionScript.

---

So primitiv ist Actionscript gar nicht? Programmieren hat nicht zwangsläufig etwas mit Hochsprachen zu tun...

Zitat:

---

Zitat von Rewind

Sowas ist immer eine Frage der Organisation. Scratch mag hier nur ein Spielzeug sein, aber wenn man sowas mal professionell aufziehen würde, wäre sowas durchaus denkbar.

---

Was meinst du, wie die Spieleentwickler ihre Spiele schreiben?
Ein Programmiererteam schreiben eine Engine und eine IDE für die Designer.

Zitat:

---

Zitat von Rewind

Ein bisschen mehr Grafik würde Programmierern auch nicht schaden. Ich weiß nicht, warum sich diese Anwendergruppe so strikt gegen arbeitsvereinfachende, grafische Werkzeuge zu wehren scheint... kommt einem jedenfalls manchmal so vor.

---

Und was hat das Programm nun mit der Programmierung einer Grafischen Oberfläche zu tun?
Wenn man klein, mit dem Programmieren, anfängt, lässt man nicht ein komisches Tier, mit einem Baguette in der Hand, durch die Gegend laufen.

Das Programm ist vielleicht für Spieledesigner, im ersten Semester, interessant, die Scripte ala "Person A läuft nach Ort B" schreiben.

Zitat:

---

Zitat von Rewind

So primitiv ist Actionscript gar nicht? Programmieren hat nicht zwangsläufig etwas mit Hochsprachen zu tun...

---

Ich hab auch nicht gesagt, dass ActionScript primitv sei ...
Ich sagte nur, dass das Programm mich ein bisschen an eine abgespeckte Version von ActionScript erinnert.

Zitat:

---

Zitat von Whiz-zarD

Was meinst du, wie die Spieleentwickler ihre Spiele schreiben?
Ein Programmiererteam schreiben eine Engine und eine IDE für die Designer.

---

Und warum genau scheint es für das Programmierteam ein Verbot zu geben, grafische (besser gesagt: node-basierte) Entwicklungswerkzeuge zu benutzen? Die IDE-Entwickler für Programmier-IDEs könnten doch auch schon grafische Hilfen einbauen, oder?

Zitat:

---

Zitat von Whiz-zarD

Und was hat das Programm nun mit der Programmierung einer Grafischen Oberfläche zu tun?
Wenn man klein, mit dem Programmieren, anfängt, lässt man nicht ein komisches Tier, mit einem Baguette in der Hand, durch die Gegend laufen.

---

Ich spreche auch nicht von dem Programm, was du mit Scratch entwickelst, sondern vom Ansatz, wie Scratch an die Programmierung herangeht. Wenn du BlueJ kennen solltest, weißt du vielleicht eher was ich meine: Du hast für jede Klasse ein Node, mit denen du die Entwicklung deines Programms visualisieren kannst (z.B. mit einem UML-Klassendiagram). Ansätze davon gibt es - wie gesagt - auch in Xcode, aber aus anderen Umgebungen kenne ich das kaum. Ich finde, man könnte UML-Editoren mehr in die Entwicklung integrieren, statt sie nur zur Planung und Vorbereitung zu nutzen. Ich verstehe nicht, warum man in professionellen Grafikprogrammen seine Shader-Programme u.ä. zusammenklicken kann, während man C, C++ und Java alles ziemlich mühsam per Hand tippen muss - oder täusche ich mich da? Für Eclipse gibt es nicht einmal einen gescheiten GUI Designer, ganz zu schweigen von den Ideen eines node-basierten Entwicklungstools...

Zitat:

---

Zitat von Whiz-zarD

Ich hab auch nicht gesagt, dass ActionScript primitv sei ...
Ich sagte nur, dass das Programm mich ein bisschen an eine abgespeckte Version von ActionScript erinnert.

---

:) hatte ich falsch verstanden, sry

Zitat:

---

Zitat von Rewind

Und warum genau scheint es für das Programmierteam ein Verbot zu geben, grafische (besser gesagt: node-basierte) Entwicklungswerkzeuge zu benutzen? Die IDE-Entwickler für Programmier-IDEs könnten doch auch schon grafische Hilfen einbauen, oder?

---

Es gibt kein Verbot. Nur stört oftmals Klicki-Bunti.
Schon mal Flash-Anwendungen programmiert? Das ist die reinste Klick-Orgie, die zu keinem Ergebnis führt.

Ich hab damals, als Mechatroniker, SPS-Anlangen über Kontakt- und Funktionsplänen programmieren müssen. Irgendwann hat man auf diesen Kram keine Lust mehr, weil der grafische Kram irgendwann mehrere Bildschirme füllt und man nur noch dabei ist rumzuscrollen.
Und zur besseren Übersicht hilft das auch nicht.
Da hab ich lieber reinen Text und kann, ohne zu scrollen, die Funktion begutachten.

Zitat:

---

Ich spreche auch nicht von dem Programm, was du mit Scratch entwickelst, sondern vom Ansatz, wie Scratch an die Programmierung herangeht. Wenn du BlueJ kennen solltest, weißt du vielleicht eher was ich meine: Du hast für jede Klasse ein Node, mit denen du die Entwicklung deines Programms visualisieren kannst (z.B. mit einem UML-Klassendiagram). Ansätze davon gibt es - wie gesagt - auch in Xcode, aber aus anderen Umgebungen kenne ich das kaum. Ich finde, man könnte UML-Editoren mehr in die Entwicklung integrieren, statt sie nur zur Planung und Vorbereitung zu nutzen. Ich verstehe nicht, warum man in professionellen Grafikprogrammen seine Shader-Programme u.ä. zusammenklicken kann, während man C, C++ und Java alles ziemlich mühsam per Hand tippen muss - oder täusche ich mich da? Für Eclipse gibt es nicht einmal einen gescheiten GUI Designer, ganz zu schweigen von den Ideen eines node-basierten Entwicklungstools...

---

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.
C stellt ja nur eine geringe Anzahl an Befehlen zur Verfügung. Befehle, wie z.B. fprintf werden durch Module reingeladen.

Das einzige, was man da machen könnte, wäre eine Hybrid-GUI erstellen, die einer Seite die Funktionen per Text programmieren lässt und man dann einen grafischen Teil besitzt, wo man dann die einzelnen Funktionen. zusammenfügen kann. Allerdings hätte man dann wieder das Problem, dass wenn man mit den zurückgegebenen Daten einer Funktion arbeiten möchte, wiederrum ein Textfenster benötigt, was die Sache wieder unnötigt kompliziert macht.

Vielleicht verstehst du jetzt, warum man eine IDE nicht komplett grafisch gestallten kann. Es würde die Sache komplizierter machen, als sie schon ist.

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.

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.

Zitat:

---

Zitat von 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.


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

Zitat:

---

Zitat von 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.

---

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.

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

Zitat:

---

Zitat von Whiz-zarD

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

Zitat:

---

Zitat von Mog

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.

Zitat:

---

Zitat von DFYX

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.