HN vorgestellt: Eine neue visuelle Programmiersprache für die Coding-Ausbildung von Kindern

 (pickcode.io)
4 Punkte von GN⁺ 2023-11-23 | 1 Kommentare | Auf WhatsApp teilen
  • Pickcode ist eine Online-IDE für den Informatikunterricht an Mittel- und Oberschulen und versteht sich als einfache, stabile Plattform, die den Zeitaufwand von Lehrkräften für die Unterrichtsorganisation reduziert
  • Chromebook-Unterstützung, Monitoring der Schülerarbeiten, Echtzeit-Zusammenarbeit und Einsicht in den Code-Verlauf sind zentrale Funktionen für das Unterrichtsmanagement
  • Lehrkräfte können Unterrichtsmaterialien und Aufgaben individuell anpassen und organisieren; Pickcode weist ausdrücklich darauf hin, keine KI-Codeassistenz zu bieten
  • Rückmeldungen von Lehrkräften besagen, dass Pickcode Schülern in Java-, Web-Development-, Python- und AP-Computer-Science-Principles-Kursen geholfen hat, leichter einzusteigen und selbstständiger zu arbeiten
  • Da das Tool stärker auf Kurserstellung und Schülerverwaltung ausgerichtet ist als auf komplexe Profi-IDEs, kann es im Klassenzimmer als Option gelten, die Ablenkungen reduziert

Eine Online-IDE für den Unterricht

  • Pickcode ist eine Online-IDE für den Informatikunterricht an Mittel- und Oberschulen
  • Der Fokus liegt auf einer einfachen und stabilen Plattform, mit der Lehrkräfte Zeit bei der Unterrichtsorganisation sparen
  • Es bietet grundlegende Einstiegspfade zu den Seiten für den Start, den Login und die Tarife

Funktionen für den Unterrichtsbetrieb und Reaktionen von Lehrkräften

  • Die wichtigsten Funktionen von Pickcode sind auf die Durchführung des Unterrichts und die Kontrolle von Schülerarbeiten ausgerichtet
    • Funktioniert auf Chromebooks
    • Schülerarbeiten lassen sich überwachen
    • Echtzeit-Zusammenarbeit wird unterstützt
    • Der Code-Verlauf lässt sich einsehen
    • Unterrichtsmaterialien können individuell angepasst werden
    • Aufgaben können organisiert werden
    • Es gibt keine KI-Codeassistenz
  • Lehrkräfte bewerten die Oberfläche als einfach, aber erweiterbar, und berichten, dass Schüler verschiedener Altersgruppen sie mögen
  • Es gibt Einsatzbeispiele in Java-, Web-Development-, Python- und AP-Computer-Science-Principles-Kursen
  • Enthalten sind Rückmeldungen, wonach Schüler das Tool leichter nutzen, ihre Arbeit nachverfolgen und selbstständiger vorankommen konnten
  • Auch das Support-Team wird als schnell reagierend und hilfreich bewertet; viele Vorschläge seien umgesetzt worden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-23
