12_Inou
Touch UI Programing†
「タッチＵＩのプログラミング環境が必要」†
仮説：「今後３年間でキーボード端末は駆逐される」†
- 根拠：Windows8、iPad等、タブレット端末は増える一方。
- 小仮説：タブレット端末のカジュアル性（いつでもどこでも）の利便性がキーボートによる入力の高速性を上回る。
仮説：「日常的にプログラミングに触れる必要性の増大」†
- 根拠：安価なスマートフォン「FirefoxOS」の普及。（このOSはすべてがHTMLで作られている）
- 根拠：ユビキタス社会が実現するとプログラミングの必要性が増える
- 根拠：小中学校へのプログラミング教育の普及（プログラミングを知らないと生きていけない）
- 問題点：「プログラミング言語の学習コストよりも環境の構築の方が困難」
- 根拠：中学校のころLEGO Mindstormを触った経験。
- 根拠：楽譜はプログラミング言語とほぼ同じ機能を持っている。（むしろ音楽はプログラムである）
- 根拠：小学生でも楽譜読めるのにプログラミング言語が読めないはずがない。
仮設：「プログラム実行環境はWebへ移る」†
- 根拠：HTML5の普及
- 根拠：マルチデバイス対応の解決策としてのブラウザで動くWebアプリ。
- 仮説：「今後３年間でキーボード端末は駆逐される」
- 仮説：「プログラミングの必要性は増え続ける」
- 仮説：「日常的にプログラミングに触れる必要性の増大」
- 故に「タッチＵＩのプログラミング環境が必要」である。
タッチＵＩのプログラミング環境とは†
- プログラミングにキーボードが不要、あるいはほとんど使わない。
- バーチャルキーボードによるコーディングは難しい。
- カーソルの移動が困難。
つまり†
- プログラミングのコード入力はタッチＵＩが基本
問題点†
- タッチUIにするにはIDEが必要
- CUIの時代にはキーボードに特化したプログラミング環境、いわゆる「エディタ」が流行った。（Vim、Emacs等）
- GUIの時代にはキーボードとマウスを併用したプログラミング環境、いわゆる「総合開発環境」が流行った。（Eclipse、VisualC++等）
- TouchUIの時代にはタッチ操作に特化したプログラミング環境が必要とされる。
- マウス主体となるグラフィカルプログラミング環境はマウスの不便さ故廃れた。（LEGO Mindstorm等）
- が、今後タッチUIの普及で復活する見込みがある
これまでの状況†
ぼくの提案†
ぼくが求めているもの†
- あらゆるデバイスで開発、あらゆるデバイスで実行。
- HTML+CSS+JSというWebアプリで完結した開発環境。
- タッチパネルでも、キーボードでも、ゲームパッドでも快適なプログラミング環境。
- ゆるふわな専用言語（Processing等）ではなく、ローレベルAPIにアクセス可能な言語。
- タッチUIに対応しつつも、キーボードでも編集可能な言語
上記条件をすべて満たしている「Lisp」†
LISP - Wikipedia
- 最古参にして現代の言語に負けない（というかもう絶対に負ける見込みのない）最強言語。
- Lispに特徴的な*1)を多用したコードが、タッチUIに向いている。
- 括弧を単位としているので、それをブロックと見なせる。
- JavaScriptはLispを元に作られた。
- Lispのほぼすべての機能をJavaScriptは持っている。
先行研究†
- ClojureJS
- Lisp -> JavaScriptの唯一の実装。
- でもJVMで動く言語を無理やりJSに当てはめているだけなので無理がある
プログラミング言語「Pebble（仮）」†
(= fizzbuzz (fn (n)
([1..n] 'map (fn (i)
(if
(=== (% i 15) 0) "fizzbuzz"
(=== (% i 5) 0) "buzz"
(=== (% i 3) 0) "fizz"
i)))))
(console 'log (fuzzbuzz 10))
これが
var fizzbuzz = function(n){
return (function(a, b){
var __ary = [], __i;
for(__i=a; __i<=b; __i++){
__ary.push(i);
}
return __ary;
}(1, n)).map(function(i){
return (function(){
if(i%15===0){
return "fizzbuzz";
}else if(i%5===0){
return "buzz";
}else if(i%3===0){
return "fizz";
}else{
return i;
}
}());
});
};
console.log(fizzbuzz(10));
こうなる。おわかりいただけただろうか。
Lispを使うことの利点†
- Lispはその括弧の多さで嫌われるが、括弧があることによって「コードを手で操作」しやすい。
- Lispによる簡潔な記述でコード量が削減できる
- JavaScriptもLispを元に作られているので柔軟でなんでもできるが、無理に見た目を手続き型のC言語にしてしまったためコード量が増えがち。
- Lispの最大の利点「マクロ」が利用できる。
- マクロ使えるJSとか世間に非常に必要とされているのでこれ発表するだけでも反響はすごいはず。
Lispを使うことの欠点。†
- Lispの学習コスト。
- 解決策：実体はJavaScriptなのでJavaScriptの知識をそのまま使える。
- Lispの(関数名 引数)という独特の記述は慣れるまでは見にくい。
- 解決策：慣れれば生JavaScriptを読むよりもはるかに読みやすい
- Lispの「マクロ」には専門の知識が必要
- 解決策：excelの「マクロ」と一緒。使える人が使えばよい。
開発工程†
- 12月
- Pebbleの仕様決定：済
- parserの開発：開発中
- compilerの開発：開発中
- TouchUIの仕様決定
- REPLの開発
- 1月
今後の野望†
- ソーシャルコーディングシステム
- 関数を登録しシェアできるシステム。
- 「引数の型と返り値の型が一致する関数」あるいは「単体テスト形式でテストをパスする関数」を検索できるシステム。
- Ａさんは「これを入力したら、これを出力する関数」がほしくなった。
- 「これ作って！」とWebサービスにポスト。
- そのまま開発を続ける。
- すると、このアプリ使っている他の人にパズル形式で出題される。
- パズル好きで暇をもてあましているＢさんがサクっと実装。
- Ａさんのコードにはいつの間にかそのコードが実装されている。
- Idle状態の生体CPUに手伝ってもらえる！！！すげぇ！
- P2P通信
- 正確には「サーバーサイドプログラミングを必要としない」システム。
- 時代に逆行しているように見えるが、サーバー管理コストが浮く。
- 多画面多デバイス同時開発
- エディタ画面はこのノートPC、
- 実行画面はこのスマホ、
- マニュアル等のブラウジングはこのデスクトップPC
- デバッグ画面もこのデスクトップPC
- たくさんのデバイスの画面を最大限に活用する仕組み。
- 並列プログラミングの推奨
- 時代はメニーコア。
- データフロープログラミングはVPLに向いていて、
- さらに関数型に近いので並行性も高い。
- クラウドコンピューティング
- モバイル端末で重い処理が必要になったとき、通信速度が十分であれば
- クラウド上の超高速マシン、あるいは充電中の他端末に計算を代理する仕組み。
- 手続き型、オブジェクト指向、関数型、データフロー、
感想、要望等†
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
