AST Mutator（仮）の目的を言語化してみる
作りながらブレないよう、今のうちに言語化し始めておく
テキストプログラミングに慣れていない人が、構文を直感で理解できず、意図せず構文エラーを起こしてしまう問題
例えば、
, などの記号を１文字でも消すと動かなかったり、逆に、スペースや改行がいくつ含まれていても意味的に等価であったりと、納得しづらいルールが多数存在する 始めは「どうしてこんなルールがあるんだ？」と疑問に思うのだが、自分自身のプログラミングスキルが上がっていくと、次第に「厳格な方がありがたい」と思うようになる
実際、厳密でないと困ることの方が多いので、構文は曖昧であってはいけない
長いこと読んでいると目が慣れてきて、適切なインデントがあれば十分読めるようになる
{ や => など、構文的に意味のある記号がシンプル過ぎるせいで、特別な意味があることに気がつきづらい 一方、自然言語で書かれた文章では、基本的に予約語が存在しないため、「見えている通りの意味」になる
自然言語が優れているという訳ではない。例えば、Scrabox が、文章を箇条書きにすることによって読みやすくしているように、「見たままの意味をもつ記号」は文章の読みやすさを向上させる
箇条書き、空行、フォント（サイズ）、下線、枠線、矢印などは、おそらく、誰にでも意図通り伝えられる
カギ括弧、クォーテーション、斜体などは言語のコンテクストに依存するものの、目にする機会が多いので、概ね意図が伝わる
プログラミング言語のルールが厳格なのに対して、一般的なテキストエディタは自由度が高すぎる
キー１つで容易に構文を破壊できる
そもそも「テキストエディタ」とはあらゆる「テキスト」を編集するためのものであり、汎用化が求められる
「JavaScriptモードのあるエディタ」は存在するが、「JavaScript専用エディタ」はおそらく存在しない
コードを読めない人々がテキストエディタでコードを編集できないのは当然だと思われている？
ブロックプログラミングも、この問題を解決するアプローチの１つ
ただし、テキストプログラミング言語に比べると表現力が劣る
e.g. 変数のスコープを表現できない。MakeCode では、テキストモードで
if (true) { let x = 0; } と書いてブロックモードに変換すると、 let x = 0; if(true) {} のように変数が条件分岐ブロックの外に出てしまう e.g. オブジェクトの型を表現できない。Scratch では、数値、文字列、論理値はブロックの形で表現されているが、配列を「リスト」という独自の概念に置き換えていたり、構造体やクラスに相当する概念がない
上記の例はブロックプログラミング言語が発展途上にあることを表している。将来的には、例えばVR空間上でプログラミングをしたり、全く異なるパラダイムのプログラミングが一般化することで、テキストプログラミングの表現力を超える「なにか」が作られるかも知れない
AST Mutator（仮） のアイデア
ソフトウェアが「構文を知って」いれば、自力でコードを読めない人でも扱えるのではないか？
ソフトウェアが「ドキュメントを読んで」いれば、わざわざ調べなくてもコードの意味がわかるのではないか？
JavaDoc 形式で書かれたコメントを IDE が表示してくれるのは当たり前になっている
JavaScript でも、 Visual Studio Code などでは d.ts ファイルを参照して型によるヒントを提供している
CodeMirror や MonacoEditor などのレイヤーに相当する、JavaScript に特化した新しい UI コンポーネントを作る
まずは React Component として開発して、React のプロジェクトにインポートできるようにする
Pros
構文エラーを起こしづらいので、安心してコードを書き換えられる
Cons
あらゆるプログラミング言語に対応できる訳ではない
すでにあるコードを書き換えてデバッグするときなどでは、書き換えられる場所は限られてくる
数字や文字などのプリミティブを書き換えてみる
手続きの実行順を入れ替えてみる
console.log() や debugger などを差し込む 要らなそうなコードをコメントアウトしてみる
これらの「具体的な操作」を直感的に行えるようにしていくと良いかも
表現方法は、結局のところ既存のブロックプログラミング言語から良いところを持ってくることになりそう
そのほか、ピクトグラムとか、モチーフとか、言葉とか、うまく伝え方を考えていければいいな