HN紹介: 子どものコーディング教育のための新しい視覚言語
(pickcode.io)- Pickcodeは中学・高校のコンピュータサイエンス授業向けのオンラインIDEで、教師が授業運営に使う時間を減らすシンプルで安定したプラットフォームを目指している
- Chromebook対応、生徒の作業モニタリング、リアルタイム協業、コード履歴の確認が主要な授業管理機能である
- 教師は授業資料と課題をカスタマイズして整理でき、PickcodeはAIコード補助機能がないことを明示している
- Java、Web Development、Python、AP Computer Science Principlesの授業で、生徒がより簡単に取り組み、独立して作業するのに役立ったという教師の評価がある
- 複雑な専門IDEよりも授業作成と生徒管理に焦点を当てたツールであり、教室環境で気が散る要素を減らす選択肢と見なせる
教室向けに作られたオンラインIDE
- Pickcodeは中学・高校のCS授業向けのオンラインIDEである
- 教師が授業運営の時間を節約できるよう、シンプルで安定したプラットフォームを強調している
- はじめる、ログイン、料金プランのページへつながる基本的な導線を提供している
授業運営機能と教師の反応
- Pickcodeの主な機能は授業の進行と生徒の作業確認に合わせて設計されている
- Chromebookで動作する
- 生徒の作業をモニタリングできる
- リアルタイム協業をサポートする
- コード履歴を確認できる
- 授業資料をカスタマイズできる
- 課題を整理できる
- AIコード補助機能がない
- 教師たちは、インターフェースはシンプルだが拡張性があり、さまざまな年齢層の生徒に好評だと評価している
- Java、Web Development、Python、AP Computer Science Principlesの授業での活用事例がある
- 生徒がツールをより簡単に使い、作業を追跡し、独立して進めるのに役立ったという反応が含まれている
- サポートチームは対応が速く親切で、提案事項の多くが実装されたという評価もある
1件のコメント
Hacker News のコメント
var、set、callキーワードを必須にする十分な理由があるのか気になる。BASIC にはそういうものはなかったし、子どものころ初めてプログラミングを学んだおぼろげな記憶からすると、こうしたキーワードは不要な複雑さだったように思うたとえば LOGO では単に
forward 10、left 90のように書けたのに、call paint.forward(10)、call paint.left(90)は過剰でうるさく感じるset x = 7では、変数を変更しようとしているのか、等価性を主張しようとしているのかをキーワードが明確にしてくれる技術的には描画プログラムの文脈で
forward()をトップレベルのメソッドにすることもできるが、後で生徒が 2D ゲームエンジンに進み、複数のスプライトを制御する場合に備えて、もう少しオブジェクト指向的にすることにしたforwardとleftは移動方向のように見えるので、特に絵描きを「左に移動」させたいときに紛らわしい実際には
forwardは描画/移動で、leftは負の引数も受け取る反時計回りの回転なので、call paint.draw(10)、call paint.rotate(90)、またはrotate("up")のほうがしっくりくるgosubコマンドがあったちなみに初期の BASIC がそうだったということで、リンク番号も 1 から始めるように付けた :)
[1] https://picaxe.com/basic-commands/program-flow-control/gosub...
[2] https://alandix.com/blog/2021/07/27/a-brief-history-of-array...
LET X=10があった10歳の子に Godot を紹介しているところ。ここ半年は Scratch でゲームを作っていて、Scratch は好きだが、その限界にも苛立っていた
本物のスクリプト言語を使えばもっと気に入ると思っていたが、GDScript を使い始めた途端、タイピング量のせいですぐに挫折した。手が小さくてタッチタイピングを身につけるのが難しく、変数名やメソッド呼び出しを打つのに時間がかかりすぎる
これはちょうどよいバランスに見えるので、試してみるつもり
3歳の子とごく軽い Python の授業をしているが、理解度のわりに進みがなぜ遅いのか不思議だった。今思えば、括弧や引用符のようなものを打つだけでも時間がかかっていたのだ
このプロジェクトは気に入ったし、使ってみるのが楽しみだ。子ども向けプログラミングは多ければ多いほどよいという考えに変わりつつある。複数の言語やワークフローから選ぶという力学に触れさせるのもよさそう
ところが「本物の」プログラミング言語を見せると、それは全部 Scratch でもできるし、わざわざそんなにたくさんタイピングする必要はないと言う
GameMaker も一緒にやってみて、見事な成果を作ったが、少し目を離すとまた自分の Scratch プロジェクトに戻っている。ときどき、昔の自分のように最初からコードで始めていたほうがよかったのだろうかと思うこともある ;-)
ただ、問題を指摘して、どうできると思うかを尋ねるだけでも、子どもはその問題を考え、Scratch の中で可能なさまざまな方法を見つけるようになる。たとえばプログラムを複数のオブジェクトやエージェントに分ける、といった具合だ
Scratch は第一印象や最初のプログラムが示唆するよりも、はるかに強力だ
varとconstがあるPickcode のリリースおめでとう。細部の完成度が高く、丁寧に作られていることが伝わってくる
非開発者にとってプログラミングをより近づきやすくしようとするビジュアルプログラミングには、少なくとも二つの流れがあると思う
ある試みは、ビジュアルインターフェースによって構文学習の負担を減らすが、命令型としての性質やアルゴリズム的思考の必要性は隠さない。実質的にはアクセシビリティのレベルが異なる IDE と見なせるもので、Pickcode と Scratch はこの範疇に入ると思う
もう一方は、ビジュアルな比喩とある程度相性がよい別のプログラミングパラダイムを探求する。ユーザーにも命令型プログラミングとは異なる考え方を促す。Node-RED はフローベースプログラミングを探求する良い例で、これは関数型リアクティブプログラミングに近い親戚だ。LabVIEW もデータフロー型の近い親戚だが、より多くの魔法のような要素がある。実際には、かなり賢いデフォルト値と内部変数名付けである。Apple Automator も思い浮かぶ
どちらが必ずしも優れている、劣っているとは思わないが、ビジュアル言語を見るときに命令型とリアクティブの区別を考えると、最終的なユーザー体験が大きく変わるという点は有用だ
「コード編集体験は完全に構造化されていて、タイピングの代わりにメニューから選ぶ」という点がとても素晴らしい
大人のプログラマー向けにこういうもの、つまり複数のプログラミング言語で使える汎用の構造化エディタがあればいいのにと思う。プログラミングするとき、まず頭に浮かぶ意図は意味論的なものだ。ここで関数を定義し、そこで条件を確認する、という具合に
それなら、なぜその意味論的な意図をエディタに直接伝えてはいけないのか分からない。なぜまず意図を文字列にシリアライズしてから、エディタがそれをまたエラーの起きやすい方法でパースしなければならないのか疑問だ。タイプミス、括弧の不一致、演算子の優先順位ミスのようなばかげた構文エラーが入り込む余地を作るより、意味論的なエラーだけが残るほうがよいのではないかと思う
こういうエディタが必ずしもキーボードに不親切である必要もない。Excel がキーボードに不親切ではないのと似ている。東アジア言語の入力メソッドのように、「変換ウィンドウ」に入力し、「候補ウィンドウ」から選んで挿入する方式でも動かせそうだ
私の理解では、この場合の大きな問題は、コードが通過するすべての中間状態が意味論的に有効でなければならない、という制約をかけたくなる点だ。表面的には魅力的だが、実際には致命的な制約になる。優れた人たちも多少ゆるく考えてから後でコードを直すし、それは1行単位でも同じだ。常に100%有効でなければならないという強制は、実際の思考方法と大きくずれている
このずれは根本的なものだと見ている。人間のごく一部でもこのように考えるのかは分からない。専門の数学者でさえ、実際の作業では先回りして考え、その後で厳密さを埋めることが多いという。彼らでさえ一段階ずつ厳密に前進しないのなら、いったい誰がそうするのだろうと思う
プログラミングは意味を理解する自動補完と提案に落ち着いたし、それは単なる怠慢の結果ではなく、実際の最適点である可能性が高い
誰かが最後まで押し通せば問題は解けるかもしれないが、ここに果実があるとしても、低いところにぶら下がった果実ではないと言いたい
saurik が言ったように、Emacs を使う Lisp の世界がこれに最も近いが、それでもやりたいことは何でもできる。ただ、より意味論的に作業するのを助けるツールが多いだけで、絶対的に強制されるものではない
当時、そのソフトウェアを聞いたことがある唯一の応募者だったので仕事を得た。雑誌で短い記事を一度読んでいたおかげだ
https://en.wikipedia.org/wiki/Omnis_Studio
ドロップダウンリストやポップアップをクリックしてプログラミングする方式は、それほどよく設計されているとは言えなかった。プログラムはリストのように見え、1行を編集しようとするとモーダルダイアログが出て、その1行だけを直せた。IntelliSense やコード補完は当然なかった
思い出すだけで PTSD がよみがえりそうで、酒かタバコが必要になるほどだ
Scratch で最も好きな機能の1つは、構文エラーを作れないことだ。ブロックははまるか、はまらないかのどちらかだ。だから子どもたちは、別途説明や個別指導がなくても、より簡単に始めて遊べるのだと思う
四角形チュートリアルの最初の数ステップを追ったあと、あれこれクリックして自分で試してみたところ、
call math paint.forward()が作られて構文エラーになった。当然その行はゴミだが、mathコマンドがどう動くべきなのかは分からなかった。チュートリアルをさらに進めれば説明が出てくるのだろうが、発見可能性も重要だと思うブロックが増えると互いに重なることもあり、見つけるのがかなり難しくなる。ブロックの引数を入れ忘れる問題もある。それでも実行はされるが動かない
ビジュアルプログラミングは子どもにとって明らかにより良いが、Scratch より厳格なアプローチと、より優れたデバッグ能力が必要だと思う
本当に見栄えがいい。Khan Academy で ProcessingJS エディタのブロックベース版を作っていた頃を思い出す
UI が少し粗く、保守も難しかったので結局やめたが、これはかなり滑らかに見える。新しいプログラマーが型付きプログラミングに入っていく道をより多く提供している点がよい。ブロックコーディングの大半は実際のコードから離れすぎているとも思う
ときには、こうしたブロックベース編集が型検査と組み合わさり、「穴」を賢くクエリベースで埋められるようにすることもある。おそらく Agda のような純粋関数型言語向けのエディタで最も顕著に見られる
ZX81のBASICを思い出した。キーワードをタイピングするのではなく、特殊なキーボードに各キーワード用のキーがあった。
エディタは文脈依存型で、言い換えれば、パーサーに導かれる字句解析器がユーザー自身だった。当時は、単語や数字を入力しようとしているのか、キーワードを入力しようとしているのか、またどの種類のキーワードなのかを見分けるのが、少し魔法のように感じられた。実際、教育的に重要なのは、自分がそれを理解していたという点なのだが。
ZX81で重要だったのは、テキスト表現の代わりにトークンを保存してメモリを節約していたことだ。RAMは1KBで、その中にディスプレイメモリまで含まれていた。別個のGPUもなかった。入力時にパースすることで、実行もより速くなっていたはずだ。
サイトは非常によく磨き込まれているが、目標には完全には同意しない。印象的なIDEではあるものの、新しい言語よりもPythonのサブセットに注力しただろうと思う。
そうでないと、Scratchのほうが教えやすく、Pythonのほうが学ぶ価値が高いという理由で見向きされない可能性がある。前者は開発者である教師がいる学校に、後者は子どもに教えるプログラマーの親に当てはまる。
ソフトウェア開発者として、妻の小学校・幼稚園でのプログラミング授業を手伝ったことがあり、この領域の課題はある程度分かっている。
関連記事:
Show HN: Pickcode – A new way to introduce programming to kids - https://news.ycombinator.com/item?id=33562193 - 2022年11月、コメント14件
Show HN: PickCode – An educational coding environment for students after Scratch - https://news.ycombinator.com/item?id=32230329 - 2022年7月、コメント32件
Show HN: Pickcode – A graphical code editor for education - https://news.ycombinator.com/item?id=31426331 - 2022年5月、コメント4件
再投稿は1年ほど経てば問題なく、以前のスレッドへのリンクは、さらに知りたい読者のためのものだ。
似たようなコンセプトを音楽プログラミング向けに作業中:
https://glicol.org
ランディングページにすぐいくつか例があるとよさそうだ。
レッスンを試してみると行き詰まるが、ヒントは右側にあるものの、あまり目立たない。Svelte Tutorial(https://learn.svelte.dev/tutorial/welcome-to-svelte)のように配置し直せるかもしれない。
文法には確信が持てない。LOGOを使うことも検討したのか気になる。