XtextによるAsakusaFW独自DSL実験

独自DSLのエディターを作るのにXtextがあまりに便利なので、ふと思い立ってAsakusa FrameworkのBatch DSL・Flow DSLの独自言語を作ってみた。

DSLの定義とハイライト（色付け）・アウトラインの表示・基本的なソース整形まで、1日で出来た(笑)
Batch DSLの方は、バッチクラス（本来のJavaのBatch DSL）を生成するところまでやってみた。

DSLの見た目はとりあえず問題なさそうだけど、入力補完が出来ないと、やはり便利ではない。
Batch DSLの場合はJobクラス（Flow DSL）自体を補完する必要があるし、Flow DSLはオペレータークラスやメソッドを補完する必要がある。
JobクラスやOperatorクラスを探す部分を作るのは大変そう。

それと、（忘れてたけど）オペレーターは色々な種類の引数を定義できるんだよね。
これをDSL上で表現するのも面倒（やり方は分かっているので、本当に面倒なだけ）＾＾；

という訳でかなり簡単に独自のAsakusa DSLは実現できそうだけど、実用性はよく分からないので、とりあえずここまで。

---

本家のAsakusa DSLは、Javaをホスト言語とする内部DSLとなっている。
オペレーターをJavaで書くので、それを呼び出すFlow DSLもJavaで作ると、Javaのエディターの機能（クラスやメソッドの入力補完）がそのまま使える。
やはり内部DSLにもメリットがある。

『アルゴリズムを学ぼう』

『アルゴリズムを学ぼう』『続・アルゴリズムを学ぼう』川中真耶、杵渕朋彦、椎名俊輔
（著者に知り合いがいるのに今頃買ったなんて、口が裂けても言えない＾＾；）

噂どおり、ゆるふわなイラストで油断させたガチの内容(笑)
基礎的な内容から探索・ソート・暗号・シミュレーション・AIなど、いろいろなアルゴリズムに触れている。

特に一番最初のデータ構造と計算量は、大学の情報工学科でも出てくる本当に基本的な話なので、仕事でプログラミングをする人は押さえておいた方がいい。
少なくともデータ構造に関しては、オブジェクト指向厨だろうが関数型モヒカンだろうがstaticおじさんだろうが、絶対把握しておくべき。
とか言いながら、「ヒープ」がデータ構造の一種だって、初めて知ったんだが(爆)

JavaのTreeMapが赤黒木だったのも知らんかった。
NP完全とかP=NP問題とかも言葉は聞いたことあったけど、そういう内容だとは知らんかった。
暗号の概念の話とか面白いね。公開鍵暗号の解説は世の中に多いけど、DESの暗号化の方法（アルゴリズム）の説明は初めて見たｗ
逆行列の計算とか、なんか昔習ったような気がする。
文字列の探索（マッチング）もKMP法は習った覚えがある（名称は忘れ去っていたが）。
オートマトンも習った、懐かしい。
山登り法も聞いた覚えがある。

というように、情報工学科の人間が習っている内容なので、プログラミングをやっていてそういう基礎を知らない人は、興味があるならこの本は向いているかも。 

ただし、アルゴリズムの個々の内容については解説は色々されているものの、数学に挫折した自分には、最後の「ゆえに○○である」の部分がなんでそうなのか理解できなかった（飛躍しているように感じた）ので、本当に理解したければ他に専門書を勉強すべきなんだろうなぁ。

最後に気になる点をひとつ。
レッドブルを温めて飲んだらどうなるか、著者らは試したのだろうか？(笑)

---

（2013/09/10追記）
この本のストーリーは、アルゴリズムの解説という意味では不要かもしれないけど、面白かったよ(笑) 1冊進む度に1年経過しているということは、4年生・大学院で、あと4冊くらいは余裕だよね？
という訳で、 トランザクションとか分散処理とかのアルゴリズム解説を期待(爆)

コメント不要論の補足

コメント不要論の部分、言葉足らずでまとまりを欠いている気がするので、ちょっと補足しておきたい。
言いたいことをまともに書こうとするとコメント関連だけでまた1ページ行っちゃいそうなので、とりあえず覚え書きということで＾＾；
以下、主にJavaがターゲット。

