考えてみるとインタプリタを作り始めたのが去年の6月の頭だったと記憶しているので、もうすぐ1年になる事になる.

去年延々グダグダ言っていたクラス機能はどうにも型なしのスクリプト言語としてはクラス自体が型であり、事前設計的である事から「硬い」印象がぬぐえず、試験実装のみで実際には使っていない.

現状使っているバージョンではオブジェクトのようなインテリジェントなデータ構造が必要であれば構造体スロットにクロージャを入れる形になっている、こんな↓具合.

function Stack(){
    data=[];
    closure push(n){
        push(data,n);
    }
    closure pop(){
        if(empty()) error("Stack is empty");
        pop(data);
    }
    closure empty(){
        len(data)<=0;
    }
    this=struct(push=&push, pop=&pop, empty=&empty);
}

/*---------------------------*/
st=Stack();
st.push(10);
st.push(2);

while(!st.empty())  print(st.pop());

型無し言語としてはこういう方がいい加減な気がして良い気がしていたり、型が無い時点で全てはObjectであるし、呼び出しは引数の数のみの制約なので多態も呼び出しシグネチャだけ一致してれば良い、結合メソッドをイベントにバインドする場合にもクロージャなのでそのまま結合メソッドとして扱える.

無論プログラミングの方法論として型制約なし>型制約ありというつもりは無く、型制約なしの方が楽に書き始められる&初期効率は良いものの、正直1000行を越える辺りからは型制約ありの方が効率的であろう、ただ上記スクリプトはよくある書き捨てのプログラム向けなので問題なし.

---------------

と、ここまでやってきてよくある言語論的な優劣について、結局の所言語は所詮言語でしかない、との結論に行き着く. ただどんな言語でも同じだという結論でも無く、言語における開発効率や思考の優劣はあれど、それは個々のプログラマのセンスを越えるものでは無いという所、凡人がいくら優れた言語を使っても優秀なプログラマが凡庸な言語を使った結果を超える事はまず無い. ただ同じ人間が使うのであれば言語はその機能に優劣が発生する、というしごく当たり前の結論(笑)(※1)

結局の所言語論争ってのは潜在意識的な所でエンジニア的優越感の確認の為に他を攻撃する的な側面もあるのだよなぁなどと思ってみたり.(よくある問題のすり替えってヤツ :-P

という事で無能プログラマの僕が道具に頼って何とか底上げを図ろうとする望みは脆くも崩れたのでありました(笑)

まぁでも自分用の言語を作る事でこれまでPerlとかにやらせてた処理を肩代わりできた & 幾何的な計算などのプロトタイプ作成の効率は上がっているので悪くはないカンジ もう変数の$マーク付け忘れエラーで頭に来る事も、ブロックをコメントアウトしようとして#if 0が無くてブチ切れる事も無い(笑) 弊害としては最近C++で書くのが少々面倒になってきた事 (得にクロージャと多値代入が無いのが、、、※2) とゆー事で機会があれば結構お勧め、自分で仕様を決めるだけあって実に快適だし(※3)＞自分用言語の作成(って誰に言っているのだか.

※1) 特化DSLやフレームワークライブラリによるDSL化などの効率化の影響は除く、これらは言語デザインに直接影響するものでは無いし(※4) プログラム全体の構造設計という観点ではそういったフレームワークの間に書き込むイベントコード、あるいはダイアログベースのアプリのコード程度はある意味どうでも良いものでもある為、ただフレームワークも複数使用する場合の管理コストを考えるとトレードオフポイントの臨界点が近いのではないかなぁなどと最近のエンプラ界隈を見ていて思う部分もあるけど.

※2) 実際にはC++のようなリソース管理が厳密であるものでクロージャのような構造が曖昧になりがちなものを扱うのは危険なので、GC言語でないときついとは思うけど ;-)

※3) 実際この前の仕事でも検証用として役に立った、3Dボードの計算検証用にZバッファレンダラを実装して、、、ってまー余りそういう事もないか、ついでに仕事自体はポシャったし(苦笑)

※4) とは言っても擬似DSL化した時に何処まで抽象階層を含められるかという所は言語のポテンシャルとも言える、オブジェクト指向によるデータ抽象もその手段と言えるし演算子のオーバーロードやLispのマクロなども然り、また簡易言語を作るというアプローチそのもの(最近はJava周辺が妙に元気な気がするが)やXMLによる設定の分離なども含まれるとも言える、無論これらを複数組み合わせる場合利便性のトレードオフポイントが逆転する可能性もある.

