その他
HN: The Good Parts (2016)
HN: The Good Parts (2016) (danluu.com)
要約
Hacker Newsのコメント欄は、しばしば低品質で攻撃的ですが、技術的なコメントにおいては他のフォーラムよりも優れていると筆者は主張します。専門知識を持つコメントは稀ですが、現れた際には上位に表示されやすく、質の高い技術的議論が埋もれにくい傾向があります。著名な貢献者によるコメントは特に価値が高いとされています。
全文翻訳
HNのコメントはひどい。私が詳しいトピックについては、コメントの大部分は明らかに間違っている。ほとんどの場合、そのトピックについて知っている人からのコメントはゼロで、トップのコメントはもっともらしく聞こえるが完全に間違っている。さらに、多くのコメントは不必要に意地が悪い。「これは、お互いを褒め合うだけのコメント『これは素晴らしい』のようなものよりも良い」といった理由で、意地悪なコメントが正当化されることがよくあるが、まるで意地悪であることが空虚な決まり文句に対するお守りであるかのように。これに反論する人もいる。追い詰められると、人々はしばしば、意地悪でなければ教えることは不可能か非効率的だと言う。まるで、人を馬鹿だと伝えることが学習を助けるかのように。まるで、サイモン・コーウェルを見て説明の仕方を学んだかのようで、個人的な侮辱で散りばめられていない説明の概念を理解できないかのようだ。ポール・グレアムは「あなたが書いたものについてのHacker Newsのコメントは絶対に読むべきではない」と言っている。HNのコメントについて聞く否定的なことのほとんどは真実だ。それにもかかわらず、私はこれより優れた技術的コメントを持つ公開インターネットフォーラムを見つけていない。私が慣れているトピックについては、スレッドに情報が豊富なコメントが一つでも含まれることは稀だが、それらのコメントが現れると、通常は上位に浮上する。他のフォーラムでは、情報が豊富なコメントは存在しないか、現れたときに、もっともらしく聞こえるが完全に間違ったコメントに埋もれてしまう。そして、HNよりもさらに稀に現れる。量で言えば、リンクよりもコメントの方が、興味深い技術的な「投稿」が多いだろう。まあ、それはあなたが興味深いと思うものによるが、私の興味にとっては真実だ。nkurzからの低レベル最適化のコメント、patio11からのビジネスに関するコメント、nostrademonsによる企業運営に関するコメントを見たら、興味深いコメントを読むことになるだろうとほぼ確信できる。あまりブログを書かないが、HNで素晴らしいコメントを書く人は20〜30人くらいいるだろう。そして、HNで素晴らしいコメントを書いている人の半分も知らないだろう。コメントは失われがちなので、非常に簡略化された好きなコメントのリストをまとめた。ブログ記事を書けば、何年も参照されるだろうが、コメントはほとんど消えてしまう。それは悲しいことだと思う。HNには素晴らしい素材がたくさんある(そして、はい、それ以上に良くない素材も)。MS Wordのファイル形式はどうなっているのか?基本的に、Wordのファイル形式はメモリのバイナリダンプだ。冗談抜きで。メモリにあったものをそのままディスクに書き出しただけだ。なぜそうしたのか(おそらく速かったから、コードが小さくなったから)を推測することはできるが、主な理由は、元の開発者が何も知らなかったからだと思う。後で機能を追加しようとしたときに、後方互換性を保つ必要があった。そこに複雑さの多くがある。再設計を許せば簡単なことでも、多くのクレイジーな回避策がある。これは経営陣によって義務付けられたことは明らかだ。なぜなら、ソフトウェア開発者が理由もなく自分自身をその地獄に陥れることはないからだ。後で、高速保存機能(実際には何と呼ばれるか忘れた)を追加した。これは元のファイルを変更せずに変更をファイルに追加する。実装方法は非常に巧妙だったが、ファイル構造を非常に複雑にした。一つ指摘しておきたいこと(この記事が最初に投稿されたときにslashdotに巨大なものを投稿したのを覚えている)は、ワードプロセッサの双方向ファイル変換はほぼ不可能だということだ。なぜなら、ファイル形式にはドキュメントをフォーマットするのに十分な情報が含まれていないからだ。最も明白な例はページネーションだ。ファイル形式は、テキストフローのページネーションを(ユーザーが明示的に入力しない限り)指定しない。フォーマッタにそれを任せる。各ワードプロセッサはテキストを完全に異なる方法でフォーマットする。例えば、Wordは脚注を不正確にページネーションすることで有名だ。しかし、後方互換性を損なうため、変更できない。Word Perfectが今日まで生き残っている唯一の理由の一つだ。米国司法省が要求する法的文書のページネーション方法を行っている唯一のワードプロセッサだからだ。ページネーションの問題だけを考えても、問題がわかるだろう。Word文書を読むとき、Wordのようにページネーションする必要がある。しかし、ファイル形式はその情報を提供しない。誰かがドキュメントを変更し、それを再保存する必要がある場合、Wordのようにページネーションするようにマークする必要がある(たとえWordにない機能が含まれているとしても)。ページネーションだけなら、できるかもしれないが、実際にはすべてがそのようになっている。興味のある人は、XML Wordファイル形式の(一部)を読むことをお勧めする。例えば「Word 95のようにフォーマット」のようなフラグが多数表示されるだろう。フォーマットはそれが何であるかを指定しない。なぜなら、ファイル形式の作者でさえそれを知らないことは明らかだからだ。それはレガシーコードの絶望的な混乱の中に失われており、誰もそれが今何をするのか理解できない。NULLとの楽しみ これは、この素晴らしい機能のもう一つの例だ:#include <stdio.h> #include <string.h> #include <stdlib.h> #define LENGTH 128 int main(int argc, char **argv) { char *string = NULL; int length = 0; if (argc > 1) { string = argv[1]; length = strlen(string); if (length >= LENGTH) exit(1); } char buffer[LENGTH]; memcpy(buffer, string, length); buffer[length] = 0; if (string == NULL) { printf("String is null, so cancel the launch.\n"); } else { printf("String is not null, so launch the missiles!\n"); } printf("string: %s\n", string); // nullでは未定義だが実際には動作する #if SEGFAULT_ON_NULL printf("%s\n", string); // bare " %s\n" の場合、nullでセグフォールトする #endif return 0; } nate@skylake:~/src$ clang-3.8 -Wall -O3 null_check.c -o null_check nate@skylake:~/src$ null_check String is null, so cancel the launch. string: (null) nate@skylake:~/src$ icc-17 -Wall -O3 null_check.c -o null_check nate@skylake:~/src$ null_check String is null, so cancel the launch. string: (null) nate@skylake:~/src$ gcc-5 -Wall -O3 null_check.c -o null_check nate@skylake:~/src$ null_check String is not null, so launch the missiles! string: (null) IntelのICCとClangはまだGCCの最適化に追いついていないようだ。必要なパフォーマンスを得るためにその最適化に依存していたら、痛いだろう!しかし、GCCをあまり責める前に、3つのコンパイラすべてが、printf("string: "); printf("%s\n", string) を単一のステートメントとして問題なく実行できるにもかかわらず、stringがNULLの場合にセグフォールトすることを考慮してほしい。2つの別々のステートメントがセグフォールトを引き起こす理由がわかるだろうか?わからない場合は、ヒントを見てほしい:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609 オートパイロットのバックアップが注意を払っていることをどうやって確認するのか?優れたエンジニアリングは、ユーザーが間違ったことをする可能性を可能な限り排除する。…誤用を招くような機能を設計しておきながら、その誤用を防ぐために指示を使うべきではない。オーストラリアでウォーターフォール脱線事故([1])が発生した。運転手が心臓発作を起こし、7人の死者を出した(正直、それだけだったのは奇跡だ)。根本原因はデッドマンズスイッチの故障だった。ウォーターフォールのケースでは、運転手は2つのデッドマンズスイッチを使用できた。1)スロットルハンドルを小さな回転でバネに押し付けておくか、2)床のバーを踏むか。どちらかを行う必要があった。その考えは、手首や足のけいれんを防ぐために、運転手が両者を交互に使用できるようにすることだった。どちらも行わないと緊急ブレーキが作動する。この運転手は十分に太っていたため、心臓発作を起こしたときに、足がペダルを十分に踏んで緊急システムをオフに保つことができた。したがって、デッドマンズシステムは、運転席に多くの死んだ人間がいるにもかかわらず、決して作動しなかった。具体的な詳細は覚えていないが、