私みたいな教育寄りのハッカーがこんなことを言うのはなんなのですが……(なので、このエントリはツイッターにも流していません)。 PCを不特定な少数に配ってもハッカー教育にはなりません。ハッカーは育てるものではなく「元から中にハッカー因子を持っていて、それを使える環境がそろって初めてなる」ものだと思われるからです。ハッカー因子を持っていない人間はどんなに教育してもハッカーにはなりませんし、ハッカー因子を持っていてもたまたまそういう環境にいなければ一生まっとうな人生を歩んじゃうと思います。 なので、全国民をハッカーにすることは出来ませんし、環境だけ作ってもハッカーには届かない可能性が高いです。なぜかというと、ハッカーの方がユーザーより圧倒的に少ないからです。ハッカーの多くは非コミュですし(この相関の理由がよくわからない。別にコミュ力抜群のハッカーがいてもいいのに)、非コミュに「不特定な少数」宛の

「嫌い」じゃないです。「苦手」です。 機構としては素晴らしいと思いますし、CVTなんかもろ私のハートに直撃です。湿式多板クラッチでも、電磁粉体クラッチでも、単なるトルクコンバータでも、単板クラッチを摩擦ですりながら動かすよりはずっといいと思ってます。 ですが、普段エンジンのトルクカーブとアクセル開度の三次元グラフを頭に想定しながら踏み込んでいるので、たまにAT車に乗ると、頭の中の曲面とアクセル開度が微妙に合わなくて混乱します。というか、「ここはシフト下げてだなー」とか「いやいや、アイドリングトルクで走れるから」とか見えない電子制御に突っ込みを入れながら走る羽目に。 いや、理屈では判ってるんですよ。シフトパターンとトルクカーブが私の頭と実車で異なるから突っ込んでるだけだって。そのうえ、きっとATの車を日常的に乗るようになったら、突っ込む以前に体がそれに対応して思うとおりに動かせるようになるだ

