トップダウンは、知っていることを説明したり、既に構築したものを再構築したりするのに最適な方法です。
トップダウンの最大の問題は、多くの場合、単に「トップ」がないことです。システムの開発中およびドメインの探索中に、システムが何をすべきかについて考えを変えます。どのようにして、あなたが知らないこと（つまり、システムに何をしてもらいたいか）の出発点になりますか？
「ローカル」トップダウンは良いことです...コーディングより先に考えることは明らかに良いことです。しかし、考えすぎて計画を立てることはそうではありません。なぜなら、あなたが想像しているのは本当のシナリオではないからです（以前にそこに行ったことがない場合、つまり、構築していないが再構築している場合）。新しいものを構築する際のグローバルなトップダウンはナンセンスです。
ボトムアップは、問題の100％を知っている場合を除き、（グローバルに）アプローチである必要があります。既知のソリューションをコーディングするだけでよく、可能な代替ソリューションを探す必要はありません。
Lispアプローチは、蒸留されたボトムアップです。ボトムアップでビルドするだけでなく、必要に応じてレンガを形作ることもできます。何も固定されておらず、自由は完全です。もちろん自由には責任があり、この力を悪用することで恐ろしいものを作ることができます。
しかし、恐ろしいコードはどの言語でも書くことができます。心のためのケージのような形をした言語でさえ、それらの言語で猿でも良いプログラムを実行できるように設計されています（考えているだけでも痛いほど多くのレベルで非常に間違った考えです）。
あなたの例はウェブサーバーについてです。2012年には、これは明確に定義された問題であり、従うべき仕様があります。Webサーバーは単なる実装上の問題です。特に、そこにある他の数十億のWebサーバーと実質的に同一のWebサーバーを作成することを目指している場合、いくつかの特徴を除いて、実際には何も明確ではありません。RSAについてのあなたのコメントでさえ、正式な仕様で明確に定義された問題について話し続けています。
明確に定義された問題、正式な仕様および既知のソリューションを使用すると、コーディングはドットで接続されます。トップダウンは大丈夫です。これがプロジェクトマネージャーの天国です。
ただし、多くの場合、ドットの接続に使用される実証済みの既知のアプローチはありません。実際には、ドットとは何かを言うのも非常に困難です。
たとえば、自動切断機に、切断する部品を理論上の反復ロゴに完全に適合していない印刷物に合わせるよう指示するように求められたとします。機械で撮影された材料の部品と写真が提供されます。
アライメントルールとは何ですか？あなたが決める。パターンとは何ですか？あなたが決める。部品の位置合わせ方法は？あなたが決める。部品を「曲げる」ことはできますか？依存するものもあれば、そうでないものもありますが、もちろんそれほど多くはありません。材料が変形しすぎて部品が許容範囲内で切断できない場合はどうすればよいですか？あなたが決める。材料ロールはすべて同一ですか？もちろんそうではありませんが、ロールごとにアライメントルールを調整するようにユーザーをバグにすることはできません...それは非現実的です。どの写真がカメラを見ていますか？マテリアルは、それが何を意味するにせよ...それは色でありえ、光反射だけでパターンが明らかになる黒の上に黒であることができます。パターンを認識するとはどういう意味ですか？あなたが決める。
次に、この問題の解決策の一般的な構造を設計し、お金と時間で見積もりを出してください。私の賭けは、あなたのシステムアーキテクチャさえ...（そう、アーキテクチャ）が間違っているということです。コストと時間の見積もりは乱数になります。
私たちはそれを実装し、現在は動作するシステムになっていますが、システムの形について何度も気が変わりました。メニューからもアクセスできないサブシステム全体を追加しました。プロトコルでマスター/スレーブの役割を複数回切り替えました。おそらく今、私たちはより良い再構築を試みるのに十分な知識を持っています。
もちろん、他の会社も同じ問題を解決しました...しかし、これらの会社のいずれかに所属していない限り、おそらくトップダウンの詳細なプロジェクトは冗談でしょう。トップダウンで設計できます。前にやったことがないからできません。
おそらく同じ問題も解決できます。ただし、ボトムアップで作業します。あなたが知っていることから始めて、あなたが知らないことを学び、合算します。
新しい複雑なソフトウェアシステムは、設計ではなく成長しています。時々、誰かが大きな新しい複雑で不特定のソフトウェアシステムをゼロから設計し始めます（大きな複雑なソフトウェアプロジェクトでは、3つの可能性しかありません。またはc]両方...そして、ほとんどの場合[c]が該当します）。
これらは、パワーポイントスライドとUMLダイアグラムだけに数千時間も費やされる典型的な大企業プロジェクトです。それらは、恥ずかしいほどのリソースを燃やした後は必ず完全に失敗します...または非常に例外的なケースでは、初期仕様のほんの一部だけを実装する高価なソフトウェアを最終的に提供します。そして、そのソフトウェアは常にユーザーから深く嫌われています...あなたが買うソフトウェアの種類ではなく、あなたが強制されているために使用するソフトウェアの種類です。
これは、コードだけを考えるべきだと思うということですか？もちろん違います。しかし、私の意見では、構築は下から始まり（レンガ、具体的なコード）、上に行く必要があります...そして、細部への焦点と注意は、あなたが持っているものから遠くなるにつれて、ある意味「フェード」するべきです。トップダウンは、多くの場合、システム全体に同じレベルの詳細を一度に配置する必要があるかのように表示されます。すべてが明らかになるまで、すべてのノードを分割し続けるだけです。現実のモジュールでは、サブシステムはサブルーチンから「成長」します。特定の問題で以前の経験がない場合、サブシステム、モジュール、またはライブラリのトップダウン設計は恐ろしいものになります。どの関数を挿入するかがわかれば、適切なライブラリを設計できます。
Lispのアイデアの多くは人気が高まっています（ファーストクラスの関数、クロージャー、デフォルトとしての動的型付け、ガーベッジコレクション、メタプログラミング、インタラクティブな開発）あなたが必要なもののために。
たとえば、キーワードパラメータはすでに存在しますが、存在しない場合は追加できます。私が試しているおもちゃのLispコンパイラ用に（コンパイル時のキーワード検証を含めて）実行しましたが、コードはあまり必要ありません。
代わりにC ++を使用すると、キーワードパラメータはそれほど有用ではない、または非常に複雑で壊れた、裏付けのあるテンプレート実装であり、実際にはそれほど有用ではないというC ++の専門家の集まりが得られます。C ++クラスはファーストクラスのオブジェクトですか？いいえ、それについてできることは何もありません。実行時またはコンパイル時にイントロスペクションを使用できますか？いいえ、それについてできることは何もありません。
Lispのこの言語の柔軟性は、ボトムアップの構築に最適なものです。サブルーチンだけでなく、言語の構文とセマンティクスも構築できます。そしてある意味で、Lisp自体はボトムアップです。