プログラミング教育でロボットを動かすのが色々とありますが，比較のために同じロボットを大衆化として捉え直したらどんなプログラミング言語が作れるのか思考実験してみましょう．
たとえば，床を動くロボットがあったとして，床の上のあるコースにしたがって動き回るようにプログラムするとしましょう．まずは簡単のためにセンサーなどなくて，最初に決めた経路通りにしか動かないというもので考えます．
プログラミング教育としては，動かしたい経路に対して，それを必要な命令（前に進む，右に曲がる，左に曲がる）に分解して正しい順序で並べる訓練がプログラミングの基礎になるという考えなんだと思います．それはそれで教育の立場であればよいです．
それに対して大衆化の立場では，動かしたい経路があったとき，いかに簡単にその経路をロボットに入力するかが重要になります．たとえばそのロボットをその経路に沿う様に手で動かします．動かす前に記録始め，ゴールについたら記録終わり，というボタンを押してもよいでしょう．それによってロボットに経路が記録されました．次回からは，同じスタート位置にロボットを置けばなんどでも同じ経路通りに動いてくれます．
この方法ですと，ほぼストレートに入力できるので，動かしたい経路を考えることに専念できます．どう動かすのが面白い経路なのかを凝ることができます．一方で教育ではありませんからプログラミングのスキルはほとんどつきません．
しかしどちらの方法も「人間がやりたいことをコンピュータにやってもらう」ということで見れは同じです．一度覚えた動きはコンピュータは疲れずに何度でも正確に動いてくれます．そういったコンピュータの性質もどちらもまったく同じです．
方向の命令列でロボットを動かした場合と，手でロボットを動かしてその動きを覚えさせた場合，どちらも得られるものは同じなんですが，前者の方がプログラミングをやっている感がつよいですよね．それは何故なんでしょうね．
そもそもこの課題「最初に考えた経路にそって動かす」はプログラミング的につまらないものですね．やはり条件分岐や状態を持つようなプログラミングでなければ．
たとえば，経路の途中に障害物があった場合それを迂回する，というのはどうすればよいでしょうか．
プログラミング教育として考えるなら，前方に障害物があるかどうかを調べる命令や，条件分岐の命令などを導入する必要がありますね．そのとき，命令列のどこにセンサー命令を入れるのかが重要で，障害物が現れる場所に来た時に入れるということにしないとちゃんと調べてくれません．ここでイベントドリブンを導入するとさらに混乱しそうですね．
では大衆化の方でセンサーを入れた場合．色々なアイデアがありますが，一番易しいのは，まずはさっきと同じように障害物がない状況でロボットを手で動かして，動きを憶えさせます．次に，途中に障害物を置いて最初から動かします．同じ様に動いていって，障害物にぶつかりそうになってロボットは停止します．そこから自動的に記録モードにはいり，ロボットに障害物があるときの続きの動きを手でつかんで教えます．ゴールまで行ってもいいですし，途中で正常な経路に合流してもよくて，その場合はロボットがピピっと言ってくれるのでそこで手を離せば，記録終了．
これによって，ロボットの中にはセンサーと条件分岐と経路のプログラムが自動的に作られるはずです．障害物を増やすのは簡単ですし．たとえば懐中電灯で明るくして光センサーを反応させた状態で手で介入することで，明るくなった時の動きを教えることなんかもできるでしょう．これが大衆化したプログラミングのイメージです．やってみておかしければ修正する．ただそれを繰り返してゆくだけです．
これも大衆化ではありますが，これで色々と遊んでいるうちにもっとコンピュータの深い性質を直感的に獲得してゆく様に思います．教育的な要素も入っているということです．
一方で，大衆化をしないで低いレベルのプログラミングにこだわった教育ツールでは，ロボットを自在に動かすだけで息切れしてしまい，コンピュータの深い性質にはたどり着けないんじゃないでしょうか．
ちなみに，このアイデアはKidSimというビスケットの前進となった先行研究があるんですが，そこでやられていたものです．画面の中ですが．1995年ですよ．プログラミングの大衆化はGUIの登場と共に始まったのですが，いまでは本当に誰もやる人がいなくなった．