---------------

暖かくなってきたのかゴキブリを家の中で発見、マンション敷地内でも死骸を見かけたり、毎年恒例という事でホウ酸団子を買ってきて家中にバラまく、これをやっておくと取り合えず１年間はゴキブリをまず見ないのでお勧め.

Bezier曲線の均等分割 (図はおよそ5pixel距離での分割) まぁ、後はこの形でリサンプルされた形状格子にポリゴンを描画するワケでございます、連結がある場合は連結曲線全体で1となるようリサンプルする.

なおBezier曲線の式のt微分は-3*(p[0]*(t**2-2*t+1)-p[1]*(3*t**2-4*t+1)+t*(p[2]*(3*t-2)-p[3]*t))という具合.

まぁ余興というだけですが.(Webだけ見ててもはなはだ意味不明で失礼)

民間刑務所で Ruby によるソフトウェア開発者を養成、アウトソーシング業務を

だそうな.

まだ限定的らしいが、これが刑務所での他の作業と同じレベルで定着したら、仕事が無くなったら軽犯罪でも犯して刑務所に入っても良いかもしれぬ(ヲイ

実際刑務所内での仕事であれば流石に物理的に困難なものを1週間で仕上げるみたいな話は無さそうだし、バグやら何やらの対応も作業時間の割り当てでやれば良く徹夜などあるまいし、後出しの仕様変更など理不尽な要求なども別作業として割り当てられよう. 何より寝ている所から10分も歩かずに職場がある為通勤などの無駄なストレスはあるまい、無論終電なども然り.

、、、真面目にどっちが良いのか分からん気がしてきた(笑、いやマジで)

まぁ今の状態はほぼ遊んで暮らしているようなモノなので比べるべくも無いが、真面目に人生行き詰まったら就職か刑務所かを考えてみるのも悪くないかもしれないかも？(コラコラ

# 以前刑務所のドキュメンタリーでリピーターがいるという話があったけど、こういう心境なのかもなぁ(苦笑)

# 問題はソフトウェアのような定量的に評価できないものが、果たして刑務所内での作業のようなものとして成立するのかどうかやね (実際自分の場合作業時間の8割はぼけーっと考えてる時間でコーディングに要するのは微々たるモノだが、この8割が実は設計の上では非常に重要) この部分は真面目に興味があるので動き出したらドキュメンタリーかなんかで見てみたい気がする、真面目な話で言うと「上の記事の条件で」開発ってのはほぼ頓挫すると思っているのだけど ;-)

# でも携帯やカーナビ開発の現場とか言われたら冗談抜きで刑務所と迷うかも.

---------------

(2007/5/3追記)

どうも上の話には前振りがあったらしい

プログラマーの方に質問です。 受刑者にプログラミング言語を覚えさせるとしたらどの言語が最適だと思いますか？

、、、駄目だな、こりゃ.

しかも現時点で講師募集してる辺りどうもネタっぽい気がしてならない.

まぁ、真面目な話、就職訓練って所であればCとJavaの言語仕様を完全に叩き込んでC++をBetterCとして使える程度まで覚えさせて、SQLを叩けてApacheの設定程度できるようにしてHTTPプロトコルの勉強させてPerlでCGI組めて(言語としてのPerlは真剣に学ぶ必要は無いけど)、HTMLとJavaScriptを必要に応じて書けるようにして、簡単なWindowsアプリ(ダイアログベース)をAPIなりで書ける程度にして、アルゴリズムの入門書レベル(リストとかツリーとかソートの概略だけ書いてあるようなヤツ)を一通り舐めさせて位がスタートラインではなかろうかって気もするが、、、

実際にはJavaの場合は言語仕様を覚える事に余り意味は無く周辺のミドルウェア・フレームワークとの組み合わせでのシステム全体の構成の話の方が重要なのでちょっと上の表現も適切では無いし、クライアント開発として昔ならVBも入れたろうけど最近の状況は少々微妙かつ代替となるものが無いのだが、、、SwingでGUIは余りにネタ過ぎるし.NETフレームワークでGUIも多少大掛かりになる、うーむ (かといってC/C++でダイアログベースだけ作っても余り話にならんのだが、、、)