  |
はてなキーワード: オーバーヘッドとは
相手が勝ち誇ったとき、そいつはすでに敗北している
何が違うのか解った気がする（菊池 Blog）
今どき言語論争なんて愉快なことをやってるのがアンテナに引っかかったのでヲチしてたんだけども、勝利宣言キタコレ。
さて。
ネットバトル(藁)の勝敗は傍観者の評価によって定まるとしても、「傍観者の評価」は俺一人の評価と同値ではなく、むしろ多数が形成する「空気」だから、俺が「このバトルは◯◯の勝ちだ」と宣言したところで月桂冠には成り得ないわけだけども、「空気」の一要素として、高らかに宣言しておく。
このバトルは菊池氏の負けだ。
菊池氏の主張というのは結局、「日頃から良い設計でコードを書いていればコードの再利用も容易なはずだ」という「Javaプログラマかくあるべし」論だ。
だから菊池氏は自分の勝利を確信しているだろう。「低能プログラマを叩きのめしたぜ万歳！」
ところが、このネットバトルの勝利条件は「どちらが優れたプログラマか」では無い。もともと他言語との比較でJavaのメリットが問われているから、Javaプログラマを叩きのめしても意味がない。
そこで「優れた設計に基づく既存のコードを簡単に再利用できるのがJavaのメリットだ」と答えても、「その優れた設計に基づく既存のコードというのはどこにあるんですか？」と訊かれる。（ここでの「優れた設計」は、RDBMSがbigtableになりGAEのSandBoxの縛りがあっても容易に移植できる設計でなければならない。）
さて、この問いに胸を張って「いくらでもある」と答えられるJavaプログラマがどれほどいるのだろうか？百歩譲って自身が優れた設計に基づくコードしか書いてこなかったとして、Java界全体を代表して発言してもなお結論が変わらないと言えるだろうか？
つまり、他言語使いに問われた時に「俺の書いたものに限らず、Javaの既存コードはたいてい再利用できる」と言えるだろうか？
答えは否だ。嘆かわしかろうが何だろうが、否だ。
さて、このネットバトルの勝利条件は何であろうか。
それは、「GAEでJavaを使うメリットをより的確に表現する事」だ。
id:higayasuo氏の答えは大要「慣れた言語で書ける事」だ。格好良くはないが、現実的な答えだ。
菊池氏の答えが全く説得力がない以上、id:higayasuo氏の答えの説得力が弱く反論が容易であったとしても、1ピコグラムでも説得力を有する以上は、天秤はid:higayasuo氏に傾くのだ。
これは、JavaとPythonの勝敗とは関係のない世界の話。
このスレッドなご時勢に、新しいウィンドウを開くのに新しいプロセスがいるって前提がそもそもなんだかなぁ、と。スレッド関係ないけど。
ウィンドウ作ること自体がメニューやボタンとかのリソースもだし、イベントとかUI的なコンテキストスイッチ的リソースの消費もある、という話なので、プロセスも関係ないけど。
ってか、あれはタブ毎じゃなくてサイト毎にレンダーを動かすって話じゃなかったかな？タブ毎だったっけ。←たしかにタブ毎だった。
関係あるのはIPCとプロセスのオーバーヘッドか。一見スレッドモデルからの退化と思えて、実際は複数プロセスによる分散処理なわけで、DCOMとかで他マシン上にプロセスもって行けば、そのままクラスタ対応型ブラウザなわけだ。
追記
http://blog.livedoor.jp/nshun583/archives/402730.html
http://www.itmedia.co.jp/enterprise/articles/0809/17/news013.html
本を読むのが早い人は、文字から意味へと直接変換できるらしい から 政治家の演説は何故つまらないかについて
http://anond.hatelabo.jp/20090313013634
漢字の思い込みでの読み間違いのエントリーがあるが、まさに麻生の漢字の読み間違いはそういったことなんじゃないかと思う。
なまじ本とか読んでるから、頭の中でそれが定着しちゃってるのだろう、と。
特に本での読み間違いは、朗読でもしていない限り他人に指摘されることはないだろうし。
本というか文字を読むのが早い人というか、本をたくさん読む人と、そうでない人の違いというのはずばり「文字から意味（イメージ）への直接変換ができるかどうか」にあるのだそうだ。それができるかどうかで、全然読む速度が違ってくる。
そうなると、特に表意文字である"漢字"と言うのは、もはや読み方など関係なく、文字だけで意味を拾えてしまうのでやはりこの場合は漢字の読み間違いなどは関係なく意味が読めてしまう。
これができない……読んだ文字を一度頭の中で再生して、それで意味を読んでいる人にはイメージしにくいかも知れないので例を出すと「中国語と日本語で漢字は同じで意味は同じで筆談である程度話ができてしまう」と言うことがある。このときには発音は関係なく直接文字から理解しているのであるが（むしろ読み方が違うので発音すると通じない）これを常にやっていると言ったらわかるだろうか。
そうなると、一度脳内で読み上げてるとオーバーヘッドがあるなしでは全く読む速度や効率が変わってくるのである。また、音声に変換する手間だけではなく、入力デバイスたる体から脳へつながる神経の帯域幅は、おそらく耳よりも目のほうが圧倒的に広く、入力できる情報量は目の法が圧倒的に多いはずだ。もしかしたらつながっている部位も処理の方法も異なって、直接入力ができる人と、頭の中で描いているイメージすら異なるかも知れない。
パソコンに例えると、ビットを直接ストリームで送れるデジタル通信と、一度音響カプラで音声に変換しなければならない通信との違いと言ったら（一部の人には）わかりやすいだろうか。
おそらく麻生氏を初めとした「意味は読み取れるけど発音すると上手くできない」人はそういう脳の構造になっているのではなかろうか。
もちろん中には異常に高性能で超広帯域でつながった音響カプラを持っていて、脳内で超高速音声通信を可能にしている専用回路を持つ人もいるかも知れない。そういう人はおそらく読み上げる文章を書く仕事をしているのではないかと思う。つまり脳内で言葉の響きをシミュレーションできる人だ。たとえば劇作家とか、脚本家とか、放送作家とか。
日本には答弁書を書く役人や政策秘書はいても、スピーチライターと言うのはあまり聞かない。これは何故かというと、スピーチライターに必要とされている能力が、政策を策定するために大量に文章を読んで咀嚼する能力と、言葉に出して読む、響きがいい言葉を音楽のようにつなげる能力は、わりと相反するからではないだろうか
しかし、日本語は漢字という表意文字を用いる言語である。そのため、政治に携わる者、エリートとして国を動かす者などは、どうしても自然と言葉を頭の中で響きよくシミュレーションする能力ではなく、言葉を意味に直接変換する能力が強くなっていってしまう。意識せずに当たり前に文章を読み、文章を書くと、文字から直接意味を読み取り、意味を込めた文章を紡ぐ。しかしこれではどうしても響きのよい言葉は生まれにくいのではないだろうか。
また、下手をすれば、文章を一度音声に変換してから理解するように、耳で聞いた音を一度言葉に直してから意味に変換している可能性はないだろうか。もしそうだとすると、音から直接意味を拾うことのできる人とは、頭の中で描いているイメージすら異なるかも知れない。また、これだと声に出して呼んでも一度脳内で文字に変換しているため、上手く処理できないのではないか。
さらにこれは、政治家だけの問題ではなく、どうしてもスピーチが堅く強ばったものになってしまう人に共通すると思う。
では、以上の仮説からスピーチをよくするにはどうしたらいいのか。当然それは音楽のように響きを組み合わせてスピーチを作れるスピーチライターを呼んでくる、と言う解決策もあるだろうが、それはすぐにできるわけではない。
ならどうするか。それは、文章を書かない事ではないかと思う。
つまり文章を書くのではなく、ICレコーダでも何でもよい、声に出して文章を作り録音し、それを編集することで原稿を作る、つまり口述筆記だ（いや、この場合は筆記は最後にしかしないのでこ筆記ですらないかもしれない）。こうすれば自然と音声でスピーチが作成できるし、文章を読み上げているような堅い文章にはならず、音声で相手に届くものができるのではないだろうか。
いかがだろうか。
てか、口述筆記したものを音声のまま組み替える（編集する）事に特化したようなソフトってないかなぁ。音声の編集ならDTM系ならいくらでも流用できそうな気がするけれど、アウトラインエディター的に言葉を章にわけて、自由に組み替える事ができたらおもしろいと思うんだけどどうだろう。なにかないかな。
いまさらだがFizzBuzz。
1から100まで、3の倍数5の倍数云々って、全部定数の計算じゃね？
というところに気付き、自称メタプログラマー（略してメタグラマー）俺の血が騒いだ。
定数計算なら、それは実行時ではなくコンパイル時に行なわれるべきだ……。
#include <iostream> const int FIZZ_NUM = 3; const int BUZZ_NUM = 5; const int BEGIN_NUM = 1; const int END_NUM = 101; template<int N> struct Fizz { enum {PRINT = 0, NEXT = N + 1}; static void print() {} }; template<int N> struct Buzz { enum {PRINT = 0, NEXT = N + 1}; static void print() {} }; template<int N, bool ForB> struct Number {static void print() {std::cout << N;}}; template<> struct Fizz<FIZZ_NUM> { enum {PRINT = 1, NEXT = 1}; static void print() {std::cout << "Fizz";} }; template<> struct Buzz<BUZZ_NUM> { enum {PRINT = 1, NEXT = 1}; static void print() {std::cout << "Buzz";} }; template<int N> struct Number<N, true> {static void print() {}}; template<int N, int F, int B> struct FizzBuzz { static void print() { typedef ::Fizz<F> Fizz; typedef ::Buzz<B> Buzz; Fizz::print(); Buzz::print(); Number<N, Fizz::PRINT || Buzz::PRINT>::print(); std::cout << std::endl; FizzBuzz<N + 1, Fizz::NEXT, Buzz::NEXT>::print(); } }; template<int F, int B> struct FizzBuzz<END_NUM, F, B> {static void print() {}}; int main(int argc, char **argv) { FizzBuzz<BEGIN_NUM, 1, 1>::print(); return 0; }
ifなし%なしループ系なし、しかも実行時オーバーヘッドなし！（多分）
ああ、久しぶりにC++を触ったけど、やっぱC++のテンプレートってダメダメだな。20世紀の遺物といわざるを得ない。
君がもし21世紀のモテ系イケメンメタグラマーなら、21世紀のプログラミング言語、D言語を使うべきだ！
驚くべきことに、D言語はコンパイル時に関数が実行でき、その結果をソースコードとして取り込める！
ただし実行できるのは簡単な関数だけだけど……。
import std.stdio; // これでFizzBuzzを全部出力するコードを作るぜ！ string makeFizzBuzzCode() { string code; for(int i = 1; i <= 100; ++i) { // 効率？ コンパイル時にそんな配慮は要らん！ if(i % 3 == 0 && i % 5 == 0) { code ~= "writefln(\"FizzBuzz\");\n"; } else if(i % 3 == 0) { code ~= "writefln(\"Fizz\");\n"; } else if(i % 5 == 0) { code ~= "writefln(\"Buzz\");\n"; } else { code ~= "writefln(" ~ static_itoa(i) ~ ");\n"; } } return code; } int main(string[] args) { // おまけで生成されたコードも見せるよ。 pragma(msg, makeFizzBuzzCode()); // 生成したコードを埋め込む。コピペみたいな感覚。 mixin(makeFizzBuzzCode); return 0; } // 以下ユーティリティ。このぐらい標準で欲しいな……。 /// 整数→文字列変換（コンパイル時） string static_itoa(int n) { if(n == 0) { return "0"; } // 10で割りながら余りを文字にして追加。桁が逆転した文字列になる。 string s; for(; n; n /= 10) { s ~= ("0123456789")[n % 10]; } // 桁位置を正常にする。相変わらず効率無視。 return static_reverse(s); } /// 配列リバース（コンパイル時） /// 実行時ならarray.reverseが使えるんだけどね……。 T[] static_reverse(T)(T[] s) { T[] result; foreach_reverse(c; s) { result ~= c; } return result; } // 心配なので静的ユニットテスト（笑） unittest { static assert(static_itoa(0) == "0"); static assert(static_itoa(10) == "10"); static assert(static_itoa(999) == "999"); static assert(static_itoa(9999) == "9999"); static assert(static_itoa(12345) == "12345"); static assert(static_itoa(314159265) == "314159265"); }
コンパイル結果
$ dmd -unittest fizz_buzz.d writefln(1); writefln(2); writefln("Fizz"); writefln(4); writefln("Buzz"); writefln("Fizz"); writefln(7); writefln(8); writefln("Fizz"); writefln("Buzz"); writefln(11); writefln("Fizz"); writefln(13); writefln(14); writefln("FizzBu(ry
出力結果は略。
さすがD言語！C++やJavaやC#にできない事を平然とやってのけるッ
そこにシビれる！あこがれるゥ！
というか、
writefln(1);
writefln(2);
writefln("Fizz");
writefln(4);
もうwritefln（出力関数）要らなくね？
修正。
// これでFizzBuzzを全部出力するぜ！ string makeFizzBuzzCode() { string code; for(int i = 1; i <= 100; ++i) { // 効率？ コンパイル時にそんな配慮は要らん！ if(i % 3 == 0 && i % 5 == 0) { code ~= "FizzBuzz\n"; } else if(i % 3 == 0) { code ~= "Fizz\n"; } else if(i % 5 == 0) { code ~= "Buzz\n"; } else { code ~= static_itoa(i) ~ "\n"; } } return code; } int main(string[] args) { // もうコンパイル時のメッセージしか出さない。（笑） pragma(msg, makeFizzBuzzCode()); return 0; }
コンパイル結果。
$ dmd -unittest fizz_buzz.d 1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBu(ry
実行するまでもなく結果が出力された。つまり実行時間ゼロ、ということは……
世 界 最 速
みんな使おうD言語！
http://www.kmonos.net/alang/d/1.0/index.html(1.0。こっちの方が安定してる？)
http://www.kmonos.net/alang/d/2.0/index.html(もっと凄い2.0)
その昔HTMLソースはエレガントであるべきでそのためには手打ち以外にないという職人派が居ましたね。
理由はいろいろいわれましたが結局は経済的な問題のためです。ドキュメントを表示するクライアントマシンのリソースとそのデータを取得する通信回線の帯域がとても少なく貴重であり、そのために通信量が少なくなるように簡潔なデータで再現にマシンの負担が無いように無駄なドキュメント要素の無い「エレガント」なソースが求められました。
さらに当時Webのコードを書くのは物好きでしかなく、金になりませんでしたので労働単価が安く、コードを人間様が調整するほうが安く済んだのです。
そして今目の前にあるのは有り余るマシンリソースとP2P以外に使い切れないような通信帯域。はっきり言って見た目が同じならいいです。（適当すぎて原因特定もできないトラブルが頻出して手間が増えるのは問題だけど）あまり気にするのは偏執であり、不経済です。
データの再利用も機械がデータを整理するべきで忙しい人間様を煩わせてはいけません。つまりそれはSEOもデータの分析が商売であるGoogle側が頑張るべきことでこちらがやることではないということです。
一部のエンタープライズなサイトではCSS等駆使したキレイな構造化による効率化はクリティカルに効くでしょうが、現実アドホックに組んでるその他圧倒的なページは数十ページ程度で局所的に最適化していてもシステムメリットは出ず、その規模ではむしろ抽象化上昇でオーバーヘッドの増加となるでしょう。
とはいえSEOで見積書の行数が稼げるならなにかと手間が増えた方が商売になるというものでもありまして、まあ良い時代になったのですよとごまかすのも処世と。
入力と関数と出力があって、同じ入力を複数のアルゴリズムで実装された各関数に与え、出力結果が異なるものがあれば異常発生と見なし、システムを停止するなり多数決を行うなり、って話？
朴訥に実装した関数と、こりこりに最適化した関数に、それぞれデータを食わして……みたいな話は既に行われてるよ。朴訥な方は速度が遅いから、テスト段階で、って話だけど。
逆だ逆。無料Ｗｅｂサービスは量で勝負（客数/鯖代）なんだから、実装の冗長化なんて無理（一番遅い実装に速度が引き摺られることになるし、結果の照合を行うプログラムのオーバーヘッドもある）。どうしたって「確実で早い唯一の実装」が求められる。だからテストケースを増やしたり、目を増やしたりするわけだ。
処理コスト・時間コストを使っても安全性が欲しい部分でなら使えるんじゃね？
っていうか前提がおかしいんだな
これはＹｅｓだけど
これはＮｏだなぁ。
「ちゃんと書ける人がちゃんと書く」ならテストとデバッグに掛かるコストは大幅に減少する。
Ｎｏ．比例するに決まってるじゃん。
例外は「労働力」を「時間」と捉えた場合か。「まともな技術者を1ヶ月使う」「まともでない技術者を６ヶ月使う」を同じだと思った場合とか。
測定はできるかもしれん。だけど、前2項がＹｅｓであるような酷いプロジェクトでは、余計な混乱を招くだけだろう。
4番目がYesなら2番目3番目はNoだろうから、前提全てが満たされることはない。
しかし、自動化やマネージメントは、本質的には、あらゆる業務の能率を上げていく
メタスキルであり、とくに日々の業務のなかで発生するちょっとした繰り返し作業は、
その業務分野の専門知識に乏しいプログラマーにアウトソースすると、
プログラマに業務内容を説明するオーバーヘッドの方が大きくなってしまうだろう。
大多数が余裕を持って暮らせる豊かな社会の作り方
でも非プログラマはプログラミング知識がないため、プログラマが長い時間をかけてヒアリングして仕様を起こしコードに落とし込む。でもそこまでのしきいがコスト面時間面で高いため、簡単な業務はいつまでも自動化されない。
自動化とはちょっと違うけど、情報共有でいえばTuigwaaが解法のひとつとなりうる。
Tuigwaa を使えば、現場で働く人たちが、自分たちの業務効率を向上させる為に 自分たちで DB と連動する Web アプリケーションシステムを作ることができます。
つまり、Tuigwaa はボトムアップで企業の生産性向上を実現するためのツールを目指しています。
WebUDA Tuigwaaとは
http://tuigwaa.sandbox.seasar.org/index.html#WebUDA_Tuigwaa%E3%81%A8%E3%81%AF