1. コメントが全て全く要らないというわけではない。“適切な”コメントを書くべきだ、という事に異存は無い。
2. 適切な変数名やクラス名・メソッド名を付けるのが大変なのと同様、適切なコメントを書くのは大変。けっこう労力（時間）がかかる。
3. コメントを書くのは、プログラムをコーディングする能力とは別で、日本語の文章を簡潔に書く能力が必要。
4. メソッド本体が1行しか無いようなメソッドでもJavadocコメントが数行になったりする事もある。実装を見ればすぐ分かる場合でも説明文章を苦労して書くのは馬鹿らしい気がする。
5. Javaの文法は知っててもJavadocの文法を知らない人が居る。JavadocのHTMLを生成したことのない人はもっと多いと思う。（生成してみるとけっこう感激するよｗ）
   でも共通ライブラリー・ユーティリティーやフレームワークならブラウザーでJavadocが見られると便利かもしれないが、業務プログラム本体がそういう状態になっても、きっと見ない。
6. プログラム本体の1ステップ毎に何をしているか書くようなコメントは冗長・無駄。
7. コメントもソースレビューの対象になるはず。（コメントが増えればレビューの時間も相応に増えるはず）
8. にもかかわらず、工数見積もりでステップ数とやらを根拠にする場合、「コメントを除いた実ステップ数」とかいうのを使うことが多い。つまり工数にコメントを書く分が含まれないと思われる。にもかかわらずコーディング規約で「全メソッドにコメントを書け」とか…。

コメントを付ける位置にも色々あって、ファイルヘッダーやクラスのJavadoc、フィールド・メソッドのJavadoc、メソッドの中身に書くコメント。
必要度が違うだろうから、ひとまとめにして要/不要を言えるわけもなく。

それから、コメントの目的。
「何をしているか」ではなく「何を意図しているか」「何故そうしているか」あるいは分かりづらい注意点・考慮点を書くべき。

ログ出力があるなら、それがコメント代わりにもなる事もある。

冗長なコメントの例…例えば「getDate() //日付取得」というコメントは、特に要らないでしょ。
そして「getPerson() //日付取得」とか「setDate() //日付取得」とか書かれていたら、正気を疑うぜｗ（メソッド名とコメントの相違は混乱の元）
（そういえば、コメントの内容が間違っててもコンパイルエラーは出せないね）

つまり、プログラミング言語も「言語」だから、何の処理をしているかという事実については、コメントで書かなくても伝えられるはず、という話。
ただ、そういう「文章っぽくなる」のを意図している言語がCOBOL(爆)
なので、英文でなく数学の記号（式）を使った方が簡潔で分かりやすいでしょ（代入を「a=1」と書くのと「MOVE 1 TO a」と書くのとどっちが簡潔か）とか、
でも理論の記号よりも利便性を優先したい（代入に「:=」でなく「=」を使いたい）とか、
コメントから派生して色々な話題が出てきちゃう(苦笑)

ああ、ソースの変更履歴をコメントに残しておくって話もあるなぁ(苦笑)
バージョン管理システム使えよってことで大筋同意だけど。
でも削除した場合って、履歴を探さなければ「昔は有ったという事に気付けない」というジレンマもあるんだよねー。

なので、よほど気力が出ないとやっぱりコメント全般についてまとめる事は出来ない…orz

手続き型vsオブジェクト指向vs関数型

数日前に「関数型言語が普及しない理由」というのが話題になってたみたいで、どこかに「オブジェクト指向は分かりやすい」ってな言及があって面白いと思ったｗ
それが本気か釣りかジョークかネタか分からないけど、なにせオブジェクト指向が流行り始めた頃は「オブジェクト指向分からん」って声が多かったので。

んで、一番分かりやすいのはやっぱ手続き型だよね、と思ったので自分が知っているプログラミング言語（パラダイム）の変遷についてちょっと書いてみた。

というか、ちょっとのつもりが意外と長くなってしまったので結論だけ別途書いておくと、
Scala最強(爆)

M.T.GODDESSとMSXエミュレーター改造の話

昔作ったものを思い出していたら懐かしくなったので、ちょっとフォローしておくｗ

