情報弱者
情報強者
2008/11/11(火) 14:35:55
はてな知らないとか何なん？
Googleって聞いたことがあるって人もいるけど、
情報を仕入れようという気持ちはないわけ？
amazon知らない人ってまさかいないよね？
Googleって聞いたことがあるって人もいるけど、
情報を仕入れようという気持ちはないわけ？
amazon知らない人ってまさかいないよね？
↑
2008/11/11(火) 15:58:00
＞amazon知らない人
友人が知りませんでした（実話）。
友人が知りませんでした（実話）。
あ
2008/11/11(火) 17:32:52
はてな http://www.hatena.ne.jp/
本社
〒604-0835
京都府京都市中京区御池通間之町東入高宮町206 御池ビル9F
資本金 5,600万円
googleやYAHOOに比べれば見劣りするが
そこそこネットでは有名やな
本社
〒604-0835
京都府京都市中京区御池通間之町東入高宮町206 御池ビル9F
資本金 5,600万円
googleやYAHOOに比べれば見劣りするが
そこそこネットでは有名やな
あ
2008/11/11(火) 21:28:34
はてなとかgoogleとかamazonなんか知らない奴
多いんじゃないの。おばはんなんか”パソコンする～”
の一語に”メール、ブラウジング、家計簿”等
の意味をつけてるからな。
多いんじゃないの。おばはんなんか”パソコンする～”
の一語に”メール、ブラウジング、家計簿”等
の意味をつけてるからな。
あ
2008/11/12(水) 06:50:38
天才だが、プログラミングが出来ないやつはサブヒューマン。
きくこ
2008/11/12(水) 12:40:08
早川あられ。が好きです☆
サブヒューヒュー！
サブヒューヒュー！
↑↑
2008/11/12(水) 13:53:09
早川、一番有益な言語って何？
Java？
Java？
★ュー
2008/11/12(水) 15:16:46
コンパイル系とスクリプト系から一つずつ選ぶなら
JavaとPerlだろ
JavaとPerlだろ
↑
2008/11/12(水) 15:46:55
＞コンパイル系とスクリプト系
それぞれの相違点を文系にも分かるように説明して下さい。
それぞれの相違点を文系にも分かるように説明して下さい。
eroPC
2008/11/12(水) 17:52:57
パソコンする＝オナ二-する ってのも多そうや
あ
2008/11/12(水) 18:04:41
天才だが、JavaとRubyやっとけ。
↑
2008/11/13(木) 00:49:15
早川、その二つの言語って何がどうすごいの？
文系にも分かるように説明して。
文系にも分かるように説明して。
あ
2008/11/13(木) 00:51:14
天才だが文系（笑）
あ
2008/11/13(木) 08:26:08
天才だが早川ｗ
↑
2008/11/14(金) 04:06:55
ピュイピュイピュイピュイピュイピュイピュイピュイピュイピュイピュイピュイピュイピュイピュイ
ミュー
2008/11/19(水) 00:15:48
Javaはマシンを選ばず動くからすごい。
Rubyはただでさえ強力なPerl言語にオブジェクト指向を取り入れた
完成度の高いスクリプト言語。
コンパイル言語は人間が打ったコードをマシンコードや
それに近い中間ファイルに翻訳してから実行するので速い。
一方スクリプト言語（日常会話ではインタプリタ言語とほぼ同義）は
人間が書いたコードをマシンコードに一行ずつ翻訳しながら実行するため
遅いが修正した結果がすぐに確かめられる。
コンパイル言語でもデバッガ使えば大体同じことできるけどね
Rubyはただでさえ強力なPerl言語にオブジェクト指向を取り入れた
完成度の高いスクリプト言語。
コンパイル言語は人間が打ったコードをマシンコードや
それに近い中間ファイルに翻訳してから実行するので速い。
一方スクリプト言語（日常会話ではインタプリタ言語とほぼ同義）は
人間が書いたコードをマシンコードに一行ずつ翻訳しながら実行するため
遅いが修正した結果がすぐに確かめられる。
コンパイル言語でもデバッガ使えば大体同じことできるけどね
↑
2008/11/19(水) 22:26:47
漢なら、マシン語でダイレクトにコーディングして
OSから自作する。これに尽きる。
OSから自作する。これに尽きる。
あ
2008/11/20(木) 10:07:14
はてななんて２ちゃんの出張所くらいにしかみえないのだが。
だいたいPerlでOOPしてる時点で狂気の沙汰だし、学部基礎レベルのデータ構造とアルゴリズムをちょっと適用してみせて技術力とか言っちゃってるし。
その活動のすべてがネタだとしか思えないのだが。
だいたいPerlでOOPしてる時点で狂気の沙汰だし、学部基礎レベルのデータ構造とアルゴリズムをちょっと適用してみせて技術力とか言っちゃってるし。
その活動のすべてがネタだとしか思えないのだが。
↑
2008/11/20(木) 11:03:41
激しく同意。
あ
2008/11/20(木) 12:06:47
当方麻布卒の天才だが、
え、はてなってしょぼいの？
とても快適に利用させてもらってますけど、
中の人は池沼だらけ？
え、はてなってしょぼいの？
とても快適に利用させてもらってますけど、
中の人は池沼だらけ？
↑
2008/11/20(木) 12:46:02
具体的にどう利用してるのか？
↑
2008/11/20(木) 13:49:25
はてな便利だよね
はてブとか人力検索とか
はてブとか人力検索とか
↑
2008/11/20(木) 15:13:48
便利さと引き換えに有限の時間を失うことについてはスルーですか
あ
2008/11/20(木) 15:15:27
はてなは社名にセンスがない。
理系的愚昧性が顕在している。
理系的愚昧性が顕在している。
あ
2008/11/20(木) 19:24:51
当方麻布卒の天才だが、こいつら、出身は何学部？はてな。
>だいたいPerlでOOPしてる時点で狂気の沙汰だし、学部基礎レベルのデータ構造とアルゴリズムをちょっと適用してみせて技術力とか言っちゃってるし。
kwsk
>だいたいPerlでOOPしてる時点で狂気の沙汰だし、学部基礎レベルのデータ構造とアルゴリズムをちょっと適用してみせて技術力とか言っちゃってるし。
kwsk
↑
2008/11/20(木) 22:10:54
早川、お前の知識で
①Perl
②OOP
③データ構造
④アルゴリズム
について説明してくれ。
説明といっても詳説する必要はないから。
①Perl
②OOP
③データ構造
④アルゴリズム
について説明してくれ。
説明といっても詳説する必要はないから。
あ
2008/11/21(金) 10:42:42
当方麻布卒の天才だが、
１）Rubyはこれの代わりになると言われてます。スクリプト言語です。可読性が著しく低いという事が欠点だと言われています。
２）オブジェクトの責務とコラボレーションに注目したプログラムの設計手法です。
３）むき出しの配列とか、リストとか？
抽象データ型という言葉がオブジェクト指向にはあります
http://ja.wikipedia.org/wiki/%E6%8A%BD%E8%B1%A1%E3%83%87%E3%83%BC%E3%82%BF%E5%9E%8B
が、ある単純な責務を負った非常に原始的な構造の事でしょうか？
オブジェクト指向の世界ではデータ構造なんていう概念は存在しません。内部実装はカプセル化してください。
４）ある問題を解く為の効率のよいプログラミングの書き方です。一般にその効率はオーダーによって評価されたり、あとは実際に問題領域に対して動かして計算時間で評価する事もあります。
１）Rubyはこれの代わりになると言われてます。スクリプト言語です。可読性が著しく低いという事が欠点だと言われています。
２）オブジェクトの責務とコラボレーションに注目したプログラムの設計手法です。
３）むき出しの配列とか、リストとか？
抽象データ型という言葉がオブジェクト指向にはあります
http://ja.wikipedia.org/wiki/%E6%8A%BD%E8%B1%A1%E3%83%87%E3%83%BC%E3%82%BF%E5%9E%8B
が、ある単純な責務を負った非常に原始的な構造の事でしょうか？
オブジェクト指向の世界ではデータ構造なんていう概念は存在しません。内部実装はカプセル化してください。
４）ある問題を解く為の効率のよいプログラミングの書き方です。一般にその効率はオーダーによって評価されたり、あとは実際に問題領域に対して動かして計算時間で評価する事もあります。
↑
2008/11/21(金) 11:26:10
データ構造はデータをプログラムで操作するための枠組み。オブジェクト指向のクラスはまさにデータ構造そのもの
「アルゴリズム = プログラミングの書き方」は限定しすぎだろ。アルゴリズムは処理手順、プログラムは実装の一種。別に電子回路で実装しても良いのだから。
「アルゴリズム = プログラミングの書き方」は限定しすぎだろ。アルゴリズムは処理手順、プログラムは実装の一種。別に電子回路で実装しても良いのだから。
あ
2008/11/21(金) 12:02:28
君はオブジェクト指向を構造体の延長だと考えてる完全なる池沼だな。
オブジェクト指向において、オブジェクトには責務に対する振る舞いしか持たせてはいけない。データ構造は隠蔽すべきだ。そういった抽象的な振る舞いのセットを抽象データ型という。
クラスはデータ構造ではない、クラスは振る舞いしか持たない。その中身に対して直接アクセスして操作しようというのであれば、もはやそれはクラスではない。そうやって設計されたプログラムはきちんとしたクラスに分割されず、不必要な結合を生みだし、結果として、脆いプログラムになる。君はたぶんテストファーストをしたらいい。そしたら今のC言語の延長的な腐敗した思考から解放されるだろう。いいか、クラスはインターフェイスという名の振る舞いしか持たない。要はそれが正しく抽象的に分割されてるかどうかだ。データ構造なんていう言葉はどこにも出てこない。
一般的には、アルゴリズムは数学的な要素が強いと思うが、おれの領域では、問題があり、それを解決する為の手段がアルゴリズムだ。それは常にプログラムによって実現される。よってとある問題をプログラムにより効率的に解決する手法がアルゴリズムという考えだ。
オーダー表記というのもおれは使わない。実際に動かしてみない事には分からんのだ。あと、プログラムの話でいえば、著しく可読性を落とすアルゴリズムはもはやジョークだ。
問題というのは、常に、「作ってみたけど、くそ遅い。どこが遅いかプロファイラで調べたらここが遅いから直さないとダメだ」という風に発生する。
オブジェクト指向において、オブジェクトには責務に対する振る舞いしか持たせてはいけない。データ構造は隠蔽すべきだ。そういった抽象的な振る舞いのセットを抽象データ型という。
クラスはデータ構造ではない、クラスは振る舞いしか持たない。その中身に対して直接アクセスして操作しようというのであれば、もはやそれはクラスではない。そうやって設計されたプログラムはきちんとしたクラスに分割されず、不必要な結合を生みだし、結果として、脆いプログラムになる。君はたぶんテストファーストをしたらいい。そしたら今のC言語の延長的な腐敗した思考から解放されるだろう。いいか、クラスはインターフェイスという名の振る舞いしか持たない。要はそれが正しく抽象的に分割されてるかどうかだ。データ構造なんていう言葉はどこにも出てこない。
一般的には、アルゴリズムは数学的な要素が強いと思うが、おれの領域では、問題があり、それを解決する為の手段がアルゴリズムだ。それは常にプログラムによって実現される。よってとある問題をプログラムにより効率的に解決する手法がアルゴリズムという考えだ。
オーダー表記というのもおれは使わない。実際に動かしてみない事には分からんのだ。あと、プログラムの話でいえば、著しく可読性を落とすアルゴリズムはもはやジョークだ。
問題というのは、常に、「作ってみたけど、くそ遅い。どこが遅いかプロファイラで調べたらここが遅いから直さないとダメだ」という風に発生する。
↑
2008/11/21(金) 12:50:04
>> データ構造なんていう言葉はどこにも出てこない。
そりゃクラスって呼ばれているのだから出てくるはずがない。
何か間違ったことを書いたか？ データ操作の枠組みとはすなわちデータ処理に対する振る舞いの集合、プログラムに本質はデータ処理なのだから、君の流儀に従えば、責務に対する振る舞い (の集合) になると思うんだけど。データ構造は別にデータを含んでいるわけではないし、ましてやcでいうところの構造体とは関係ないよ。
そりゃクラスって呼ばれているのだから出てくるはずがない。
何か間違ったことを書いたか？ データ操作の枠組みとはすなわちデータ処理に対する振る舞いの集合、プログラムに本質はデータ処理なのだから、君の流儀に従えば、責務に対する振る舞い (の集合) になると思うんだけど。データ構造は別にデータを含んでいるわけではないし、ましてやcでいうところの構造体とは関係ないよ。
↑×４
2008/11/21(金) 13:37:44
早川、ありがとう。
a
2008/11/21(金) 14:17:48
おい、池沼。
http://lise.me.sophia.ac.jp/kktm/Essay/abstract.htm
http://www.codereading.com/algo_and_ds/ds/adt_and_class.html
これを見なさい。データ構造というのは抽象データ型の内部に隠蔽される、むき出しの存在である。例えば、配列というものに対して、a[i]=5とかするのはデータ構造の書き方であり、Array#set(i, 5)とかするのはこれは抽象である。この時点で配列というメモリ上の存在への操作から、クラスの振る舞いという概念に変わっている。
君はカプセル化に対しての知見が足りていない。データ構造がクラスだとか言い出す時点で終わってる。データ構造などというのは非常に原始的な話題であり、オブジェクト指向のレイヤーでは一切出てこない言葉だ。
抽象データ型、ＡＤＴというが、これについて勉強してからやり直しなさい。おれについてはコードコンプリートによく書かれている。
http://lise.me.sophia.ac.jp/kktm/Essay/abstract.htm
http://www.codereading.com/algo_and_ds/ds/adt_and_class.html
これを見なさい。データ構造というのは抽象データ型の内部に隠蔽される、むき出しの存在である。例えば、配列というものに対して、a[i]=5とかするのはデータ構造の書き方であり、Array#set(i, 5)とかするのはこれは抽象である。この時点で配列というメモリ上の存在への操作から、クラスの振る舞いという概念に変わっている。
君はカプセル化に対しての知見が足りていない。データ構造がクラスだとか言い出す時点で終わってる。データ構造などというのは非常に原始的な話題であり、オブジェクト指向のレイヤーでは一切出てこない言葉だ。
抽象データ型、ＡＤＴというが、これについて勉強してからやり直しなさい。おれについてはコードコンプリートによく書かれている。
b
2008/11/22(土) 10:41:21
で、早川に楯突いた情弱野郎はどこに行ったんだww
あ
2008/11/22(土) 14:43:01
オブジェクト指向のクラスはデータ構造か否かについて。
確かにオブジェクト指向の機能面(例えば継承や多態性や遮蔽性など)にはデータ構造に該当する概念は存在しない。
しかしOOPLそのもの(例えばrubyなど)がCで実装されているという事実を鑑みれば、クラスそのものはデータ構造であるという指摘は正しい。
確かにオブジェクト指向の機能面(例えば継承や多態性や遮蔽性など)にはデータ構造に該当する概念は存在しない。
しかしOOPLそのもの(例えばrubyなど)がCで実装されているという事実を鑑みれば、クラスそのものはデータ構造であるという指摘は正しい。
41
2008/11/23(日) 06:02:13
> 一般にその効率はオーダーによって評価されたり、あとは実際に問題領域に対して動かして計算時間で評価する事もあります。
対数時間でないアルゴリズムを実際に動かせるのは問題のサイズが小さい場合だけ。しかも同じ問題クラスでもbest caseからworst caseまでピンキリだから、問題インスタンスのテストでは不十分。ここは理論的にやるべきところだろう。
> あと、プログラムの話でいえば、著しく可読性を落とすアルゴリズムはもはやジョークだ。
可読性はプログラム=実装の問題であって、アルゴリズムには使わない。既に指摘されているようにアルゴリズムは実装ではない。ただしアルゴリズムには実装の容易さという要求がある。
> 例えば、配列というものに対して、a[i]=5とかするのはデータ構造の書き方であり、Array#set(i, 5)とかするのはこれは抽象である。
C言語と何らかのOOP言語を比較しているようだが、前者のような記法で抽象データ型を操作できる言語も有りうる。シンタクティックシュガーという。シンタックスは言葉と同じで定義されるものだから、表面的な記法だけを見て議論はできない。
> おれについてはコードコンプリートによく書かれている。
Code Completeはプログラミング一般に関するプラクティスの本であって、アルゴリズムについては深くない。Algorithm Design Manualがおすすめ。
> しかしOOPLそのもの(例えばrubyなど)がCで実装されているという事実を鑑みれば、クラスそのものはデータ構造であるという指摘は正しい。
概念の議論で実装は根拠にならないだろう。
対数時間でないアルゴリズムを実際に動かせるのは問題のサイズが小さい場合だけ。しかも同じ問題クラスでもbest caseからworst caseまでピンキリだから、問題インスタンスのテストでは不十分。ここは理論的にやるべきところだろう。
> あと、プログラムの話でいえば、著しく可読性を落とすアルゴリズムはもはやジョークだ。
可読性はプログラム=実装の問題であって、アルゴリズムには使わない。既に指摘されているようにアルゴリズムは実装ではない。ただしアルゴリズムには実装の容易さという要求がある。
> 例えば、配列というものに対して、a[i]=5とかするのはデータ構造の書き方であり、Array#set(i, 5)とかするのはこれは抽象である。
C言語と何らかのOOP言語を比較しているようだが、前者のような記法で抽象データ型を操作できる言語も有りうる。シンタクティックシュガーという。シンタックスは言葉と同じで定義されるものだから、表面的な記法だけを見て議論はできない。
> おれについてはコードコンプリートによく書かれている。
Code Completeはプログラミング一般に関するプラクティスの本であって、アルゴリズムについては深くない。Algorithm Design Manualがおすすめ。
> しかしOOPLそのもの(例えばrubyなど)がCで実装されているという事実を鑑みれば、クラスそのものはデータ構造であるという指摘は正しい。
概念の議論で実装は根拠にならないだろう。
41
2008/11/23(日) 06:18:52
はてなの強みはよくわからない。ウェブ系のサービスを独立して展開している国内で数少ない会社というくらいしか。それだけ日本が貧弱ということだろう。
それと情報収集にコストをかけすぎるのはよくない。
それと情報収集にコストをかけすぎるのはよくない。
あ
2008/11/23(日) 10:27:26
当方麻布卒の天才だが、
とりあえず日本のITがうんこすぎる事だけは同意する。
とりあえず日本のITがうんこすぎる事だけは同意する。
41
2008/11/23(日) 23:41:14
訂正。記法 (notation) ではなく構文 (syntax) だ。
やはりレビューすると自分の文章に間違いがあることに気づく。私たちは日本語の文章なんて滅多に書かないからなおさらだ。
やはりレビューすると自分の文章に間違いがあることに気づく。私たちは日本語の文章なんて滅多に書かないからなおさらだ。
41
2008/11/23(日) 23:50:20
麻布の天才氏は迅速に実装する方だから、設計と実装を区別する必要があまりないのだろう。アルゴリズムの表現手段の一つは現実のプログラミング言語だから、「可読性の低いアルゴリズム」も間違いではないかもしれない。
I suppose Akira does not distinguish design and implementation in principle because he is an agile programmer. Since a real programming language is one of the ways to represent algorithms, we may say that an algorithm is unreadable.
I suppose Akira does not distinguish design and implementation in principle because he is an agile programmer. Since a real programming language is one of the ways to represent algorithms, we may say that an algorithm is unreadable.
あ
2008/11/24(月) 07:47:57
君はアジャイルを誤解している。
そして、英語がめちゃくちゃだ。恥を知れ。
そして、英語がめちゃくちゃだ。恥を知れ。
41
2008/11/24(月) 19:56:22
日本語がめちゃくちゃというコメントは削除されたが、英語についてはOKのようだ。日本語は人格の一部だが、英語は論理だから、他人の英語を批判するのは構わないのだろう。
あ
2008/11/24(月) 20:24:57
当方麻布卒の天才だが、
とりあえず４１、お前、なんか生意気だから、
お前が書いたコードをうpしろ。
おれが評価して、ダメだししてやる。
とりあえず４１、お前、なんか生意気だから、
お前が書いたコードをうpしろ。
おれが評価して、ダメだししてやる。
41
2008/11/24(月) 23:27:48
無理。41はコードを書かない。それよりも英語の誤りを具体的に指摘してほしい。
あ
2008/11/24(月) 23:38:13
自分の心に聞いてみな。
41
2008/11/24(月) 23:38:30
ITに物凄く弱い日本で、中途半端にITに通じることは幸福なことだろうか。意に反してネットワーク管理者をやらされたり、かえって不幸になることも多いのではないか。重要なのは、はてななんて知っていることよりも、リア充であることではないか。
41
2008/11/24(月) 23:45:07
心に聞いてもわからないよな。まあサブヒューマンらしいから英語を正すのはあきらめよう。
あ
2008/11/25(火) 02:42:19
ITバブルも終わった感があるな
あ
2008/11/25(火) 07:35:27
当方麻布卒の天才だが、リア充が未定義語だ。
おれには彼女も友達もいない。朝、研究室に向かい晩までパソコンの前にいて、家に帰ったら寝るだけの生活だが、自分では激しくリア充だと思っている。
きっと、自分の正しいと思う事に打ち込んでる人間がリア充なのではないだろうか？リア充とはリアルが充実の略である。充実感というものは常に主観的なものであり、他人が見て決めるものではない。非リアが彼女持ちを見てリア充と決めつけるのはそれはただの憧れに過ぎない。
今、おれの生活は充実している。毎日が楽しい。それだけで、おれのこの単調な日々はそれでも充実していると言い切れる。
おれには彼女も友達もいない。朝、研究室に向かい晩までパソコンの前にいて、家に帰ったら寝るだけの生活だが、自分では激しくリア充だと思っている。
きっと、自分の正しいと思う事に打ち込んでる人間がリア充なのではないだろうか？リア充とはリアルが充実の略である。充実感というものは常に主観的なものであり、他人が見て決めるものではない。非リアが彼女持ちを見てリア充と決めつけるのはそれはただの憧れに過ぎない。
今、おれの生活は充実している。毎日が楽しい。それだけで、おれのこの単調な日々はそれでも充実していると言い切れる。
↑
2008/11/25(火) 09:00:52
大筋には同意
満足している人ならリア充と言えると思う
みんな彼女をほしがっているから、
彼女がいる人がリア充となっているが、
それだけとは限らないと思う
ただ充実感は他人に分からないだけでなく、
自分でも本当のところは分からないのではないか
彼女がいなくても充実していると思っていた人が、
彼女が出来て今までの生活はやはり不満だったんだと
気がつく可能性もある
満足している人ならリア充と言えると思う
みんな彼女をほしがっているから、
彼女がいる人がリア充となっているが、
それだけとは限らないと思う
ただ充実感は他人に分からないだけでなく、
自分でも本当のところは分からないのではないか
彼女がいなくても充実していると思っていた人が、
彼女が出来て今までの生活はやはり不満だったんだと
気がつく可能性もある
あ
2008/11/25(火) 11:11:07
失って気づく大切なものだってあるみたいだしな。
もはや都市伝説だが。
もはや都市伝説だが。
あ
2008/11/26(水) 16:07:04
リア充の定義はきちんとされてないが、一般的なネットの使われ方では、個人が充実していると感じているかどうかではなく、社会的に見て充実しているように見えるかどうかってことでしょ。
だから本人の充実感が低くても、イケメンで彼女持ちだったり、ポジティブな活動に参加していて、一般的な大多数の他人から見て羨ましいと思わるような状況ならリア充になるはず。
充実感自体は主観的な感覚だと思うが、リア充と言う言葉は客観的に見た場合の状況を指すということじゃないかな。
だから一般的な「リア充」とはやや異なるが、自分の毎日が充実してるならそれはそれはそれでリア充ではなる。
そもそもリア充って言葉もおかしいんだけどね。
リアルが充実って生活はすべてリアルでしょ。
例えば非リアな人がするエロゲーとかの類はそれ自体は虚構で非リアルなものだが、プレイしてる人のその時自体は全て現実なんだからさ。
だから本人の充実感が低くても、イケメンで彼女持ちだったり、ポジティブな活動に参加していて、一般的な大多数の他人から見て羨ましいと思わるような状況ならリア充になるはず。
充実感自体は主観的な感覚だと思うが、リア充と言う言葉は客観的に見た場合の状況を指すということじゃないかな。
だから一般的な「リア充」とはやや異なるが、自分の毎日が充実してるならそれはそれはそれでリア充ではなる。
そもそもリア充って言葉もおかしいんだけどね。
リアルが充実って生活はすべてリアルでしょ。
例えば非リアな人がするエロゲーとかの類はそれ自体は虚構で非リアルなものだが、プレイしてる人のその時自体は全て現実なんだからさ。
41
2008/12/01(月) 04:13:24
麻布の自称天才が言っているプロファイリング云々は一般的にいう最適化でしょう。ならば大筋において正しいはず。「早すぎる最適化はよくない」という原則があります。
あ
2008/12/08(月) 10:18:45
当方天才だが、
プログラミング力がおれ未満のやつは全員サブヒューマン。
プログラミング力がおれ未満のやつは全員サブヒューマン。
追加発言