Hacker-News-Meinungen

  • Ich frage mich, ob es einen guten Grund gibt, die Schlüsselwörter var, set und call zwingend zu verlangen. BASIC hatte so etwas nicht, und in meiner verschwommenen Erinnerung daran, wie ich als Kind zum ersten Mal Programmieren gelernt habe, wären solche Schlüsselwörter wohl unnötige Komplexität gewesen.
    In LOGO konnte man zum Beispiel einfach forward 10, left 90 schreiben; call paint.forward(10), call paint.left(90) wirkt übertrieben und noisy.

    • Die Schlüsselwörter wurden eingeführt, damit sich jede Zeile leicht laut vorlesen lässt. Gerade bei set x = 7 macht das Schlüsselwort klar, ob man eine Variable ändern oder Gleichheit behaupten will.
      Technisch könnte man im Kontext eines Zeichenprogramms forward() auch zu einer Top-Level-Methode machen, aber mit Blick darauf, dass die Schüler später zu einer 2D-Game-Engine wechseln und mehrere Sprites steuern, haben wir uns entschieden, es etwas objektorientierter zu machen.
    • Die Namen wirken hier auf mich etwas wenig intuitiv. forward und left sehen wie Bewegungsrichtungen aus, was besonders dann verwirrend ist, wenn man den Maler „nach links bewegen“ möchte.
      Tatsächlich ist forward Zeichnen/Bewegen, und left ist eine Drehung gegen den Uhrzeigersinn, die auch negative Argumente annimmt; daher wären call paint.draw(10), call paint.rotate(90) oder rotate("up") für mich verständlicher.
    • Das verrät wohl mein Alter, aber in dem BASIC, das ich zuerst gelernt habe, gab es den gosub-Befehl für Subroutine-Aufrufe.
      Nebenbei habe ich die Linknummern auch bei 1 beginnen lassen, weil frühe BASICs das offenbar so gemacht haben :)
      [1] https://picaxe.com/basic-commands/program-flow-control/gosub...
      [2] https://alandix.com/blog/2021/07/27/a-brief-history-of-array...
    • In dem Basic, das ich benutzt habe, gab es LET X=10.
    • Mein erster Eindruck war derselbe. Ich sehe den ganzen Tag deutlich komplexeren Code, aber wenn ich aus der Perspektive eines kleinen Kindes denke, könnte dieses unnötige Rauschen ziemlich leicht zu Missverständnissen führen.

  • Ich führe gerade ein 10-jähriges Kind an Godot heran. In den letzten sechs Monaten hat es Spiele mit Scratch gebaut und mag Scratch, war aber auch von dessen Grenzen frustriert.
    Ich dachte, eine echte Skriptsprache würde ihm besser gefallen, aber sobald es mit GDScript anfing, war es wegen der Menge an Tipparbeit schnell frustriert. Die Hände sind klein, Touch Typing ist schwer zu lernen, und das Tippen von Variablennamen und Methodenaufrufen dauert viel zu lange.
    Das hier sieht nach genau der richtigen Balance aus, ich werde es mir ansehen.

    • Die Begrenzung durch Tippgeschwindigkeit ist ein wirklich guter Punkt, und seltsamerweise hatte ich daran überhaupt nicht gedacht.
      Ich mache mit einem 3-jährigen Kind einen sehr leichten Python-Unterricht und habe mich gefragt, warum der Fortschritt im Verhältnis zum Verständnis so langsam ist. Jetzt sehe ich, dass allein das Tippen von Dingen wie Klammern und Anführungszeichen viel Zeit gekostet hat.
      Mir gefällt dieses Projekt, und ich freue mich darauf, es auszuprobieren. Ich ändere gerade meine Meinung dahin, dass bei Programmierung für Kinder gilt: je mehr, desto besser. Es dürfte gut sein, sie der Dynamik auszusetzen, zwischen mehreren Sprachen und Workflows zu wählen.
    • Ich frage mich, warum man keine Tastatur in Kindergröße verwendet.
    • Meine Erfahrung ist ähnlich. Ich habe meinem Sohn mit 8 Scratch vorgestellt, und zwei Jahre später baut er inzwischen deutlich anspruchsvollere Spiele, als ich erwartet hatte.
      Wenn ich ihm aber eine „echte“ Programmiersprache zeige, sagt er, dass man das alles auch in Scratch machen könne und nicht so viel tippen müsse.
      Wir haben auch zusammen GameMaker ausprobiert und tolle Ergebnisse erzielt, aber sobald man kurz nicht hinsieht, ist er wieder bei seinen Scratch-Projekten. Manchmal frage ich mich, ob es besser gewesen wäre, wenn er wie ich früher direkt mit Code angefangen hätte ;-)
    • Ich hatte den Eindruck, dass die Grenzen von Scratch darin liegen, dass einem Kind nicht klar ist, wie man die Komplexität verwaltet, wenn das Programm zu groß wird.
      Es reicht aber oft schon, auf das Problem hinzuweisen und zu fragen, was man tun könnte, damit das Kind darüber nachdenkt und innerhalb von Scratch verschiedene mögliche Wege findet. Zum Beispiel, indem man das Programm in mehrere Objekte oder Agenten aufteilt.
      Scratch ist viel mächtiger, als der erste Eindruck oder das erste Programm vermuten lässt.
    • GDScript ist eine erstaunlich gute Sprache. In vielerlei Hinsicht besser als Python, zum Beispiel hat sie var und const.

  • Glückwunsch zum Launch von Pickcode. Der Feinschliff ist gut, und man merkt, dass es mit Sorgfalt gebaut wurde.
    Bei visueller Programmierung, die Programmieren für Nichtentwickler zugänglicher machen will, sehe ich mindestens zwei Strömungen.
    Manche Ansätze reduzieren mit einer visuellen Oberfläche die Belastung durch das Lernen der Syntax, verbergen aber weder den imperativen Charakter noch die Notwendigkeit algorithmischen Denkens. Im Grunde sind das IDEs mit einem anderen Accessibility-Niveau; Pickcode und Scratch würde ich in diese Kategorie einordnen.
    Die andere Seite erkundet andere Programmierparadigmen, die bis zu einem gewissen Grad besser zu visuellen Metaphern passen können. Sie regt Nutzer auch zu einer anderen Denkweise an als imperative Programmierung. Node-RED ist ein gutes Beispiel für die Erkundung von Flow-based Programming, einem nahen Verwandten der funktional-reaktiven Programmierung. LabVIEW ist ebenfalls ein naher Verwandter auf Basis von Dataflow, hat aber mehr magische Elemente. In Wirklichkeit sind das ziemlich clevere Defaults und interne Variablennamen. Auch Apple Automator kommt mir in den Sinn.
    Ich sehe keine der beiden Seiten zwangsläufig als besser oder schlechter, aber bei visuellen Sprachen ist die Unterscheidung zwischen imperativ und reaktiv hilfreich, weil sie die Endnutzererfahrung stark verändert.

    • Ich erinnere mich, dass es tatsächlich leichter war, Anfängern Workshops zu funktionalen Sprachen wie Elm zu geben als Experten. Der Kopf von Anfängern ist nämlich nicht von einer Art imperativem C-Denken verunreinigt.

  • Dass „die Code-Editor-Erfahrung vollständig strukturiert ist und man statt zu tippen aus Menüs auswählt“, ist ziemlich cool.
    Ich wünschte, es gäbe so etwas für erwachsene Programmierer: einen universellen strukturellen Editor, der sich für mehrere Programmiersprachen verwenden lässt. Wenn man programmiert, ist die Absicht, die einem zuerst in den Sinn kommt, semantisch: hier eine Funktion definieren, dort eine Bedingung prüfen und so weiter.
    Warum also diese semantische Absicht nicht direkt an den Editor übergeben? Warum muss man die Absicht erst als String serialisieren, damit der Editor sie anschließend wieder auf fehleranfällige Weise parst? So entsteht Raum für dumme Syntaxfehler wie Tippfehler, nicht zusammenpassende Klammern oder Fehler bei der Operatorpräzedenz. Wäre es nicht besser, wenn nur semantische Fehler übrig blieben?
    So ein Editor müsste auch nicht zwangsläufig tastaturunfreundlich sein. Ähnlich wie Excel nicht tastaturunfreundlich ist. Ich könnte mir vorstellen, dass er wie Eingabemethoden für ostasiatische Sprachen funktioniert: Man tippt in ein „Kompositionsfenster“ und wählt dann im „Kandidatenfenster“ aus, was eingefügt werden soll.

    • Solche Versuche gab es viele. Das ist weniger eine „Idee, auf die noch niemand gekommen ist“, sondern eher eine „Idee, über die sehr viele Leute nachgedacht und die sie ausprobiert haben, nur um sofort auf ein großes Problem zu stoßen“.
      Soweit ich es verstehe, besteht das große Problem hier darin, dass man dazu neigt, die Einschränkung erzwingen zu wollen, dass jeder Zwischenzustand, den der Code durchläuft, semantisch gültig sein muss. Oberflächlich wirkt das attraktiv, in der Praxis ist es aber eine fatale Einschränkung. Auch brillante Leute denken zunächst etwas unscharf und korrigieren ihren Code später, sogar innerhalb einer einzelnen Zeile. Der Zwang, immer zu 100 % gültig zu sein, passt schlecht dazu, wie Menschen tatsächlich denken.
      Ich neige dazu, diese Diskrepanz für grundlegend zu halten. Ich weiß nicht, ob überhaupt ein winziger Teil der Menschen auf diese Weise denkt. Selbst professionelle Mathematiker denken in der tatsächlichen Arbeit angeblich oft voraus und füllen die Strenge erst später aus. Wenn nicht einmal sie streng Schritt für Schritt vorgehen, wer dann?
      Beim Programmieren hat sich semantisch informierte Autovervollständigung mit Vorschlägen etabliert, und das ist wahrscheinlich nicht bloß das Ergebnis von Bequemlichkeit, sondern ein tatsächliches Optimum.
      Vielleicht lässt sich das Problem lösen, wenn jemand es konsequent zu Ende treibt, aber falls hier Früchte hängen, dann sind es jedenfalls keine niedrig hängenden.
      Wie saurik sagte, kommt die Lisp-Welt mit Emacs dem am nächsten, aber auch dort kann man immer noch tun, was man will. Es gibt nur viele Werkzeuge, die dabei helfen, semantischer zu arbeiten; absolut erzwungen wird es nicht.
    • Ich glaube, davon gibt es ziemlich viele. Scratch oder sein Verwandter Snap (https://snap.berkeley.edu/snap/snap.html), ein visueller Flow-Editor für React (https://app.flowhub.io/#project/c111454c9fd2f74d37d1e8a4e739...) sowie ähnliche Dinge wie https://retejs.org/ gibt es zum Beispiel.
    • Du sagtest, du wolltest so etwas für erwachsene Programmierer; Blythe Omnis 7 gab es schon 1996 oder früher. Das war eine RAD-Plattform/-Lösung, die sowohl Windows als auch Macintosh unterstützte.
      Ich bekam damals den Job, weil ich der einzige Bewerber war, der von der Software gehört hatte. Das lag daran, dass ich einmal einen kurzen Artikel in einer Zeitschrift gelesen hatte.
      https://en.wikipedia.org/wiki/Omnis_Studio
      Die Art zu programmieren, indem man Dropdown-Listen und Pop-ups anklickte, war nicht besonders gut gestaltet. Ein Programm sah wie eine Liste aus, und wenn man eine Zeile bearbeiten wollte, erschien ein modaler Dialog, in dem man genau diese eine Zeile ändern konnte. IntelliSense oder Code Completion gab es natürlich nicht.
      Allein beim Gedanken daran kommt wohl PTSD hoch, sodass ich fast Alkohol oder Zigaretten bräuchte.
    • Zum Beispiel ist https://github.com/nocode-js/sequential-workflow-designer genau so gestaltet. Man programmiert Logik, indem man vordefinierte Aktionen in die richtige Reihenfolge bringt, und programmiert damit auf hoher Ebene.
    • Soweit ich weiß, machen Leute, die Lisp mit Emacs bearbeiten, diese Erfahrung. Denn sie können nicht als bloßer Text denken und arbeiten, sondern in Forms.

  • Eine meiner Lieblingsfunktionen von Scratch ist, dass man keine Syntaxfehler erzeugen kann. Blöcke passen entweder zusammen oder sie passen nicht zusammen. Deshalb können Kinder meiner Meinung nach leichter einsteigen und herumspielen, ohne zusätzliche Erklärungen oder Nachhilfe.
    Nachdem ich die ersten paar Schritte des Rechteck-Tutorials befolgt hatte, klickte ich selbst ein wenig herum, und es entstand call math paint.forward(), was einen Syntaxfehler verursachte. Natürlich ist diese Zeile Unsinn, aber ich konnte nicht herausfinden, wie der Befehl math funktionieren soll. Wenn man dem Tutorial weiter folgt, wird es vermutlich erklärt, aber ich finde auch Auffindbarkeit wichtig.

    • Scratch lässt zwar keine Syntaxfehler entstehen, beschwert sich aber auch nicht, wenn etwas nicht an seinem Platz ist. Wenn man zum Beispiel mit Blöcken hantiert und einer abfällt, läuft das Programm zwar, funktioniert aber nicht richtig.
      Wenn es viele Blöcke werden, können sie sich auch überlappen, sodass es ziemlich schwierig wird, das zu finden. Außerdem kann man Argumente von Blöcken weglassen. Es läuft trotzdem, funktioniert aber nicht.
      Visuelle Programmierung ist für Kinder sicher besser, aber ich denke, man braucht einen strengeren Ansatz als Scratch und bessere Debugging-Fähigkeiten.
    • Ein weiterer Vorteil von Scratch, genauer gesagt der Blöcke, ist, dass man sie ziemlich leicht an eine neue Sprache anpassen kann. Wir haben Blöcke verwendet, damit IoT-Kunden Geräte so konfigurieren konnten, dass sie auf Events reagieren und Events an andere Geräte senden; all das wurde in eine hochgeladene JSON-Konfiguration umgewandelt.

  • Sieht wirklich gut aus. Das erinnert mich an die Zeit, als wir bei Khan Academy eine blockbasierte Version des ProcessingJS-Editors gebaut haben.
    Die UI war etwas sperrig und schwer zu warten, deshalb haben wir sie am Ende eingestellt, aber das hier sieht ziemlich geschmeidig aus. Mir gefällt, dass es neuen Programmierern mehr Wege in typisiertes Programmieren eröffnet. Ich finde auch, dass der Großteil des Block-Codings zu weit von echtem Code entfernt ist.

    • Solche Block-Editor-UIs sollten sich eigentlich automatisch aus einer abstrakten Beschreibung der Grammatik generieren lassen, wie sie etwa tree-sitter-Parser verwenden.
      Manchmal kann diese blockbasierte Bearbeitung auch mit Typprüfung kombiniert werden, sodass „Löcher“ intelligent und abfragebasiert gefüllt werden können. Am deutlichsten sieht man das vermutlich bei Editoren für rein funktionale Sprachen wie Agda.

  • Erinnert mich an BASIC auf dem ZX81. Man tippte die Schlüsselwörter nicht ein; auf der Spezialtastatur gab es für jedes Schlüsselwort eine eigene Taste.
    Der Editor war kontextsensitiv, anders gesagt: Der Benutzer selbst war der vom Parser gesteuerte Lexer. Damals wirkte es ein wenig magisch, herauszufinden, ob man ein Wort/eine Zahl eingeben wollte oder ein Schlüsselwort – und welche Art von Schlüsselwort. Der pädagogisch wichtige Punkt war eigentlich, dass ich das wusste.
    Wichtig am ZX81 war, dass er Tokens speicherte, um Speicher zu sparen, statt eine Textrepräsentation abzulegen. Er hatte 1 KB RAM, einschließlich Displayspeicher. Eine separate GPU gab es nicht. Das Parsen bei der Eingabe dürfte auch die Ausführung beschleunigt haben.

  • Die Website ist sehr gut poliert, aber mit dem Ziel bin ich nicht ganz einverstanden. Es ist eine beeindruckende IDE, aber ich hätte mich wohl eher auf eine Teilmenge von Python konzentriert als auf eine neue Sprache.
    Andernfalls könnte sie ignoriert werden, weil Scratch leichter zu unterrichten ist und Python nützlicher zu lernen. Ersteres gilt für Schulen mit Lehrkräften, die Entwickler sind; Letzteres für programmierende Eltern, die ihrem Kind etwas beibringen.
    Als Softwareentwickler habe ich einmal beim Programmierunterricht meiner Frau in der Grundschule/im Kindergarten geholfen und kenne die Probleme in diesem Bereich daher ein Stück weit.

    • Ich frage mich, ob es Alternativen gibt, die einer „Teilmenge von Python“ entsprechen. Eine natürliche Brücke hin zu „echter“ Programmierung wäre interessant.

  • Verwandte Beiträge:
    Show HN: Pickcode – A new way to introduce programming to kids - https://news.ycombinator.com/item?id=33562193 - November 2022, 14 Kommentare
    Show HN: PickCode – An educational coding environment for students after Scratch - https://news.ycombinator.com/item?id=32230329 - Juli 2022, 32 Kommentare
    Show HN: Pickcode – A graphical code editor for education - https://news.ycombinator.com/item?id=31426331 - Mai 2022, 4 Kommentare
    Reposts sind nach etwa einem Jahr in Ordnung; die Links zu früheren Threads sind für Leser gedacht, die mehr erfahren möchten.

  • Ich arbeite an einem ähnlichen Konzept im Bereich Musikprogrammierung:
    https://glicol.org
    Es wäre gut, wenn es direkt auf der Landingpage ein paar Beispiele gäbe.
    Wenn man die Lektion ausprobiert, bleibt man stecken; rechts gibt es zwar Hinweise, aber sie fallen nicht besonders auf. Man könnte sie vielleicht wie im Svelte Tutorial (https://learn.svelte.dev/tutorial/welcome-to-svelte) anders anordnen.
    Bei der Syntax bin ich mir nicht sicher. Ich frage mich, ob ihr auch in Betracht gezogen habt, LOGO zu verwenden.