OOPの時代にCがそれほど人気になった理由は何ですか？
私はCとC++の両方で多くのコーディングを行っていますが、CがJavaに少し遅れて2番目に人気のある言語になるとは思っていませんでした。
なぜこのOOPの時代に、Cはまだそれほど人気があるのか、私は興味がありますか？人気の高い5つのプログラミング言語のうち4つは、「モダン」なオブジェクト指向対応言語であることに注意してください。
さて、私はあなたがOOPをある程度使用することができることに同意しますが、それはちょっと痛くてエレガントではありません（少なくともC++と比較すると、私は推測します）。それは効率なのか、低レベルなのか、既存のライブラリの大部分、または何か他のものですか？
貢献するいくつかの要因：
- Cはユビキタスです。プラットフォームが何であれ、Cはおそらく利用可能です。
- Cはポータブルです。クリーンなCを書き、他のプラットフォームでの変更を最小限に抑えてコンパイルします-時々それはそのままで機能します。
- Cはしばらくの間存在しています。 UNIXが世界を征服した当時、C（選択されたUNIXプログラミング言語）は世界の支配を共有し、プログラミング世界のlingua francaになりました。真面目なプログラマであれば、少なくともsomeがCのチャンクの意味をなすことを期待できます。他のほとんどの言語についても同じことが言えません。
- Cは、UNIXおよびUNIXフレーバーシステムのデフォルト言語です。ライブラリをオープンソースの土地で成功させるには、かなりの理由notを使用してCを使用する必要があります。これは部分的には伝統によるものですが、Cは安全に想定できる唯一の言語であるためです。 UNIXライクなシステムでサポートされます。ライブラリをCで作成すると、依存関係を最小限に抑えることができます。
- Cは単純です。洗練されたOOPまたは関数型言語の表現力に欠けますが、そのシンプルさはそれを素早くピックアップできることを意味します。
- Cは汎用性があります。組み込みシステム、デバイスドライバー、OSカーネル、小さなコマンドラインユーティリティ、大きなデスクトップアプリケーション、DBMS、他のプログラミング言語の実装、その他ほとんどすべてに適しています。
- Cは高速です。ほとんどのCの実装は直接マシンコードにコンパイルされ、プログラマーはマシンレベルで何が起こるかについて全力を発揮します。インタープリター、JITコンパイラー、VMまたはランタイムはありません。コード、コンパイラー、リンカー、およびベアメタルのみです。
- Cは「無料」です（ビールとスピーチの両方の意味で）。標準を所有および管理している単一の会社はなく、選択できるいくつかの実装があり、Cを使用するための著作権、特許、または商標の問題はなく、最良の実装のいくつかはオープンソースです。
- Cには勢いがあります。言語は何十年も人気があったため、言語をサポートするための膨大な量のアプリケーション、ライブラリ、ツール、そして何よりもコミュニティがあります。
- Cは成熟しています。大きな変更を導入した最後の標準はC99であり、ほとんどの場合、以前の標準との下位互換性があります。新しい言語（たとえば、Python）とは異なり、すぐに変更を壊すことを心配する必要はありません。
- Cは互換性があります。ほとんどの言語には、Cと対話するためのバインディングがあります。つまり、標準の呼び出し規約を使用してCでライブラリを開発でき、他のほとんどの言語がそのライブラリにリンクできると確信できます。広く使用されているいくつかの人気のある言語に名前を付けると、C＃、Java、Perl、Python、PHPすべてのCライブラリを問題なくリンクできます。
- Cは強力です。言語が何かを実行できない場合、一般的なコンパイラはすべて、ハードウェアが実行できるすべてのことを実行できるアセンブラコードを埋め込むことができます。これは、互換性に関する上記のポイントと推移的に組み合わさることで、Cが上位言語とアセンブリの「ベアメタル」との間の連絡役として機能できることを意味します。
私はいつも、Cの人気を普遍的なアセンブリ言語の必要性のせいにする傾向があります。これは、マシンレベルでの特異性、標準化、および極度な移植性の組み合わせにより、Cがデファクトユニバーサルアセンブリ言語として機能することを可能にします。そのため、その役割は無期限に続くと思います。
OOPが一種の「最終モデル」としてプログラミングコースで提示され、優れたプログラミングの唯一の可能なエンドポイントであるとき、私は常に少し驚いていることを言及しておきます。他の多くの側面と同様にプログラミング、OOPの値は、人間の脳が情報を編成する方法、社会グループが長期にわたってソフトウェアをサポートする方法、オブジェクト指向プログラミングの場合など、多くの競合する要素の間の妥協です。宇宙自体がどのように機能するかのかなり深い側面。
そして、その最後の点は少しハンマーする価値があります。特定のプログラミングスタイルが存在する理由、それらがどのように連携するのか、そしてそのような概念をさらに発展させて将来世界がどこに向かうのかについての物理レベルの調査に興味がある場合は、さらに読んでください...
物理学におけるオブジェクトは、時間の経過とともに認識可能な一貫性を維持するものです。これにより、私たちのような単純な生き物が、生存をそれほど危険にさらすことなく、少数のビットのみを使用してオブジェクトを表現することを回避できます。しかし、物理学の観点から言えば、そのような単純化を容易かつ一般的にするために正確に理解しなければならないことの数は非常に多くなります。人間なので、率直に言って、それほど多くのことを考えていません。そうでなければ、私たちはここにいません。
抽象的すぎると思いませんか？それは本当にそうではありません。たとえば、自動車の代わりに急速に振動するプラズマ場と、非常に広範囲の速度で移動する物質の瞬間的な凝縮に遭遇した場合に、友人の家への道をナビゲートしようとしていると想像してください。そのようなシナリオは、社会化の機会をかなり深く切り込むかもしれませんね。オブジェクトが必要であり、 are オブジェクトであり、オブジェクトの存在は、周囲の環境を簡素化する非常に重要なレベルを提供します。
それでは、これらすべてをソフトウェアに戻しましょう。プログラミングの観点から、現実世界のオブジェクトはオブジェクトについて何を言わなければなりませんか？
まあ、1つには、ソフトウェアで「良い」オブジェクトを定義するのは、処理しているデータのタイプが、認識可能な永続的な永続化のアイデアをすぐにサポートできるかどうかであるということです 。
定義を使用すると、OOPの最も簡単な形式は簡単に認識できます。これらは、すでに「アタッチ」されているか、または実際の世界で定義されているデータのみを使用して、ビットを取り出します。人、家、車などの真に物理的なオブジェクトです。今日でも、これはソフトウェアコースで取得するオブジェクトの only 定義である場合が多すぎます。オブジェクト指向プログラムは、それよりも広い定義が必要です。
オブジェクトの2番目ではるかに興味深いカテゴリーは、私が不死化した実世界のイベントと呼ぶもので構成されています。 「不滅化」とは、現実に明確に定義されたエンティティまたはコレクションとして少なくとも簡単に存在するが、物理的に意味のあるコレクションとして分散し、存在しなくなることを意味します。シンポジウムは良い例です。シンポジウムは、しばらくの間、適切に定義された場所と人々の集まりとして存在します。しかし、悲しいかな、最高の会議でさえ終了しなければならず、それらを構成した個々の部分は他の活動に移ります。
しかし、コンピュータとネットワークを使用することで、その一時的なシンポジウム seem を、長期的なオブジェクトのように、そのメモリをソフトウェアオブジェクトとしてキャプチャして維持することで作成できます。私たちがコンピューターやデータベースで行うことの多くは、このような一時的なイベントの不滅化に相当します。実際には、物理的に存在できない方法でそれをキャプチャして拡張することにより、実際の宇宙をより豊かにしようとします。たとえば、最近本物のパンドラを見たことがありますか？このような現実世界の作品のキャプチャと拡張は、私たち自身の生活、経済、および選択肢を驚くほど豊かにし、拡張するのに役立ちます。私にとってこれは、オブジェクト指向プログラミングの中心であり、最も顕著な影響を与えてきた、そして与え続けてきた場所です。
OOPの最後のカテゴリは、外部イベントとの密接な関係がないオブジェクトで構成されていますが、代わりに infrastructure が現実の継続的な拡張をサポートするために必要です）現実世界の不滅のオブジェクトを使用します。これは、コンピューターの（半）金属に至るまで降りて、現実世界の化学要素のような永続的な現実の断片を作成し、すばやく興味深い方法で組み合わせることができる場所です。新しい内部の世界を構築するためにモバイルコンピューティングは、この種の高度に再結合されたアプローチの成長を促進するのに役立ちました。これは、多くの点で、物理的な世界の再結合機能を模倣しています。また、難しいです。時間の経過とともに、予期せぬ悪い状況に陥りました。これは通常、サポートするのではなく、多様性と拡大を阻止することになるためです。
この最後のカテゴリは、プログラミングに1つのモデルのみを使用するリスクも示しています。これは、現実の世界と同様に、プログラムされた世界にも比較的変化しないオブジェクトにできないのプロセスが必要なためです。地球は物体でいっぱいですが、太陽は非常に動的なエネルギーの流れでいっぱいで、最終的にはより低いエネルギーの地球で物体と活動を「駆動」するために必要です。同様に、コンピューティングワールドの作成では、フローや変換、急速に変化するコンテキストに対処する必要がある場合がありますが、それ自体は非常にオブジェクトのようではありませんが、より高いレベルで使用されるよりシンプルで人間にやさしいオブジェクトを有効にするために絶対的に重要です。 。カーネルレベルで行われるプログラミングの多くが目立ってオブジェクトのようになっていないこと、またはより処理指向のCなどの言語に大きく依存する傾向があるのは偶然ではありません。これらは、コンピューターで生成された世界で高く見られる魅力的な多様性を補完する、より深いドメインです。それらを純粋なオブジェクトモデルに強制しようとすることは、人間に優先して理解し、ナビゲートしやすくするために、数十億のきちんとした暖炉オブジェクトとして再編成する必要があることを太陽に伝えるようなものです。
OOPがうまくいかない場合があるもう1つの領域は、 old オブジェクトの概念に重点を置いています。
現実世界のオブジェクト、特に living オブジェクトは、複雑で微妙な方法で環境とやり取りする、驚くべきレベルの能力を持っています。お互いを見渡し、互換性と健全性のチェックを行い、相互作用する新しい方法を理解する合成可能なウィジェットは、単純なフレームワークや単純な継承スキームよりも、オブジェクトの実際の生物学的概念に非常に近づいています（通常は必要に応じて）コードレベルで焦点を当てます。これはサイバー世界でのオブジェクトの成長分野の1つであり、プログラミング自体の中でも環境に対する反応性が標準である、より「エージェントのような」アプローチです。
そして、OOPに対する私の「批評」はこれで終わりです。それでも、「1つだけ」で十分であると想定するのではなく、より豊かなサイバーワールドを作成することが、包括的な多様なプログラミングスタイルを意味する理由を指摘しておけば幸いです。私が今やっていることのどれほど平凡であっても、本当に面白いものはまだないというのが私の気持ちです！
まず、OOPの必要はありません。これに関する一般的な教訓が普及しているにもかかわらずです。Javaとは異なり、Cは関数ポインターと クロージャーさえ を使用してドアを開きます関数型プログラミングに移行し、問題空間のかなりの部分を解決しますOOPは、依存性注入の手段を提供するため、処理します。また、注意深いsglib が証明するように、マクロを使用すると、実際にいくつかの非常に素晴らしいものが作成されます。
奇妙な方法で、CはJavaとC++の間の適切な妥協案として見ることができます。私はではないことに注意してください Cは何らかの形で両方の組み合わせであると言っていますが、Javaとは対照的に、Cとは対照的に、扱いやすい複雑さを備えた強力な言語です。
これは古い言語であり、信頼性と一貫性が高まっていますが、実際には複雑ではありません。それを除けば、巨大なエコシステムがあり、どこでも実行できます。
CにはABI（Application Binary Interface）があり、C++にはありません。これにより、特定のインスタンスではCがC++よりも有用になります。ライブラリを作成して、他の人が使用できるようにバイナリを出荷できるようにする場合、C++はその仕事には不適切なツールです。他の言語で再び使用されるライブラリを作成する場合、Cはその仕事に適したツールです。 CへのFFI（Foreign Function interface）をサポートしていない言語を聞いたことがありませんが、異なるコンパイラーが使用されている場合、C++はC++で書かれたライブラリーでは機能しません。
基本的には、C++が適さない役割を満たすCに要約されます。
C++やJava=のような言語よりもCを使用する利点の1つは、内部ではそれほど多くの魔法が発生しないことです。アイテムが割り当てられたときにコンストラクターが実行されず、デストラクタも実行されません。オブジェクトがスコープから外れたとき。名前のマングリングやvtableはありません。パフォーマンスの予測は簡単です。ガベージコレクターがルーチンに割り込んでそのタイミングを落とすことを心配する必要はありません。
コンストラクタ、デストラクタ、名前のマングリング、vtables、ガベージコレクタなどを使用すると、作成するコードの複雑さの一部を緩和できますが、その複雑さは言語自体の一部になります制御できない部分it。ビルド時間が長くなる（煩わしいが許容できる）、ランタイムメモリフットプリントが大きくなる（許容できる場合とできない場合がある）、またはパフォーマンスが遅くなる可能性があります。 Cを使用すると、needの機能がなくなるまで、その複雑さの一部を取り除くことができます。
たとえば、C++ stringデータ型はlight-yearsはCスタイルの文字列よりも扱いが簡単ですが、かなり重いコードであり、画像に多少の重さを追加しますサイズ。誰もが1つのプログラムでstringの機能をフルに活用することはほとんどありません。 Cスタイルの文字列は、操作が難しくなりますが、実行時間と画像サイズの点でペナルティが少なく、特定の問題についてはそのためより魅力的です。
組み込みシステムとドライバーは通常Cでプログラムされます。それ以外にも、維持され、拡張されているレガシーCシステムが数多くあります。
手動ハンマーが空気圧ハンマー（エアハンマー）の時代に人気を博しているのと同じこと：Cは依然として特定の仕事に適したツールです。
シンプルさ、一貫性、精度。
シンプルです。複雑な開発環境、大規模なライブラリ、仮想マシンは必要ありません。
それは一貫しています-10年前に書かれたほとんどのCは今日コンパイルできます。
精度-必要に応じてメモリの場所を把握しながら、マシンのレベルに到達できます。これは、パフォーマンスと組み込みハードウェアに最適です。
それはすべてのためではありません、それはまだ便利なツールです。
別の回答から2つのポイントを引用します。これは、Cを時々使用する理由を正確に捉えているためです（ただし、私の主な言語は選択していません）。
- Cは単純です。洗練されたOOPまたは関数型言語）の表現力に欠けていますが、その単純さは、すぐに取り上げられることを意味します。
- Cは成熟しています。大きな変更を導入した最後の標準はC99であり、ほとんどの場合、以前の標準との下位互換性があります。新しい言語（たとえば、Python）とは異なり、すぐに変更を壊すことを心配する必要はありません。
これは本当だと思います。私はCを早い夜の間に学びました。それはシンプルで、キーワードや構成が少なく、ほとんどの作業は図書館で行われていました。その後、私は数年間Cを使用しませんでした。 2002年頃にアルゴリズムの高速実装が必要になり、Cコンパイラをインストールして実装しました。私は言語を知っています、それが何のために良いのか、何が良くないのかを知っています（私はnever CでWebアプリケーションを実装します！）、それは必要なときにそこにあります。驚く様な事じゃない。
C++では、私は別の経験をしました。私は1995年頃にそれを学び、それは命令型からOOPへの大きなパラダイム転換を意味しました。すごい！ 1999年までいくつかのプロジェクトで使用していました。数年間はC++を使用していませんでしたが、それを再び取り入れたとき（2008）、言語にはすでに多くの新機能があり、さらに計画されています（その間、C++で導入されました） 11）。もう一度言葉を覚えなくてはいけないと感じました。
私は開発者として、成熟した安定した言語を好みます。言語を一度習得し、その設計原則、それが何に役立つかを理解し、それが仕事に適したツールだと思ったときにそれを使用するのが好きです。また、さまざまな言語を学び、自分のニーズに合った言語（C、C++、Java、Scala、Haskellなど）を選ぶことも好きです。私が好きではないことは、同じ言語を何度も何度も学習する必要があることです。それは、ますます発達し、成熟することは決してないからです。
私見、プログラミング言語は、明確で一貫性のある、安定した設計でなければなりません。 Niklaus Wirthのようなデザイナーのアプローチが好きです。彼が別の言語の必要性を感じるたびに、彼は新しい言語（Pascal、Modula-2、Modula-3、Oberon）を設計しました。 5年から10年ごとに重要な変更が加えられる言語は好きではありません。それらはターゲットを移動するようなものであり、現在学習しているバージョンはおそらく数年で廃止されるため、深く学ぶために時間を費やす価値はないと思います。とにかく年。
この意味で、CはIMOの勝者です。特定のアプリケーションには適していますが、他のアプリケーションにはあまり適していませんが、シンプルで比較的安定しているという利点があります。
Worse Is Better について誰も言及していないことに驚いています。現時点で20年以上経過していますが、読む価値はまだあります。ときどきほのめかしていることもありますが、C（LISPに対抗する）を中心的な例の1つとして使用することで、便法がしばしば理想に勝つ方法と理由を概説するのに非常に役立ちます。
Cコンパイラーを使用している場合、通常はC++コンパイラーも使用しているという事実にもかかわらず、人々がC++ではなくCを使用する理由を尋ねたいと思います。
- C言語はC++よりもはるかに単純です。コーディング規約で完全なC++標準を使用している会社は知りません。例として、GoogleのC++コードスタイルを見てください。 http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
- Cはコンパイルがはるかに高速です。コンストラクトをコンパイルするのが難しいことのおかげで。
何もない。 TIOBEは価値のないインデックスです。実際にそれらの測定値を見ると、それは絶対的な推測にすぎません。
多くのレガシーソフトウェア
多くの企業は、すべてのコードを即座にC++または同様のものに変更することはできません。
多くの企業はコードを変更する余裕がありません。
多くの企業はコードを変更する余裕がありますが、気にしない、または「安い」です。
多くの企業が移行を進めていますが、まだ完了していません。
隠しオブジェクトの向き
（非オブジェクト指向）オブジェクト指向Cソースコードとして設計されたCソースコード、オブジェクト指向でモデル化され、「純粋なC」でコード化されたアプリケーション、または「C++」やその他のO.Oから変換されるツールプログラム。 Cにlangします。
一部のビデオゲームはそのように行われると聞きました。一部のクロスプラットフォームツール、およびGNome Linux O.S.用のGTK（GObject、GLibrary）ビジュアルインターフェイスライブラリ分布。
Cには巨大なユーザーベースがあるからです。はい、それは少し難題ですが、StackOverflowでCについて質問すると、ほぼ即座に答えが得られます。 Pythonについての同じ質問は、回答を得るために何時間もかかる可能性があります。
C++に関しては、学ぶのはIMOより複雑です。さらに、OOP=を10年間試した後、それが必ずしも有用であるとは限らず、手続き型プログラミングを使用する方が簡単な場合がしばしばあります。
なぜCが最も人気があるのか、長い間使用されているのか、ほとんどのプラットフォームで利用できるのか、無料であるのか、などの回答者がいるようです。
しかし、他の言語についても同じことが言えます。たとえば、無料のPascal-それは無料で、ほぼすべてのプラットフォームでサポートされています。
Pascalは1970年頃に発明され、Cは1972年頃に発明されたので、PascalはCと同じくらい長い間存在していたと思います。
個人的には、Cが最も人気のある言語だと思います。なぜなら、誰でも再利用できるオープンソースコードがもっとたくさんあるからです。はい、Pascalよりもレベルが低いため、アセンブリに近づきつつありますが、アセンブリよりもはるかに読みやすくなっています。
プログラミング言語は多すぎると思います。プログラマーとして、私たちは重要なもののほとんどを知る必要がありますが、最終的にはその必要はないはずです。 1つのプログラミング言語を実装して、ウェブサイトの構築からiOSコンピュータゲームまで、すべてを実行できます。
Cはそのグローバル言語のようですが、Object Pascalのようなものにしたいと思います。 Object Pascalがより読みやすいプログラミング言語である理由OOPコードはCよりも再利用可能で、バグが少ない（私の意見では）傾向があります。
非常に大規模なアプリケーションは、C/C++よりもObject Pascalで管理する方が簡単です。
70年代からいくつかのプログラミング言語があり、5年または10年ごとに変化する言語が好きではない。時が経つにつれ、技術が進歩し、プログラミング方法が改善されます。数年ごとに言語が劇的に変化する場合、そのデザイナーはおそらくそれをよく考えていませんでした。しかし、1970年から2012年はほぼ半世紀です。その間に言語を変更して、ソフトウェア開発で使用される進歩を組み込むことは問題ありません。
C自体は何度か改訂されています。したがって、その観点から他の言語よりも優れているわけではありません。