ってのは、BEEP誌上でUPLの藤沢勉さんが言ったのがたぶん人目に触れる最初だったんじゃないかと推測します。1980年代中程かなぁ。BEEP復刻版捨てちゃったんだよね。もったいない。 現代のゲームに「○と×で表現してもおもしろい」を無邪気に適用するのはちょっとどうかと思いますが、「おもしろい」ということを定型化するための要素抽出が必要なのは昔も今も変ってないと思います。むしろ、グラフィックなどの表現方法の発達した今だからこそ、要素抽出を行っても劣化しないレベルの何かという形で抽象化する思考訓練は重要でしょう。 例をいくつか挙げると、個人的にはFF7以降のFFというゲームはあまり好きではありませんが、これは「ムービーが多いから好きではない」のではなくて、「ムービーの量とは無関係にゲームがへぼだから」ですね。同じ時期の「グランディア」はムービーがそこそこ入っていても全然へぼじゃなかったですし(

「ボタンを押してからインパクトまでは10frameでモーションをお願いします。これでも遅いぐらいです」 「せめて60frameはないとかっこわるいからいやです」 つべこべ言わずにゲーム側に合わせろー！　おめーのグラフィックが見たいんじゃねーんだよ！　10frameじゃないとゲームが破綻するからそう言ってるんだよ！　なんなら証拠見せようか！　ええ！？　ほら60frameでは全然ゲームにならないだろ？　それぐらいゲームの画面見たことあるんなら判るだろ。素人じゃあるまいし。 とは言わない8年前の大人な私。 もう人事権のない仕事はやりたくない。

通常、抽象的な思考を司る部位(連合野、というらしい)と、言語を司る部位(ブローカ野とウェルニッケ野)は脳内で分かれているそうですが、普段使わない外国語などを抽象的な思考を司る部位で処理していると思考に回せる処理リソースが足りなくなって馬鹿になるという現象が起こるらしいです。 私たちプログラマーにとってはプログラミング言語は手続き型だろうと関数型だろうと言語野で処理するもので(なので、「言語には音韻処理が必須」という仮説には懐疑的。Haskellなんか「ドル」とか脳内で発音してるとは思えない)、抽象的な思考には関与しません。が、何らかの理由で脳の処理リソースが極端に減ると言語を司る部位でもプログラムが出てこず、抽象的な思考を行うところでもかろうじてクラスの組成が出てくる程度でその実装までは出てこない、なんてことが起こります。 さすがにこの状態で納品用のプログラムなんか書けるわけが無く、ジェー

田中公平のブログ　My Quest for Beauty:創作者の皆さんへ(http://ameblo.jp/kenokun/entry-10561698619.html) 田中公平さんといえば私にとっては神様のような方で、軽々しく声をかけていいのやらって感じですが(インターネットの原住民でも、相手によってはそういうこと考えることもあるんですよ)、でも、どうしても書きたいので。しかし、アメブロってトラックバック受け付けてるのかな？　ま、いいや。 むかーし昔のその昔、私がまだ小説を書き始めて間がない頃、「インスピレーションこそが全て。そこから先は単なる作業」と思っていた時期がありました。同じ頃、「ひらめかないプログラムは作れない」とも思っていました。私にとって小説を書く作業と、プログラムを作る作業はほぼ同質で、訓練を積むことによって(何せ、1ヶ月で400字詰め原稿用紙300枚だの、マシン語の

「ソフトウェア工学なんてものはない」と言ったのはかのアラン・ケイですが、ソフトウェア開発はかなり文芸的で工学的に開発に対してきちんとした進行管理をするのは難しいです。 もちろん、完全なメソッド(この場合「やりかた」のこと。関数呼び出しルールじゃなくて)が決まっていて単純作業の組み合わせにまで落とし込むことが出来れば、のべ人日に分けることは出来ますが、そんなのはソフトウェアの「開発」ではなく単なる作業。思考の必要すらもいらない何かです。 そうではなく、目的があってそれを実現する情報科学的な裏付けがあって、でもまだ「実現されていない」ものを作ることが開発であり、高度な創造性が要求される専門職です。 昔、J.P.ホーガンが「創世記機械」を書いたときに作内の人物に「軍人の奴らは発明までスケジュールに組み入れやがる。発明というのはひらめいた瞬間に生まれるもので予定して発明することなどないのに！」と語

現代のディジタルコンピュータは基本的にシャノンの情報理論と、アラン・チューリングの有限状態機械の実装(チューリングマシンと互換性がある:チューリング完全)で動いています。 が、チューリング完全を実装するためにはなにもチューリングマシンに似た実装である必要はありません。たとえば、人間の脳は逐次実行を行っていませんがチューリング完全と言えます。非常に効率は悪いですが。 ということは、ある程度の複雑さを持っていれば人間の脳と同じような方法論(ノード間の接続強度の動的学習)でチューリング完全を実現することは、論理的には不可能ではない、とかんがえられます。 さて、ここで、「セルオートマトン」という考え方を導入します。ドイツコンピュータの父、コンラート・ツーゼは宇宙全体を無限小のグリッドと見なし、その「場」を値と見なした三次元のセルオートマトンと見なすと物理法則すべてをシミュレーションできるという仮説

まんじゅう怖い。ここらでちょっと、茶が怖い＜はい、ここ笑うところ ＃古典落語はネタは知っていても落ちを知っている人は少ないんだよなー。「あたまやま」とか「時そば」とか。何かわけのわかんないグルーブに引きずられているうちに、かなりしょうもない落ちでスパンと落ちるのが落語の楽しさです。 閑話休題。 例えばコンピュータにおいて、「学問」の領域はとんでもない勢いで増えています。別にコンピュータじゃなくてもいいんだけど、例えば「材料工学」なんてのにおいてはまずは基礎となる物理と化学と高分子化学の話をやっつけてからじゃないとスタートラインに立てないとか道筋がだいぶありますが、コンピュータの場合新しい技術やその基礎理論がものすごい勢いで増えている(その上、「最先端が最良」であるということが多い)ので、勢い「目的があって、それを実現するのに必要な技術を見つけ、それを学習する」という方法論がよく取られます。

JavaVM自体は、良くできています。好きです。AOTアセンブラやバイトコードVMとオブジェクトエンジンを作ったり、Javaバイトコードをはき出すオレオレコンパイラを作るくらいには好きです。 けど、全体的に16bitの呪縛(methodやinterfaceに16bit決めうちのところが結構ある)や32bitの呪縛(実はJavaのポインタやフィールドは32bit。doubleやlongを使うときには「特例扱い」しなくちゃならない)が大きくて、不定長命令のくせに32bitアラインしなくちゃならない命令があったり(lookupswitchとtableswitch)、巨大なJavaのプログラムというのは動かしづらかったりします。 もちろん、Javaもコンポーネント同士がプロセス間通信でやりとりをするという前提があるのであれば、VMインスタンスを複数持つことで巨大なJavaのプログラムを作ることはで

魔法学校の先生をやってもう10年にもなりますが、毎年自己紹介がてら新弟子に「心のゲーム」を聞くことが恒例行事になっています。 で、今30歳前後の人たちに、彼らが18歳位の時に「心のゲームは？」と聞いたときに圧倒的な得票数でトップに輝いたのが「ファイナルファンタジー3」でした。 もちろん、彼らが感受性豊かな時期にインパクトあるものを見たらそれが印象に残るのは当然ですので、平均年齢と「いつそれに触れたのか」によって傾向が大幅に変わるのは当然としても、「ファイナルファンタジー3」のインパクトは結構なものがありますね。 「ファイナルファンタジー」のシリーズで初期3作はシナリオに寺田憲史、プログラムにナーシャ・ジベリという当時から見てもすごいスタッフが気合いを入れて作っていたのが見て取れる作品でした。「あのナーシャ・ジベリがファミコンのソフト作ってるよ！｣と大変興奮したものです(Apple IIの数

背景などのデータは「頂点情報と色情報をストリーミング」して、CPUでレンダリングしています。リアルタイムに座標変換しているものもこれまたやっぱりCPUでレンダリングしてるので「戦艦の一部が壊れる」とかやっててかっこいいです。でも、よく見ると背景とゲーム本編のフレームレート違うのね。等倍速CD-ROMの限界だったんだろうな。 同じくメガCDのスターブレードは「頂点情報と色情報をストリーミング」して、CPUでレンダリングしています。ただし、リアルタイムに座標変換しているものはワイヤーフレームで表示されていました。 PS1のスターブレードは「背景はムービーのストリーミング」で、リアルタイムに座標変換しているものはポリゴンで描画していました。なんというか、大変操作性の悪いゲームで、何度パッドを投げたくなったことやら。 アーケード版のGalaxian3のうち、花博バージョンは背景をリアルタイムにレン

PC-6001(1981年)Z80+独自CRTC+AY-3-8910 カセットビジョン(1981年)CPU組み込みカートリッジ+独自CRTC FM-8(1981年)6809x2+独自CRTC ZX-81(1981年)Z80+独自CRTC+AY-3-8910 PASOPIA(1981年)Z80+独自CRTC Commodore Max Machine(1982年)6510+独自CRTC←なんと、C64よりも早い！ Commodore 64(1982年)6510+独自CRTC SORD M5(1982年)Z80+TMS9918+SN76489 ぴゅう太(1982年)TMS9995+TMS9918+SN76489(らしい) ファミリーコンピュータ(1983年)6502(互換)+独自CRTC SC-1000/3000(1983年)Z80+TMS9918+SN76489 PASOPIA7(1983年

元ネタは各自検索のこと(えー)。 かなり暴論におちつきます。 ことプログラムを実際にコーディングする作業において、抽象度を上げることがデメリットを持つことはあり得ないとする立場に立って話を進めます。可能な限り抽象度は高いに超したことはないと思います。 まずは抽象度が高い方がいい理由を。人間の思考能力には限界があります。複雑な事柄を複雑なまますべて理解することはできません。 このため、複雑なプロジェクトにおいては物事をすべて俯瞰した状態という観点をどこかに作る必要があります。このために使われる技術を総称してここでは「抽象化」と呼んでいます。この観点を前提にすると、抽象化を止める理由は基本的にはなくなります。プロジェクトは進むごとに複雑さを増していきますので、可能な限り抽象化を進めていかないと理解できなくなる瞬間が(つまり、作れなくなる瞬間が)くることが判ります。 ここで問題となるのは、スキル

CHIPTUNEが最強であることに関しては論を待ちませんが、記号化に関してはCHIPTUNEとテクノと現代音楽の中に横たわる一つの発想があります。 それは、「音楽を構成する要素は楽器に規定されないのではないか」という疑念です。 現存している楽器はどれも長い年月を経てソフィスケートされた物ばかりです。 そりゃ、今だって常に新しい楽器は生まれ続けています。KaossilatorやDS-10なんかはなかなかいい発想ですし、アナログ楽器だって、山口トモや鋸演奏なんて物だってあります。 でも、長く現存する楽器には、長く残る羽目になった理由がきっと内側に隠れているはずです。ピアノの音にはあの倍音構成に理由があり、スネアドラムのアタックのノイズにはやっぱり何らかの理由があるはずだろうと。 現代音楽はかなり意図してこの辺の理由を探ってきました。もちろんクラシックもずっと探ってきましたし、ポップミュージック

id:minekoaさんの以下のエントリーを読んでつらつらと。 [C++] 漢の言語(http://d.hatena.ne.jp/minekoa/20080310/1205146973) 一時期、何でもかんでも巨大なライブラリアーカイブ(.a,.lib)に放り込むというコーディングスタイルを持っていた時期がありました。 結構いろんなメリットがあって、 ライブラリ自体が巨大でも、ライブラリ内のモジュール依存性が低いと実際にリンクされるのは一つだけ。 C言語はエントリーポイントを一つしか持てないので、ユニットテストがやりづらいのを切り分けられる(本番時もmain関数のみのソースをリンクするのみ) コンパイルの時間が省略される まぁ、生でC言語を触ることが極端に減ったのでこの辺の好みは今となってはあまり生かされていないのですが、他にもこんな方針を同時に立てていました。 関数は１画面以内。それも、

我々は１１年待った！ ……と、行きつけのお店にポップがありました。あそこの店員さんたち（絶対一人じゃないよ、あの怒濤のポップ）ノリノリで書いてるよ(^^;)。よもや展示台で平積みされてるとは思わず、店中を探し回っちゃいました。 おもしろいです。やっぱりこれは、リモコンでやるべきゲームですね。操作に気づくまでは全然思った方向に行けませんでしたが、ヌンチャク、クラシックコントローラなど一通り試した後、リモコンに戻ってくるとえらいしっくりきます。 まぁ、もっとも、ヌンチャクやクラシックコントローラでやりづらいのは、任天堂独特の3Dスティック根本の八角形の所為ですが。ほかのゲームはともかく、ことNightsに関してのみはマルコンのアナログキーの方が圧倒的にしっくりきます。 音楽は相変わらず。ササキトモコさんの例のモチーフがこれでもかというほど使われています。面のBGMも相変わらずでいい感じ。当時、

昔、RNAを記憶媒体として使うというアイディアを初めて聞いたとき、こんなネタを考えました。 RNA同士の遺伝子交換は、論理式の演算子と見なすことができる RNA自体が、記憶装置として振る舞う RNAはが演算をするタイミング（確率）は、RNAの入っている槽の流速とRNAの濃度に依存する これらから、 情報を持つRNAを洗濯機みたいな攪拌槽に入れる RNA同士が勝手に反応 一定時間後に、クロマトグラフィーなどでRNAの組成とその分布を調べる ということで計算を行うことができるのでは？なんてな事を考えました。 これ、確実な一つの答えを求めるには向いていません。でも、全体としての傾向や、何かのトリガーによって引き起こされるカオティックな振る舞いなどをうまーくサンプリングできる計算機になるんじゃないかな、と考えました。 当時はカオスと思考の兼ね合いについてペンローズの「王様の新しい心」などのオカルト

Javaが好きです。C#とCLRも好きですし、Smalltalkなんかも大好きです。最近ではECMAScriptとFlash環境を好んで使っています。 その上、ここのところ、ネイティブで直接マシン語に落ちるプログラムをほとんど書いていません。あえていうなら授業の素材かな。これだって、「いかに高レベルな書き方で動かすか」というネタなので、出来上がったものはネイティブとは離れていきます。 そりゃもちろん、 Florian はその筋を長いことやっている職業プログラマーですんで、低レベルなところや、泥くさいチューニングも得意です。 バイトコードVM上で動くプログラムを高級言語で組んでいても、とっさにVM上のバイトコードに落ちているところを想像したりします。さらには、VMがどうやってJITをかけているのか、オブジェクトエンジンのメッセージパッシングやキャッシュ、GCなどのタイミングもある程度読めます

static local variableのstaticは｢静的メモリ領域におかれた｣という意味です。 C言語においてはブロックの内側で定義されたlocal variableはブロックスコープを外れたときに適宜破棄されるという仕様がありますが、多くはこれをスタックフレームやレジスタで実装しています。 これを何らかの理由でスタックフレームやレジスタにとってほしくないときにstatic修飾子を使います。静的メモリ領域は、大域変数などと同様に、ローダがスタートアップ時にメモリを確保し、エントリポイントに入る前にのみランタイムが初期化を行います。この初期化のタイミングのために、｢ブロックを抜けても値が保持され続ける｣という副作用が起こります。 ｢何らかの理由｣としては 変数をたくさんスタックフレームにとることによって、インデックス相対参照できなくなってはまる 巨大な配列を取ってそもそもスタックがあ