Hallo Besucher, der Thread wurde 6,4k mal aufgerufen und enthält 37 Antworten

letzter Beitrag von ZeHa am

Galgenraten für Schulkinder

    In der schule, anno frühe 2000er haben wir sowohl galgenmännchen gespielt, alsauch ein bisschen im Informatik Unterricht programmiert.
    Wir nutzten damals eine Software namens "robot Carol" mit der man ein virtuelles legomännchen programmieren konnte. Ging quasi darum, zuerst mal eine grobe Vorstellung von Syntax usw zu bekommen.
    Danach ging es dann mit qbasic weiter. Nicht sehr zeitgemäß, aber der Lehrer war wenigstens fit darin.


    Ansätze wie scratch finde ich sehr gut, um unbedarften die Materie näher zu bringen und den Einstieg möglichst einfach zu gestalten.


    Gruß C-Man

    Zitat von Tale-X

    keine Exceptions

    Naja, die kommen eh so langsam aber sicher aus der Mode, jedenfalls in gewissen Kreisen (streng funktionale Programmierung z.B. in einer Domain-Schicht). Mit BASIC hat das natürlich nichts zu tun ;) Falls es trotzdem jemanden interessiert, hier mal ein älterer Artikel (engl.), der aber durchaus noch seine Berechtigung hat. Sorry fürs OT, irgendwie reizt dieser Thread in seinem Verlauf zur Diskussion über alles mögliche :o

    Was ich nicht verkehrt finde, die verschiedenen Facetten der Programmierung sind nun mal spannend...


    ZeHa: wenn man keine Peilung vom Programmieren hat, dann ist so eine visuelle Darstellung der Möglichkeiten zur Ablaufsteuerung schon hilfreich. Sonst klebt man zu sehr an den Befehlen der erstgelernten Sprache.

    Einen visuellen Ansatz würde ich meinen Kindern nur dann anbieten, wenn:


    a) die zukünftige Entwicklung grundsätzlich und ausschließlich auf visuelles Progrmmieren hinausläuft ODER
    b) das zu vermittelnde Lernziel visueller Natur ist, in diesem Fall vielleicht: was ist Objektorientierung? Was ist ein Objekt? Wie verhalten sich Objekte? Da ist eine visuelle Darstellung ideal.


    Ansonsten würde ich nach wie vor vom klassischen Ansatz ausgehen, dass Computer grundsätzlich nur drei Dinge können, nämlich:
    1. Befehle abarbeiten (set a = 10, print a, a= sqr(b), b= bibliotheksfunktionX(SomeParam), a++ usw. usf.)
    2. Schleifen ausführen (for, do, while, loop etc.) und
    3. Bedingungen auswerten (if, on, select case etc.)
    Hierfür benötigt man nicht nur keinen grafischen (visuellen) Ansatz, sondern er ist im Gegenteil eher hinderlich.


    Aber, wie gesagt, es gibt Lernziele, für die ein visueller Ansatz ideal ist.


    Und ja, sowohl der OT als auch die Entwicklung der Diskussion hier verdienen jeweils einen Split des Fadens.

    Ich wuerde es vielleicht so formulieren: Ein visueller Ansatz ist rein prinzipiell nicht schlecht, um etwas zu lehren. Siehe auch so Dinge wie PAP (Programm-Ablauf-Plan oder wie das heisst) usw. Nur wuerde ich halt nicht direkt die Sprache damit implementieren, sondern das halt nur im Lehrbuch/-text/-video oder sonstwo zeigen.


    Ich finde das eigentliche Coden per Text auch viel natuerlicher, flexibler, und auch praktischer, denn einen Source-Code kann ich auch copy/pasten oder in SVN einchecken oder sonst etwas. Sowas grafisches empfinde ich da als sehr "hinderlich", so ein bisschen als waere man hinter einer Glasscheibe gefangen. Auch bezweifle ich, dass grafischer Code uebersichtlich bleibt, sobald der Code mal doch einen Ticken laenger werden sollte. Auch kann man doch bestimmt keine Kommentare einfuegen, oder?

    Ich habe mich lediglich auf die geeigneten didaktischen Mittel zur Vermittlung von Lerninhalten für die Programmierung von Computersystemen für Kinder bezogen.


    Eine komplett visuelle Programmiersprache halte ich für vollständig absurd. Maximal die "IDE" könnte eventuell bis zu einem gewissen Grad visuell funktionieren, aber da greifen dann die von ZeHa genannten Einschränkungen recht schnell.

    Zitat von Bytebreaker

    Ich habe meiner Tochter ein Programm geschrieben mit dem sie Buchstaben setzen und raten soll. Das Galgenmännchen baut sich von alleine auf.

    Schönes kleines Programm. :thumbup:

    Zitat von Bytebreaker

    Es geht ja hier primär ums Buchstabieren lernen und wie man eine Tastatur benutzt inkl. Backspace. Das geht auch beim Eingeben des geheimen Wortes

    Und sie hat noch nicht die Ziffern und Sonderzeichen ausprobiert? Die werden nämlich (noch) nicht abgefangen und können zum Programmabbruch führen. ;)


    Was außerdem evtl. noch schön wäre: Eine Anzeige der bisherigen falschen Zeichen, damit man keines zweimal eingibt.

    Zitat von Commodore Man

    In der schule, anno frühe 2000er haben wir sowohl galgenmännchen gespielt, alsauch ein bisschen im Informatik Unterricht programmiert.

    Ebenfalls.



    Zitat von Commodore Man

    Wir nutzten damals eine Software namens "robot Carol" mit der man ein virtuelles legomännchen programmieren konnte. Ging quasi darum, zuerst mal eine grobe Vorstellung von Syntax usw zu bekommen.
    Danach ging es dann mit qbasic weiter. Nicht sehr zeitgemäß, aber der Lehrer war wenigstens fit darin.

    Wir haben mit Robot Karol so in der 5. Klasse angefangen, und in der 7. dann mit EOS (Einfache Objektorientierte Sprache) weitergemacht, in der man irgendwelche geometrischen Formen programmiert hat.


    Ab etwa der 8. oder 9. gabs dann Java im Informatikunterricht, zunächst mit schönen IDEs wie Greenfoot und BlueJ, die einem die Konzepte der objektorientierten Programmierung sehr gut näherbringen. Zusätzlich gabs nebenbei noch SQL und rudimentär ein bisschen HTML. In der Oberstufe gabs dann sogar Assembler auf einer einfachen Registermaschine.

    @ nino


    Wow. Warst du auf einem technischen Gymnasium? Das sieht nach guter Vorbildung aus.


    @ Mac Bacon :


    :D


    Danke dass du dir verkniffen hast dass ich außerdem den Input Befehl benutzt habe mit all seinen UI-Schwächen. Das Programm ist derzeit nicht geeignet mit einem Kind allein gelassen zu werden das alles probiert was nicht vorausschauen verhindert wird.


    Die Idee, die ausgeschiedenen Buchstaben anzuzeigen hatte ich auch schon, dachte dann aber, dass der Spieler auch sein Gedächtnis bemühen soll. Als Programmierübung dagegen ist es gut, die ausgeschiedenen anzuzeigen und nur Buchstaben zuzulassen ohne Steuerzeichen. Das müsste durch die Reihenfolge der chr Codes auch gar nicht allzu schwer abzufangen sein.


    Zitat von Bytebreaker

    Die Idee, die ausgeschiedenen Buchstaben anzuzeigen hatte ich auch schon, dachte dann aber, dass der Spieler auch sein Gedächtnis bemühen soll.

    Kannst ja das Spiel in zwei Schwierigkeitsstufen einteilen. Einmal mit Buchstaben anzeigen und einmal ohne.
    Ach so - die Idee und die Umsetzung finde ich gut. Die komfortablere Eingaberoutine kann man ja immer noch einbauen.

    Huhu!


    Anbei eine englische Version mit 2 Schwierigkeitsgraden "hard" und "easy". Unter "easy" werden die Fehleingaben auf dem Bildschirm ausgegeben damit man sieht, was man kein zweites Mal versuchen sollte.


    Dann habe ich mir das Thema Steuerzeichen nochmal angesehen. Bei der Eingabe des geheimen Wortes schaut er, ob die Eingabe einem CHR-Code >90 oder >32 entspricht und lässt nichts durch außer Buchstaben, Backspace und Return. D.h. "F1" drücken oder "Strg + 1" während der Eingabe des geheimen Wortes führt zu Ignorieren, es wird auch kein Stern dafür ausgegeben. Bei den Rateversuchen werden solche Kombis ebenfalls ignoriert.


    Man kriegt das Programm nur noch über den Input Befehl kaputt - denke ich. Ich lade das dann auch auf csdb hoch, vielleicht kann da auch jemand mit was anfangen.



    Danke an MacBacon für unnachgiebe Qualitätssicherung und nicht "Passt scho durchreichen". :dafuer:

    Zitat von zrs1

    Kriegt man natürlich hin, aber solange dann was tönt "steht" das Programm, das C64 BASIC kann ja leider keinerlei Nebenläufigkeit.

    Im Bedienungshandbuch des VC-20 steht ein kleines Programm, welches einen "Vogel" zur Bildschirmmitte fliegen läßt. Daran angefügt in etwa: "Übrigens, es ist nicht ganz so leicht, nebenher die Melodie "Kommt ein Vogel geflogen" abspielen zu lassen."


    Tja, das hatte mir damals™ keine Ruhe gelassen, und als Ergebnis kam das hier raus:

    :D


    Also: die von dir als fehlend erachtete Nebenläufigkeit fehlt eigentlich gar nicht. Man muß eben die Programmteile geschickt anordnen, so daß Effekte, die "gleichzeitig" ablaufen sollen, ineinander geschachtelt werden. Das kann z.B. mit einem Sprungverteiler am Anfang der Hauptschleife gemacht werden.

    Zitat von Mike

    Also: die von dir als fehlend erachtete Nebenläufigkeit fehlt eigentlich gar nicht.

    Öhm, also damit kann das BASIC immer noch keine Nebenläufigkeit, sondern du implementierst sie "einfach" selbst ;) Das ist allerdings schon "hardcore" ... hehe. Mal ansehen, bin gespannt wie brauchbar das Timing ist! <- edit: Ziemlich gut geworden ... haha, nett :)

    Zitat von zrs1

    Ziemlich gut geworden ... haha, nett :)

    Nicht wahr? Man muß sich eben nur zu helfen wissen.


    Als etwas ausgefeilteres Beispiel habe ich unten mal meine Spielesammlung für den VC angehängt. Speziell geht es mir da um das Spiel "MOON PATROL". Das hatte ich 1986 mal selbst programmiert und später, in 1995 wieder hervorgeholt - und einmal auseinander- und wieder zusammengebaut.


    Bei der ersten Version blieb das Spiel noch stehen, wenn Mondauto oder UFO eine Rakete abgeschossen hatten (was es eher zum Glückspiel machte, wer zuerst traf!) - in der neuen Version fliegen die Raketen gleichzeitig zum Rest der Animation. Übrigens ist das Programm immer noch zu 100% in BASIC!


    Das Beispiel zeigt aber auch die Grenzen auf, wenn man in BASIC bleibt: wenn mehr los ist, bricht die Geschwindigkeit doch merkbar ein. Dann macht es doch Sinn, die kritischen Teile in Machinensprache zu schreiben und ggfs. in den Interrupt zu verlagern, so wie das mit den Musikabspielroutinen beim C64 gemacht wird.