Smalltalk のメッセージと、Scratch の読みづらさ¶
先日の CoderDojo 稽古終了後の一幕、他のメンターさんにたずねられた
と答えると。
「いやね、子ども達なりに工夫しているのはわかるのだけど、スクリプトを分割してて、あっちこっちに飛んでて、子ども達自身もわからなくなってしまっててね」
そして興味深い一言、
「 Smalltalk のメッセージタイプのオブジェクト指向の弱点が、Scratch で顕著に現れてしまったのかもね」
ほほう、興味深い。
ということで個人的にちょっと考えてみました。
そもそも「メッセージタイプのオブジェクト指向」とは¶
Smalltalk で調べて下さい。
というと投げやりすぎるので、
ここで 2 つ Smalltalk の凄さを他の記事を借りて紹介。
- なぜ我々は Smalltalk を使うのか（その 2: Smalltalk の良さ） – Sho Yoshida – Medium
- テスト駆動開発でお試しする Pharo Smalltalk ・第 1 回 はじめてのレッド、イエロー、グリーン - Qiita
自分がわざわざここに書く必要も無いだろう。
言葉じゃ分りづらいので、Pharo をダウンロードして使ってみてください。(結局投げっぱなし)
本題：なぜ Scratch のスクリプトがごちゃごちゃになるのか¶
さて本題。
曲がりなりにもメンターやってるので、後ろや発表の時に眺めるスクリプトを見てる限りで感じた事としては、
仮説 1、 メインルーチンが親子関係無く定義できるため¶
Scratch には「スタートした時」という命令(ブロック)がある。
もちろん、スタートボタンをクリックすると、そのブロックが先頭にくっついているブロックのまとまりは実行される。
これが幸か不幸か、次の問題をまねいている気がする。
仮説 2、 「同じ時に動かす→同じメッセージを受け取った時に……」ようにと考えがち¶
うん、正しい。君のその感覚は正しい。でも混乱の元なんだ。
僕の下手なたとえ話だけど、お料理の本って、ひとつの料理の作り方は、見開き同じページに書かれてるじゃない。
そして、最初に「材料がこれだけ必要で」という説明してから、「その材料をどう調理するか」って書いてると思う。
そしてな、ブロック 1 個が実行されて、結果がでるまでの時間って、ほとんど一瞬なんだな。
仮説 3、そもそもスクリプトがスプライト毎に持てるという事を把握していない？¶
「わかる」まで「わからない」と思ってしまうのだけど、別の絵(スプライト)には別のスクリプト(ブロック)を組み込むんだ。
だから、別の絵をクリックしたらブロックが無くなってしまうのは、 隠れて しまっているんだな。
問：Scratch でのきれいなスクリプトとは？¶
プログラミングを飯の種にしている人達には常識だろうけどよ。
責任分散(単一責任原則)¶
スプライト 1 個の中のスクリプトは、スプライト自身の動きに基本は徹するべきであり、他のスプライトに命令したいときはメッセージを使う。
全体のスプライトを制御したい時は、背景にスクリプトを組み込む。
のが良いと思う。
「なんか似たブロックが並んでる……」¶
「ブロックを作る」を使うのじゃ。(関数/メソッド定義)
「データ」も上手く使うと幸せになれるぞい。(変数定義)
「ブロックを作る」で作ったブロックの中で、作ったブロックも呼び出せるからな!!
まとめ¶
子どもの自由な発想は大切にしたいですが、かといって自分の臭いコードにうんざりして、プログラミングを嫌いになってしまったら、それはかなしいなって。
リファクタリング文化を持って来てしまうのは厳しすぎるかもしれないが、Scratch でもやってみる価値はあるのかも。ということで、
- Scratch でもコードレビュー|ペアプログラミング|モブプログラミング やってみる？
- 「ブロック使わない言語でも基本は同じだからな」って伝えておく
その前に、 「混乱しないスプリプトの組み方」 で紙芝居しないとな。
とはいえ Scratch の弱点¶
多分厳しいご指摘をいただくと思いますが、
- 一見見やすいけど、透明性がブロック数が増えてくと、途端に見辛くなる
- 全文検索とかしづらい（XML に落とし込んで……とかできるだろうけど）
P.S.¶
この記事は、Spacemacs という Emacs ディストリビューションでかきました。
Spacemacs: Emacs advanced Kit focused on Evil
はて、なんか昔似たような事をかいた気が。