Ich muß HaWe hier Recht geben und wundere mich, was manche von einem Projekt für Kinder erwarten.
Bildchenprogrammierung für Kinder ab zehn halte ich auch für sinnvoll, wobei ich zehn eher für die absolute Untergrenze halte. Ab zwölf wäre sinnvoller, man sollte nicht vergessen dass man es nicht nur mit Nerd-Kindern in einer Klasse zu tun hat.
Was soll ein achtjähriges Gehirn denn Großartiges abstrahieren? Eine einfache Abfolge von Anweisungen Wenn-das-tu-jenes ist meines Erachtens vollkommen genug. Wenn du Kindern etwas beibringen willst ist es das Wichtigste, ihre Neugier auf den Inhalt zu lenken. Wenn du dagegen ihren Unmut förderst (und das wirst du mit zuviel Abstraktion unweigerlich tun) wirst du mit deiner Lehre keinen Erfolg haben.nein, eben nicht. Mit "Bilder-statt-Text" ruinierst du den Hintergrund der Programmierung und entlastest das Hirn von der Abstraktion.
Das Leben ist sicher nicht immer Zuckerlecken und das sollten Kinder auch frühzeitig lernen, aber Lehrer die ihren Stoff nur mit Gewalt in Kinderköpfe kriegen sind schlechte Lehrer.
Ich habe meine ersten Programme für einen Lego-Roboter auch mit Bildchenschieberei zusammengeklickt. Später habe ich Assembler für AVRs, C, Java und Labview (wieder Bildchenschieberei) gelernt und das Bildchenschieben hat mich gewiss nicht versaut. Im Gegenteil, ich finde dass beide Konzepte so unterschiedlich sind, dass sie sich gegenseitig relativ wenig beeinflussen. Es macht zwar Mühe sich in das Konzept einer Sprache reinzudenken und konsequent und geschickt anzuwenden, aber das ist meiner bescheidenen Erfahrung mit jeder Sprache so.Im Gegenteil, wenn die Kinder wirklich mal Programmierer werden wollen, müssen sie sich die ganzen Hintergründe und den ganzen Syntax-Kram neu erarbeiten und neu im Hirn verankern. Dabei stört dann, dass sie durch die Bildchenschieberei quasi versaut sind.
Ich gebe dir aber Recht was zu starke Vereinfachung (siehe Rechtschreibung) betrifft, das ist unter aller Sau. Ich halte Simplifizierung auch nicht für eine geeignete Methode um Wissen zu vermitteln. Von (unnützem) Ballast befreien ja, damit der Blick für das Wesentliche frei wird. Mehr aber auch nicht. Und genau diesen Ansatz verfolgt zumindest die Lego-Programmierung ja auch. Da heißt es einfach nur, der Motor am Anschluß zwei soll für 10s rechts laufen und anhalten, sobald der Berührungssensor am Anschluß drei was merkt. Und kein nutzloses Deklarieren von Variablen, Adressen verwalten oder Compilerschelte weil irgendwo ein ; vergessen wurde. Von den Rechtschreibregeln, die jede textbasierte Programmiersprache unweigerlich mitbringt ganz zu schweigen. Und ich unterstelle den Machern von Open Roberta einfach mal einen ähnlichen Ansatz. Den üerflüssigen Mist mit gendergerechten Inhalten und diskriminierungsfreien Abbildungen (es müssen auch schwarze Kinder mit rein) ignoriere ich mal.
Viel interessanter finde ich die Frage, ob genug Lehrkräfte und Schulen bereit sind, sich mit der Thematik auseinanderzusetzen und dies im Unterricht gebührend zum Einsatz kommt. In Zeiten, wo Billigbespaßung wie "Playstation to go" das kindliche Hirn matschig dudeln und gute Spielzeuge wie Metallbaukästen quasi ausgerottet sind, sehe ich solche Projekte als umso sinnvoller an.
@HaWe:
Wegen der Labview-Diskussion:
Ich sehe LV sicher nicht als ultimative Allzweckwaffe für jedes Problem an. Man kann damit sicher alles Mögliche programmieren. Kann man mit ASM auch. Andererseits wurden die meisten Programmiersprachen für einen ganz bestimmten praktischen Zweck entwickelt (außer vielleicht Ook! oder Brainfuck, die dienen der Belustigung oder Hack, dass, soweit ich das beurteilen kann, mehr der Selbstdarstellung dient) und hat dementsprechend ihre Vor- aber eben auch Nachteile, meines Erachtens aber auf jeden Fall ihre Daseinsberechtigung. Aber das weißt du mit Sicherheit selber.
Warum sich die Entwickler bei NI für eine Bildchensprache entschieden haben weiß ich auch nicht genau. Soweit ich weiß, wollte man auf jeden Fall möglichst einfach grafische Benutzeroberflächen für rechnergestütze Meßinstrumente schaffen können-und diesen Anspruch erfüllt LV meines Erachtens nach hervorragend. Was mir als angenehm auffällt ist auch, dass sich Ablaufdiagramme recht gut runterprogrammieren lassen-sofern der Code insgesamt natürlich nicht zu unübersichtlich wird, aber dafür bietet LV ja auch Werkzeuge an.
Und auch wenn ich nicht weiß wie gut der Compiler dass das umsetzt-aber zumindest vom Ansatz her ist LV gut geeignet für parallele Berechnungen.
Lesezeichen