Hello, Guest the thread was called898 times and contains 59 replays

last post from Zaadii at the

VC20/VIC20 im Schuleinsatz (Flying Hall School)

  • Ausserdem geht es ja um den Einstieg. Da sollte sich die Komplexität der Programme in Grenzen halten.

    Ja, aber dann ist man damit ziemlich schnell an der Grenze angekommen und muss auf was brauchbares umsteigen. Dann ist man nicht mehr mit der Maus sondern mit der Tastatur unterwegs und muss den Kram auch noch korrekt tippen. Spätestens dann kommt erst einmal Frust auf.

    Und wie ist das bei Basic auf dem C64? Da gibt es keine Genze, wo man auf was "Brauchbares" umsteigen muss?

    Ich denke, die Grenze liegt bei Scratch deutlich höher.

  • Das klingt jetzt sehr akademisch. Es ist nicht objektorientiert im Sinne des Wortes, weil Instanzierung und Vererbung fehlt. :D

    Natürlich! Das ist nicht akademisch, sondern es ist nun mal ein definierter Begrif in der Informatik: Objektorientierte Programmierung


    Ok, Edith: man kann den Begriff natürlich verschieden auslegen. Bleiben wir dabei, dass Scratch einfach eine coole Sache ist.

  • Und wie ist das bei Basic auf dem C64? Da gibt es keine Genze, wo man auf was "Brauchbares" umsteigen muss?

    Ich denke, die Grenze liegt bei Scratch deutlich höher.

    Nachdem was ich so an BASIC-Programmen gesehen habe denke ich das eher nicht. Auf dem C64 muss das nicht mal in Poke/Peek-Orgien ausarten. Mein schönstes Beispiel war immer noch das 3D-Labyrinth. Es wird ein Labyrinth erzeugt, sichergestellt, daß es einen Pfad zum Ausgang gibt, du siehst auf dem Bildschirm das Labyrinth von innen und darfst den Ausgang finden, alles im Textmodus. Eine Karte mit dem eigenen Standort kann angezeigt werden. Ist reines BASIC, Lief auf dem 4032 und dem C16 (64K) wie auf dem C64.

  • Wenn Du die Kinder dann von Scratch auf eine richtige Programmiersprache umsteigen laesst, musst Du ihnen zusaetzlich noch erklaeren, warum sie jetzt auf einmal tippen sollen... der Frust kommt dann halt erst spaeter und ist vielleicht sogar noch groesser, als wenn man direkt mit tippen anfaengt ;)

  • Wenn Du die Kinder dann von Scratch auf eine richtige Programmiersprache umsteigen laesst, musst Du ihnen zusaetzlich noch erklaeren, warum sie jetzt auf einmal tippen sollen... der Frust kommt dann halt erst spaeter und ist vielleicht sogar noch groesser, als wenn man direkt mit tippen anfaengt ;)

    Ich sehe schon, du hast da mehr Erfahrung als ich. Dann mach das mal bei deinen Kindern so. :D

  • Und wie ist das bei Basic auf dem C64? Da gibt es keine Genze, wo man auf was "Brauchbares" umsteigen muss?

    Ich denke, die Grenze liegt bei Scratch deutlich höher.

    Nachdem was ich so an BASIC-Programmen gesehen habe denke ich das eher nicht. Auf dem C64 muss das nicht mal in Poke/Peek-Orgien ausarten. Mein schönstes Beispiel war immer noch das 3D-Labyrinth. Es wird ein Labyrinth erzeugt, sichergestellt, daß es einen Pfad zum Ausgang gibt, du siehst auf dem Bildschirm das Labyrinth von innen und darfst den Ausgang finden, alles im Textmodus. Eine Karte mit dem eigenen Standort kann angezeigt werden. Ist reines BASIC, Lief auf dem 4032 und dem C16 (64K) wie auf dem C64.

    Zum Thema PEEK/POKE: Man muss natuerlich auch dazu sagen dass das BASIC V2 wirklich nicht das komfortabelste BASIC ist. Am besten zum Einstieg waere natuerlich schon ein BASIC, das zumindest so Befehle wie "COLOR" oder sowas kennt. Damit kann man direkt was anfangen was auf dem Bildschirm etwas bewirkt, und das ist dann fuer mich genauso direkt wie bei Scratch. Ein einfaches Programm welches Text ausgibt und dabei die Farben wechselt usw. ist dann schnell geschrieben ohne abstrakte POKE-Befehle, bei denen ich gut verstehen kann, dass diese keiner intuitiv findet.

  • Wenn Du die Kinder dann von Scratch auf eine richtige Programmiersprache umsteigen laesst, musst Du ihnen zusaetzlich noch erklaeren, warum sie jetzt auf einmal tippen sollen...

    Und warum ';' (bei den meisten) und Einrückungen (Python... gaah!) wichtig sind.

    Genau. Die Kinder werden vollstes Verständnis dafür haben. Und weil sie verstehen, warum das so sein muss, werden sie das auch gerne machen. :thumbsup:

  • Wenn Du das denen von Anfang an beibringst, wo ist das Problem? Genauso wie ich nach meinem ersten Fehlversuch lernen musste, dass man nach jeder Zeile "RETURN" druecken muss, kann man doch auch jemandem beibringen, dass nach jeden Befehl ein Semikolon gehoert. Wenn das Kind das von Anfang an lernt ist das nichts anderes als dass man bei einem geschriebenen Satz einen Punkt am Ende macht. Dann ist das was ganz natuerliches. Wenn man hingegen erst alles zusammenklicken laesst, und damit ja "alles so einfach geht", dann werden sie doch erstmal nicht einsehen, warum sie jetzt so komplizierten Code selbst tippen muessen, oder warum siehst Du das anders?


    Und was Erfahrung angeht: Ich habe zwar keine Kinder, aber ich habe schon einigen geholfen beim Programmier-Einstieg. Sicher ist das bei jedem unterschiedlich gewesen und es ist auch wirklich nicht leicht, da das Patentrezept zu finden. Das schwierigste ist es vermutlich, in dem Moment zu verstehen, warum derjenige jetzt etwas nicht begreift und anders denkt. Mit sowas befasse ich mich schon relativ haeufig gedanklich, aber ja, es heisst nicht dass ich das immer sofort super hinbekomme. Ich beschaeftige mich aber weiterhin damit, weil ich es spannend finde, wie man Leuten solche Dinge beibringen kann. Ich habe auch nichts gegen Skizzen oder Ablaufdiagramme. Trotzdem finde ich es sinnvoll, sofort Code zu schreiben, denn das ist es, was man spaeter auch tut. Genauso wie ich jemandem, der Zeichnen lernen will, das Zeichnen direkt mit einem Stift beibringen wuerde, und nicht erstmal wie man Collagen anfertigt.

  • Zum Thema PEEK/POKE: Man muss natuerlich auch dazu sagen dass das BASIC V2 wirklich nicht das komfortabelste BASIC ist. Am besten zum Einstieg waere natuerlich schon ein BASIC, das zumindest so Befehle wie "COLOR" oder sowas kennt. Damit kann man direkt was anfangen was auf dem Bildschirm etwas bewirkt, und das ist dann fuer mich genauso direkt wie bei Scratch. Ein einfaches Programm welches Text ausgibt und dabei die Farben wechselt usw. ist dann schnell geschrieben ohne abstrakte POKE-Befehle, bei denen ich gut verstehen kann, dass diese keiner intuitiv findet.

    Also BASIC V3.5 vom C16/+4 wäre ideal gewesen? Wobei man die Textfarbe auch in V2 ohne Poke gesetzt bekommt. Sieht nur komisch aus mit den reversen Steuerzeichen.


    rotzdem finde ich es sinnvoll, sofort Code zu schreiben, denn das ist es, was man spaeter auch tut

    So mache ich das bei den ganzen kleinen Scripten, die ich für die Arbeit brauche.. Einfach mal loslegen, testen, fluchen, debuggen... bis es dann endlich läuft. Der iterative Ansatz eben. :)

  • Textfarbe kann man auch auf dem C64 mit Steuerzeichen aendern. Ich meinte jetzt eher auch bezogen auf Rahmen- und Hintergrundfarbe und sonstige Befehle. Ein PLAY-Befehl fuer Melodien usw. Ja, sowas gibt es in den spaeteren BASICs auf dem C64.


    Uebrigens fand ich Zeilennummern als Kind immer total cool und intuitiv. Konnte erstmal gar nicht verstehen warum die so verpoent waren. Auch GOTO fand ich eigentlich sehr cool. Aber so ist das halt - das womit man anfaengt, das bleibt halt haengen. Wenn man dann umsteigt auf was anderes, versteht man erstmal die Gruende nicht, warum das da ueberall anders ist.

  • Uebrigens fand ich Zeilennummern als Kind immer total cool und intuitiv. Konnte erstmal gar nicht verstehen warum die so verpoent waren.

    Was beim C64 fehlte war der Renumber-Befehl. Wenn man den hat (in BASIC 3.5 z.B. :)) sind Zeilennummern ein deutlich kleineres Problem.


    Aber so ist das halt - das womit man anfaengt, das bleibt halt haengen. Wenn man dann umsteigt auf was anderes, versteht man erstmal die Gruende nicht, warum das da ueberall anders ist.

    Nicht ganz, hin und wieder erkennt man auch, das etwas besser ist als was man bisher kannte und fragt sich wie man bis jetzt ohne auskommen konnte.

  • Ich finde, es gibt ja noch anderes neben Scratch und Basic. In den USA programmieren nicht wenige schon in der Schule in Swift – damit kann man dann auch gleich richtige Apps fürs iPad/iPhone/Mac entwickeln. Andere proggen in VB für Windows. Es geht ja erstmal nur ums lernen (auch von "modernen" Konzepten) und wenn das Ergebnis halt anfangs nur auf dem iPad läuft – egal. Immer noch besser, als wenn das Ergebnis nur auf einem Uralt-Rechner läuft, den "keiner" hat.


    Ich persönlich mochte es auch immer, wenn man am Computer das Gefühl hatte, "alles" machen zu können. So Lern-Sprachen, wie seinerzeit Logo fand ich doof, weil ich mich immer fragte, was man damit macht, wenn man gerade keine Schildkröte über den Bildschirm bewegen will. (Natürlich weiß ich heute, dass Logo mehr kann als Turtle-Graphics – aber welche bedeutenden Anwendung ist schon in Logo geschrieben?)


    Und was das Visuelle vs. "hartes coden" angeht: Moderne Entwicklungsumgebungen machen massiv Gebrauch von Auto-Vervollständigen und anderen Hilfen (da tippt auch keiner mehr einen Befehl falsch oder überhaupt ein), zudem werden oft Komponenten verwendet und nicht mehr alles von Adam und Eva an selbst geschrieben. Ich sehe jetzt keinen Vorteil darin, Kinder damit zu quälen, 3 Stunden lang nach dem fehlenden Semikolon zu suchen (nur damit sie begreifen, dass Coden kein Zuckerschlecken ist).

  • Ich sehe jetzt keinen Vorteil darin, Kinder damit zu quälen, 3 Stunden lang nach dem fehlenden Semikolon zu suchen (nur damit sie begreifen, dass Coden kein Zuckerschlecken ist).

    Ich schon. Es dauert aber keine 3 Stunden, der Compiler/Interpreter sagt dir schon ziemlich genau wo der Fehler ist.


    Warum sehe ich da einen Vorteil? Am meisten lernt man, wenn Dinge nicht so funktionieren wie sie sollen und Debuggen will gelernt sein, da braucht man immer wieder.


    Ich wäre da sogar sehr strikt. Wenn der Compiler auch nur eine Warning wirft ist das ein Fehler der zu beheben ist.

  • Wenn's ansatzweise um den Sinn der Anwendung und den zukünftigen Nutzen gehen soll und weniger um Spaß am Rumprobieren und dem Erlernen obsoleter Programmiersprachen auf historischen Computern, dann einfach gleich 'ne Engine wie Unity schnappen und 'nen 3D-Egoshooter für alle Plattformen raushauen. :D


    Basic ist einfach und schnell gelernt. so macht's Spaß, so isses geil.

    Was (für mich) eher eine "Spaßbremse" wäre, sind die 22 Spalten beim VIC20. Übersichtlichkeit hilft beim logischen Verständnis, aber auf dem VIC20 muss man ja 90% vom Code im Kopp cachen. :emojiSmiley-13:

    Die computerspezifischen Adressen für Poke & Peek zu "lernen" ist auch nix anderes als sich in Syntax und Libs reinzuarbeiten. Unbekannte Sachen, die ggf. auch erstmal unverständlich sind, muss man so oder so lernen. Später im Leben/Beruf wird einen die Sprache schon finden, die man lernen muss/will.


    Richtig bequem wurde es mit Amiga Basic, GFA-Basic oder auch QBasic. Auf dem PC hab ich FreeBasic für mich entdeckt. Sehr umfangreich und kompiliert läuft's als exe unter Windows. Hätte er mal lieber Raspis mit UAE hingestellt. ;)


    Empfehlung: ZeHas Basic-Heft "Weihnachten auf dem Commodore", dann sieht man mal, was sich mit BASIC V2 auf dem alten C64 so alles realisieren lässt. :)

  • Das war sehr gut, sehe ich auch so. Das mit "Poke & Peek ist (struktirell im Kopf) auch nichts anderes als.." u.a. .

    Dagegen halte ich aus heutiger Sicht Basic für die denkbar schlechteste Alternative, vor allem das alte zeilennummernbasierte. Das bringt einen nicht zu einem guten Programmierstil.

    Naja, anfangs zum Erlernen werden die Progamme ja noch nicht zu komplex, da geht das noch. Da brauchen die (kids) also noch keine Gosub oder Goto Orgien zum Abhandeln unübersichtlich eingefügter Prozeduren.

    Daher würde ich das eher fast andersherum sehen, dass Zeilennummern der Ordung im Kopf und der Logik eher zuträglich sind - für's erste Programmieren-Erlernen.

  • Bei einer modernen Programmiersprache bekommt man i.d.R. auch mehr als 80 Zeichen abzüglich Zeilennummer in eine Zeile. :)

    Einen VIC20 Programmierkurs ist was er ist und muss sich nicht mit modernen Sprachen messen. Oder geht da jemand mit der Erwartung hin, anschliessend direkt einen Job bei Microsoft zu bekommen? ;) Man kann immer sagen, es gibt sinnvolleres zu lernen, das gilt auch für viele andere Themen in der Schule.

    Wir könnten ansonsten gleich mit Töpferkurs vs. 3D-Drucken weitermachen.

  • Zum Lernen von Programmieren gibt es wohl bessere Systeme als das Basic des Commodore.

    Zu dem am Anfange des Threats beschriebenen Vergleich mit Scratch kann ich nur sagen, dass der Unterschied sehr groß ist - insbesondere bezüglich des intuitiven Umganges mit Parallelität.

    Wir machen eine Programmierkurs für Kids (CoderDojo) und beim Wechsel von Scratch zu Python, ist die Enttäuschung bei den Kids immer schon fast ein Entsetzen, wenn sie erfahren, dass das mit der Parallelität jetzt nicht mehr so einfach geht.


    Wofür man den Commodore wohl noch gut gebrauchen könnte ist nicht zum Lernen von Programmieren, sondern zum Lernen von "Computer".

    Also Fragen wie:

    • Was macht einen Computer aus?
    • Welche Eigenschaften hat den Prozessorhersteller festgelegt?
    • Welche Eigenschaften hat der Computerhersteller festgelegt?
    • Welche Eigenschaften hat der Betriebsystemhersteller festgelegt?
    • Welche Eigenschaften hat der Applicationshersteller festgelegt?

    Eine differenzierte Bertachtung ist bei neueren Systeme wesentlich komplizierter.

    Beim CEVI, ist das mit etwas rumPoken und dem durchforsten des Schaltplans, noch halbwegs vermittelbar.