■ 分裂勘違い君劇場 - Rubyの生産性の高さはどこまで本当か？ 
プログラミング言語の進化の歴史とは、抽象化の歴史でもあります。 そして、抽象化の目的は、２つです。 一つは、処理系による自動最適化です。プログラムコードは、抽象度が高いほど、自動的に最適化し、パフォーマンスを出しやすいのです。 今後も、処理系がインテリジェントになって最適化能力が高まれば高まるほど、プログラミング言語は、最適化のための抽象化を求められ、高級化していくと思います。 そして、もう一つは、自由度と生産性です。より、思ったことを、縦横無尽に書けるようにするため、プログラミング言語は、抽象度が高くなっていきます。 そして、後者の自由度と生産性を目的とした抽象化の行き着く先には、本質的には、Lisp-CLOSにおける、S-Expressionやメタオブジェクトプロトコルと同様のものになってしまうのではないかという予感があるのです。
もちろん、これは、今現在の話ではなく、今現在の話として考えると、「ライブラリや開発環境や普及率や素人受けしやすさやシステムの値段や重たさやレガシーなどの、文脈を無視すれば」という、でっかいIFがついたとしての話になってしまうので、現実には、Lisp-CLOSみたいな重たくて、ライブラリが弱くって、括弧アレルギーを引き起こす、普及していない言語なんかでシステム開発をするのは、まず、ほとんどあり得ないですけど。
■ [開発][プログラミング]劇的に生産性を向上させるメタオブジェクト技術とRuby on Railsの陳腐化の宿命(Java、C#) 
そもそも、「ソフトウェアの再利用可能にしたりプラガブルに設計することで必ず生産性が向上する」という単純な思い込みが、諸悪の根源なのだ。つまり、この記事のように、単純に「同じことを2度しない（Only and Only OnceあるいはDRY：Don't Repeat Yourself）」と無条件で考えてしまうと、逆に生産性が大きく低下するケースがたくさんある。ソフトウェアを、再利用可能な形で設計したり、プラガブルに設計するコストが、そう設計することで得られるメリットを上回るというケースなど、いくらでもある。とく小規模のWebサイトを、さっと作る必要があるときなど、その傾向が強い。余分な工数をかけて再利用可能だのプラガブルだのに設計したところで、あとから状況が変われば、はじめに予見したプラガブルアーキテクチャの範囲内でしか設計変更できない。しかし、そもそも未来の十分な予見など無理な場合だっていっぱいあるのだ。
■ 『Joel on Software』に載っていた「漏れのある抽象化」 
■ [開発][プログラミング]私はなぜフレームワークが嫌いか 
抽象的な設計に関する議論では、話の方向性を見誤ると気が付いたらこういったおかしな話になってしまうこともよくある。どこのレベルで現実に立ち戻るべきか。ちゃんと使えるフレームワークを作るのはとても大変。できることなら、どんなプラットフォームで使える汎用性の高いシステムなんて考えずに済ませられれば、と思う。
あと、個人的な理想としては、大規模な一枚岩のフレームワークを作って使いまわすよりも、依存性の低いモジュールを必要なだけ組み合わせて使うことで、毎回低コストに再構築するような作り方ができないかな、と思っていたりはするのだけど･･･。
■ タスクスイッチのコストを下げる10の方法 
Joel氏はプログラミング作業に必要な短期記憶の内容を以下のように列挙している。
変数名、データ構造、 APIの使い方、便利関数の名前、ファイル名。
他にもポート番号やマシンの名前やIPアドレスやURLや一時的につけたコメントの位置、
特定のバイト列やコンパイルオプション、ＩＤＥのキーバインディングや
デスクトップに置いてある作業ファイルの内容、読みかけの技術書のページ番号など、
挙げていくと相当な量になるだろう。（これを全部列挙するというのも是非やってみたい。）
しかもこれらのリアルタイムな作業情報は、ドキュメント化されないことがほとんどだし、
ドキュメント化するにはコストが高すぎる。
プログラマは、ドキュメントに書かれていない大量の短期記憶に基づいて仕事をする。