M.T.GODDESSはMSX-FANに載っていたゲームで、戦闘シーンがハイドライドやボコスカウォーズのように体当たりで戦うアクションになっている。敵味方はお互い複数居るが、操作できるのは自分のキャラ1人で、味方もコンピューターが動かす。
このうち味方2人分をプレイヤーがジョイスティックで操作できるように改造した。（要するに3人で協力して戦えるようにした）

戦闘シーンはマシン語で書かれている（BASICのDATA文で数値だけ書かれていたはず）ので、手で逆アセンブルして、ジョイスティックで操作できるように書き換え、ハンドアセンブルし直した。
こういった改造をしたのに、マシン語部分のバイト数が改造前と一切変わらなかった！
我ながら感動して、今でも覚えているのだｗ

---

MSXエミュレーターは今ではMSX MAGAZINE永久保存版が定番だと思うが、当時はfMSXをいじっていた。
当時のマシンスペックのこともあって実行速度が遅かったので、なんとかしたいと思った。

採ろうとしたアプローチは、対象プログラムをホストマシン上のプログラムに変換してコンパイルして実行するというもの。
プログラムはZ80のマシン語なので、逆アセンブルしてC言語に変換し、コンパイルしてfMSXとリンクするという発想。（fMSX自体がC言語で書かれているので）

しかしマシン語（Z80）というものはプログラム部とデータ部がきっちり分かれている訳ではないので、どこがプログラムとして実行されるかを全て追うのは困難。
また、マシン語ではプログラムの自己書き換えが出来るので、コンパイルするならその部分を判別してエミュレートする必要がある。
ROMのプログラムならそういうことは無さそうに思えるが、メガロムの場合はページ毎にアクセスできる場所を切り替える仕組みになっており、その実現方法はROMによってまちまち。あるROMでは特定アドレスに書き込むとページが切り替わるようになっている（ROMはread onlyなのに、そこへ書き込む！）が、汎用的な決まりなど無い。

大体のところは、メモリーにアクセスする時に直接読み書きするのでなくfMSXのアクセスルーチンを使うようにすれば解決すると思うが、それだとスピード面で全然改善にならない(苦笑)

という訳で、立ち消えになった。

---

MSXエミュレーターのことはさて置き、MSXでプログラムを勉強するというのは、環境面でも非常に良かったと思う。

フロッピーディスクも普及してなかった頃なので、プログラムは雑誌の紙面に載っているものを全て手打ち(笑)
何かエラーが出たら、基本的には自分が何か打ち間違えているということなので、デバッグの勉強になる。
ソースも全部見られるし全部入力するので、何をやっているのか・どういう書き方をするのか・何が定石なのかという勉強になるし、気になる部分の改造も出来る。

当然の様に、雑誌には初心者プログラマーへの解説もあった。
インターネットなんか無い時代であり、雑誌自体も種類が限られているので、MSXでプログラムを作る人はほぼ全員同じ知識を共有できていたと思う。
（たぶんMSXでプログラムを作っていた人なら、ビット演算のXORなんて常識だと思うｗ）

今の時代、「インターネットで情報は何でも手に入る」とか云うけれど、個別の事はともかく、全員が共有できる知識なんてものはウェブ上には無いんじゃないか。

もうちょっと言うと、自分はMSX-BASIC→Z80アセンブラ→C言語→VC++→Java→Scalaと勉強してきた。
技術要素的には、BASICで基礎を覚え、アセンブラでメモリーアクセスを覚え、C言語で構造体を覚え（ポインターはアセンブラをやってれば難しくない）、VC++でクラスとイベントドリブンを覚え、Javaでオブジェクト指向を覚え、Scalaで関数型の考え方を勉強中という感じになる。
つまり新しい言語を勉強すると言っても、今まで覚えてきたことに新しい要素を追加するだけという感じ。

ところがこれを今の人がJavaやScalaから入るとなると、覚えることが多くて、そりゃ大変だろうなぁと思う。
（MSX-BASICなら、パソコンの電源を入れたらBASICの画面になるので、PRINT "hello"って書けばもうプログラミング完了だよ。インストールもコンパイルもツールの起動も何も要らない。初心者にとってどれほど楽かｗ）
まぁ逆に今の時代は入門書もいっぱい出ているから、なんとかなるのかもしれないけど。（どの入門書が良いのか探すのも一苦労かもしれないけど＾＾；）