『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
テーマは「まわりが天才だらけ」と扇情的なものだが、 実際には「他人が天才と呼ぶ人」と「普通の人」の違いを示している点が 重要なのだと思う。
僕はそれまで、「自分には才能がない」と思っていたんです。ずっと後で分かったことなんですけど、それは才能のあるなしではなくて、別のものだったんです。
僕には「引き出し」がなかったんですね。
「天才だ！」と僕が思った人たちは、入社する前からアニメや漫画が好きで、アニメに対する素養があったのに、僕にはそういう引き出しがなかった。引き出しもなくて努力もしないで、いきなり彼らと伍そうと思った。入社してすぐに「あいつらは才能がある、俺にはない」という仕分けをしちゃって。それは大きな間違いで。
才能ではなく、引き出しの違いというのに気がつくのに、ずいぶんかかりました。
才能や能力があるかではなく、どれだけ蓄積したものがあるか というのがもっとも重要な点だと思う。ある意味、「時間をどう使うか決める」、 「モノになるまで継続する」ことができることこそ「才能」ではないか、と思う。
自分の引き出しはどこにあるか、知らないで「天才」と勝負するのは無謀すぎる。
自分の引き出しは、彼らと違ったんですよ。逆に、引き出しの違いが勝負ポイントになると思ったんです。
僕が好きなのはノンフィクションとか時代劇。そんなところの材料というのは、アニメの人はあまり持って来ないんです。だから僕は、なるべく漫画好き、アニメ好きが触れないようなところから持ってくる。
−−勝負ポイントを、自分の強いところに持ってくる、ということですね。
そうすると競争相手が少ないから、楽じゃないですか（笑）。
Googleがオープンソースソフトウェアとして公開しているsparsehash。 新BSDライセンス。
ハッシュテーブルは要素に対するオーバーヘッドは馬鹿にならないものがあるのだが、 こちらは1エントリあたりわずか2ビットしか消費しないのだそうだ。
いったいどうやっているのか。これもソースコードを読みたいソフトウェアである。
先日のFactorからの指摘に対する反論。
shouldとmustの取り違え。しかし、
a future version (of Larceny) will offer at least one variable-width representation that still provides O(1) access.
とあるのはどうやって実現するんだろう。実に興味深い。 というか、できるものならRubyでも真似したい。
同意。
後方互換性。また、collationはUTS(Unicode Technical Standard)であり、 実装しなくてもUnicode互換性に問題ない。
同上
今日はGfarmの話を聞いたり、その他いろいろなことを学んだが、 例によって具体的なことは書けないので、箇条書き。
なんかこの件についての反応をいくつか見かけたのでここに追記しておく(実際に書いたのは9月)。
まず、ほとんどのソフトウェア開発者は製造業経験者の語る「もっと知った方がよい」という 言葉を何度も聞いたことがあると思う。が、それらは実際には役に立たないことが多い。
我々の作るものには物理的制約がないこと、 ソフトウェアは製造するものではなく設計するものであること、 などから彼ら(製造業経験者)の使うメタファーは間違ってる(よく言って不適切である)ことが多いからだ。
それは事実だ。
今回トヨタ流製造業発想を聞いていて、 私自身が同じことを何度も思った。
が、純粋なソフトウェア開発者であり、かつ製造業についてほとんど知識のない私が これらの話を聞いて「製造業のことを知った方がよい」と思ったのは、 その態度であり取り組みである。
彼らが、プロセスの改善のために継続的かつ組織的に払っている努力は 尊敬に値する。ハッカーは環境改善が好きだが、それは組織的なものではない。 多人数によるソフトウェア開発は(伝聞によると)かなり前時代的かつ改善が推奨されない 雰囲気のところが多いと聞く。
彼らが、「正当な製品」を出荷するために継続的かつ組織的に払っている努力は 尊敬に値する。ソフトウェアはなにが「正当」が決めることが困難という事情を 考慮してもなお彼らほどの努力をしているところは少数派だろう。
もっとも私はよく知らないんだけど「組み込み」領域は 製造業の一部であるため、すでにこれくらいの努力と取り組みは行われている のかもしれない。なんか苦労話しか耳にしないんだけど、 それは彼らにとっての当たり前は話題にならないと言うことなのかもしれず。
This work is licensed under a Creative Commons License.
variable-width O(1) accessについてはWillがr6rs-discussの別のメールで触れていたと思います。ストレートな方法は文字列をN文字ごとのチャンクに分けて、チャンクの先頭を指すベクタとして文字列を表現することですね。<br>実質的に同じことですが、マルチバイト表現に付随してN文字ごとの文字先頭へのインデックスのベクタを持たせる手もあります。さらにそのインデックスベクタをlazyに計算したとしてもamortized O(1)であると。<br>ただ、string-set!を許すと面倒なことになります。amortized O(1)には出来そうな気もしますが(例えば一定数の変更までは直接文字列を変更せずに差分を持っておいて、アクセス時にはインデックスを差分情報で調整、変更が閾値を越えたら文字列をアロケートしなおしてインデックス先構築、みたいな路線で)、そこまでするメリットはほとんど無いと私は思います。(なのでr6rs-discussでは文字列のimmutable化を強く主張したのですが…)
高橋氏は天才と同じ土俵に立っていた時点で十分に才能があったとはいえないでしょうか。その氏からすれば違いは「引き出し」のみであったと。<br><br>若者に夢を与えるのは良いことですが、青い鳥を探し続けるような人が増えては困ります。
まあ、プロ野球選手になりたい子供は日本中に何万人もいると思いますが、本当になれるのはほんの一握りですものね。たしか200人いないんだっけ。<br>とはいえ、IT分野ではその辺の差はもっと少なくて、ただ単にあきらめないだけで成功できる人は今の何倍もいると思います。<br><br>それはそれとして。「青い鳥を探し続ける」ことに対して、私はまだ結論を持っていません。音楽だって美術だって成功している人の何倍も「青い鳥を探し続ける人」がいるわけですよね。音楽にも美術にも情熱のない私にはなかなか理解しがたいのですが、そのような人たちの存在が背後に無ければ一握りの成功者もいなくなるような気がして、簡単に「増えては困ります」と断言するのに抵抗があります。
>若者に夢を与えるのは良いことですが、青い鳥を探し続けるような人が増えては困ります。<br>でひらめいたのですが、YARVの愛称は、'BlueBird'というのはいかがでしょうか?
＞「ものづくり」のレベルに達してない、製造業に学べ<br>これ言ってる人って、プログラミングをやったことないんだろうな。ソフトウエア開発は物作りじゃない、建築業界とは違うって何度言ったら解るのよと。
まあ、そう思うのは無理ないのですが、実は今回そう言ってるのは間違いなく根っからのプログラマである(と自称してる)私自身なのです。<br><br>夜の懇親会でトヨタ出身の武田さんと話してて、最初私も「製造業とは違う」と思ってたのですが、冷静に聞くと我々が軽視している原則をいくつも含んでいるよなあ、と思った次第です。<br>また、楽天でもっとも品質の高いソフトウェアを書いているのは製造業出身のプログラマであったりする点も印象的でした。
こんにちは、ソフトもそろそろ、匠が作る「工芸品」から「工業製品」になっていくのでしょうね！昔ながらのエンジニアの私には少しさびしいですけど．．．
ハードディスクは物理的にシークする以上、致命的に遅いんだよね。シアトルでのRuby Conferenceで来年作るといっていたdRuby+MySQLを使ったOpenPKSDバックエンドの分散データアクセス機構は、まさに「ひたすらキャッシュにのみしかアクセスしないため」のメカニズムで、動かすとむちゃくちゃ高速だった。５台ぐらいのクラスタで実験するとほぼリニアに性能があがった。アムダールの法則からくる性能限界は、はるか上のようだった。ただし障害からの復帰機能をきちんとインプリメントをするのが面倒だったのと、クラスタ化したハードウェアをいつまでも保守できないので、そのままお蔵入りになったけど。クラスタノードが障害をおこしてもうまい具合にコヒーレンスを保つようなメカニズムはさすがに簡単には思い付かなかったし。ところでdRubyはRubyに取ってRoR並に重要な存在だと思うのだけど、使いこなせるだけの人材がいないよね。残念。
> 「青い鳥を探し続ける」<br>世の中としても重要なことだと思いますけどね。<br><br>問題なのは、成功する可能性を上げるための努力をしていない／努力の仕方を教える機会が少ないことと、諦めたときに他の道が存在しないことですな。ゆとりを効率的に活用してない。<br><br>特に日本の場合、こんなに豊かなんだから、世間（or 国）もそれぐらいの投資をしてもいいんじゃない？とは思いますけどね
個人的には方向は逆(工業製品から工芸品)だと思います。<br>もっとも現代のソフトウェア開発の多くは製品レベルに到達してませんけどね。
ソフトウェア開発と製造業では、複雑さの桁が違う、それも1桁や2桁じゃないんだから、ああいうくだらない物言いは無視するべき
うまいぐあいに問題を分割できなければコストをいくらかけても複雑すぎて解けない問題であるという点ではソフトウェア開発も製造業もかわらないだろう。ソフトウェア開発が製造業より複雑だと言う人はそんなに自分の無能さを公言して嬉しいのかね。
↑そんな無意味な命題で同じ括りにするのは無理。物理化学の法則に強く支えられた工業と、大半のレイヤーが人為で作られた不確定要因だらけのソフトウェア開発はまったく違う。ソフトウェア開発固有の事情のためにそのまま流用できないノウハウがほとんど。
態度で(あ?)り取り組みである。
あ、脱字ですね。直しておきます。
同じ製造業ならトヨタよりも住友スリーエムの取り組みの方が<br>面白いのではないでしょうか？<br>http://www.mmm.co.jp/rd/reseach.html
ありがとうございます。イマイチ普通の人にリーチしないですね > dRuby。仕組みはいろいろ思いつくんですが、応用例が身近にないんです。ネタがあるひろのぶさんがうらやましい。
組み込み領域の品質の低さこそが製造業の他業種に対する無力さを良く表してると思う、<br>ちょっと使い込むと動きがおかしくなるルータや機能の貧弱なカーナビ、雑な画像変換の高級テレビ...<br>問題領域の切り分け方になにか学ぶものはあるかもしれない、<br>それでも今ではもう彼らからという必然性はない
組み込み領域の品質は低いと決めつけるのは、ただの馬鹿だ。<br>医療機器や重機の制御みたいな、バグが人を殺してしまう分野はいくらでもある。第一組み込みのプログラムの多くは、一度製品としてリリースしてしまうと修正が難しい。品質に対するプレッシャーは業務系以上だよ。