アカウント名:
パスワード:
classとか設計に絡むものが言語仕様に取り込まれると、設計スキルが如実にコードに出る。適切に使える人と格差が出やすいので、それでビジネスをする人にとって有利な言語かもしれない。格差があれば、大きな利益を得られる訳だ。
一つの言語で低レベルのシステム記述から, 抽象度の高いアプリケーションまで対応させようという試みは, 古くはPL/IからAdaなど, 総じて良い結果を出したとは言えないですよね. その中ではC++はまだうまくやっている方だとは思いますが.
昔から, 銀の弾丸では無いですけど, 一つの言語で全ての用途をカバーするという欲求は強いんですが(その昔にはCOBOLで経済学的な数値解析をしたいというニーズも有ったらしい), むしろ用途に応じて数個の言語を使い分ける方が, 初期投資は大きくても最終的には幸せになれると思います.
個人的にはベースとなるCに, Lua [lua.org]の様な軽量スクリプト言語, それにPython, Rubyの様なリッチなスクリプト言語の組み合わせぐらいがバランスが取れていそうと感じますが.
Luaなどの組み込み言語を使う用途の場合、手続き的処理を記述するのが主目的なので、モージュール内部でカプセル化とか、ポリモーフィズムとか、オブジェクト指向言語の持つ性質はコード中にあまり必要とされないでしょうね。
それに、組み込み言語を使うような所は、末端のエンジニアがコーディングする部分だと思うので、言語仕様の拡張性の高さより、「必要十分なシンプルさ」といった性質の方がメリットがありそうです。言語仕様がシンプルなら、プログラムバグの傾向も把握しやすそうです。
実のところ、カプセル化とか、ポリモーフィズムといった性質って、モジュール単位(実行プログラムやライブラリ)には既に備えている性質です。今回はCとC++の話なので、カプセル化とか、ポリモーフィズムといった性質をモジュールより細かいソース単位の粒度で扱いたい立場の人に対する話ですね。なので、微妙に数個の言語の話は微妙に路線が違うかもしれません。
「あまねく関数、構造体、技術者にオブジェクトの光あれ。」と言った時、暖かい救いのある光に感じるか、あるいは、憎しみの光に感じるか。それは経歴次第かな。モジュール・ライブラリ単位の抽象化というのは、どこもあまり失敗しない話でしょうが、モジュールより細かい単位の抽象化というのは、初期の段階(新規に参入する分野では特に)で子細にオブジェクト(凝集度 [wikipedia.org]、ライフサイクル、拡張性など)を考慮して、理想的な形で表現するのは難しいことですし、それなら、構造化プログラミング的なアプローチで、適切に関数分割して、ライフサイクルは基本関数のスコープに合わせて書くぐらいの伝統的なやりかたの方がシンプルだと考え方もあるかなと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
適切に使用するのが難しい言語、それがC++ (スコア:1)
classとか設計に絡むものが言語仕様に取り込まれると、設計スキルが如実にコードに出る。
適切に使える人と格差が出やすいので、それでビジネスをする人にとって有利な言語かもしれない。
格差があれば、大きな利益を得られる訳だ。
C++に限らず (スコア:3, 参考になる)
一つの言語で低レベルのシステム記述から, 抽象度の高いアプリケーションまで対応させようという試みは, 古くはPL/IからAdaなど, 総じて良い結果を出したとは言えないですよね. その中ではC++はまだうまくやっている方だとは思いますが.
昔から, 銀の弾丸では無いですけど, 一つの言語で全ての用途をカバーするという欲求は強いんですが(その昔にはCOBOLで経済学的な数値解析をしたいというニーズも有ったらしい), むしろ用途に応じて数個の言語を使い分ける方が, 初期投資は大きくても最終的には幸せになれると思います.
個人的にはベースとなるCに, Lua [lua.org]の様な軽量スクリプト言語, それにPython, Rubyの様なリッチなスクリプト言語の組み合わせぐらいがバランスが取れていそうと感じますが.
Re:C++に限らず (スコア:2)
Luaなどの組み込み言語を使う用途の場合、手続き的処理を記述するのが主目的なので、
モージュール内部でカプセル化とか、ポリモーフィズムとか、オブジェクト指向言語の持つ性質は
コード中にあまり必要とされないでしょうね。
それに、組み込み言語を使うような所は、末端のエンジニアがコーディングする部分だと
思うので、言語仕様の拡張性の高さより、「必要十分なシンプルさ」といった性質の方が
メリットがありそうです。言語仕様がシンプルなら、プログラムバグの傾向も把握しやすそうです。
実のところ、カプセル化とか、ポリモーフィズムといった性質って、モジュール単位(実行プログラムやライブラリ)には既に備えている性質です。
今回はCとC++の話なので、カプセル化とか、ポリモーフィズムといった性質を
モジュールより細かいソース単位の粒度で扱いたい立場の人に対する話ですね。
なので、微妙に数個の言語の話は微妙に路線が違うかもしれません。
「あまねく関数、構造体、技術者にオブジェクトの光あれ。」と言った時、
暖かい救いのある光に感じるか、あるいは、憎しみの光に感じるか。それは経歴次第かな。
モジュール・ライブラリ単位の抽象化というのは、どこもあまり失敗しない話でしょうが、
モジュールより細かい単位の抽象化というのは、初期の段階(新規に参入する分野では特に)で子細にオブジェクト(凝集度 [wikipedia.org]、ライフサイクル、拡張性など)を考慮して、理想的な形で表現するのは難しいことですし、
それなら、構造化プログラミング的なアプローチで、適切に関数分割して、ライフサイクルは基本関数のスコープに合わせて書くぐらいの伝統的なやりかたの方がシンプルだと考え方もあるかなと思います。