なぜLinuxアプリケーションは、要約で記述された言語を頻繁に使用するのですか？

アプリケーションを展示するとき、WindowsとMacはほとんど機能について話します。一方、Linuxアプリケーションには、機能ではなく、それを記述するために使用された言語（および付随するライブラリ）に関する詳細があります。何故ですか？

デスクトップ統合要件だけで違いを生むGTK +とQTの違いを知っているのは理解できましたが、C vs C ++ vs Python vs Assembly vsなど？本当に？

たとえば、fooはC / GTK +で記述された単純な何とかです。

従来のLinuxユーザー（実際に自分でシステムをインストールしたオタクの手品師）は、このような情報を気にしていると思います（このツールの背後にあるテクノロジーは何ですか？）。私は、たとえば、パッケージが好きではない技術を使用しているという理由だけで、パッケージのインストールと使用を控える、こっけいな人の1人でもあります。もちろん、この種の行動宗教と呼ぶ人もいます。馬鹿じゃない？

とにかく2つの理由が考えられます：

• パッケージャーはそれらのLinuxユーザーよりもオタクです（それ以上ではないにしても）ので、そのような情報を追加することをお勧めします。

• これらのパッケージャーがパッケージの説明にそのような情報を入れると、何らかのプロモーションとしてそれを行う可能性が高いと思います。時々動作します（私にはかなりの回数働きました）。

これは当然のことです。

私の感覚では、ソフトウェアの4つの自由のうちの2番目に関連しています。

プログラムがどのように機能するかを研究し、それを変更して希望どおりに実行する自由（自由1）。ソースコードへのアクセスは、このための前提条件です。

言語（または他の技術的特徴）を公表することは、人々が選択する能力をサポートし、それらの言語に堪能な人々によるプロジェクトへの参加を奨励します。

これは部分的に歴史的かもしれません。それほど遠くない過去でさえ、個々のシステム管理者がシステム上で実行されるすべてを構築してインストールすることは普通でした。

ツールを実装するために使用された言語とライブラリに関するメモは、そのプロセスがどれだけの作業に使用されるかについて管理者にヒントを与えます 彼らのシステム。

ユビキタスで広範囲に及ぶパッケージ管理ツールのこの時代では、これは少し時代錯誤ですが、UNIXの文化は機能していると思われるものを捨てないという意味で保守的です。

jasonwryansの答えの拡張：

書かれた言語に名前を付けると、その言語を受け取った人は、パッチを提供したり、洞察を得たり、プログラムを拡張したりするのがどれだけ難しいかを見積もることができます。

もちろん、これはあなたがプログラマーである場合にのみ意味があります。

要約はどこで見ましたか？リポジトリ内、または.debや.rpmなどのパッケージ内？

ソースからビルドする場合、その情報は、他のもの（コンパイラ、ライブラリ、ビルドツール）をインストールする必要があるかどうかを識別するのに役立つ場合があります。

Unix、そして現在はLInuxとBSDには、常に非常に破壊されたソフトウェアベースがあり、かなり最近では、はるかに多様なハードウェアベースが存在していました。一部のソフトウェアがシステム上のインタープリターで実行されていること、またはソースコードをコンパイルできることを知っておくことが重要でした。Common Lispインタープリター、Tclインタープリター、またはその他のインタープリターがない場合は、ソースをダウンロードする必要はなく、実行できないことがわかります。

どんな言語が使われていたかを説明することで、多くの時間を無駄にすることがなくなりました。

「これは何ですか？」というプロンプトが表示された場合、開発者はその機能を説明する傾向があります。誰かが説明をよりユーザー中心に書き換えてパッケージになることを願っていますが、言語に言及することは、例えば拡張性とスクリプト可能性に関連したり、貢献者を引き付ける機会に役立ちます。

私の観点からすると、そのような情報は、新しい貢献者を引き付けるために不可欠であり、また、見込みのあるユーザーに、アプリケーションをシステムに統合するためにどれだけの作業が必要かを即座に把握できます。

• 一般的な側面は、アプリケーションの実行時に使用されるライブラリです。

一部のインストールは、GTK +などの選択されたいくつかのツールキットに制限されますが、QTは制限されません。システムを保守し、そのコンポーネントを長期間にわたって定期的に更新する管理者にとって、これは単に実用的なものであり、宗教的な問題ではありません。

• 別の側面は、使用されるライブラリと、アプリケーションをコンパイルするために必要な前提条件です。

つまり、ソースベースのLinuxディストリビューションのユーザーにとって、アプリケーションがCで書かれているか、Objective-Cで書かれているかは、コンパイラーがそもそも言語をサポートする必要があるため、大きな違いになります。他の言語では、ライブラリの膨大なスタックをインストールする必要がある場合があります。ここでの質問は、このアプリケーションをコンパイルするためにどれだけの作業を受け入れてもよいかということです。

• 別の側面は、貢献者を引き付ける意図です。

ほとんどの開発者は少数の言語を好むか、他の言語の経験が不足している場合があります。より多くの人々がアプリケーションに貢献できるようにするために、一部のプロジェクトでは、ソースを2つの異なる言語に分けています（Wesnoth、Vega Strike、Naevなど）。そのうちの1つはコアアプリケーション用（CやC ++など）、もう1つは簡単に変更できる（PythonやLuaなど）。これがWesnothで行われた方法と理由を説明する「オープンソースアプリケーションのアーキテクチャ」の章へのリンクです。

• 最後に、明らかにいくつかの言語に対する偏見と偏見があります。

私は、あらゆる言語について書かれた恐ろしく非効率なソフトウェアを見たことがあると言います。あなたが私に尋ねると、効率のために、アプリケーションのコード品質は、それが書かれている言語よりもはるかに重要です。

その多くはパフォーマンス広告に関係していると思います。コンパイルされた言語（C、C ++など）で記述されたアプリケーションは、スクリプト言語（perl、pythonなど）で記述されたアプリケーションよりもはるかに優れたパフォーマンスを発揮します。

しかし、それは互換性にも関係しています。スクリプト言語で記述されたアプリケーションは、ほとんど変更を加えずに、アーキテクチャおよびOS間でより移植性が高い可能性があります。

現在のデスクトップ/サーバーシステムではそれほど重要ではないかもしれませんが、組み込みシステムからSSDネットブックやタブレットに至るまでの小規模なシステムでは、プログラムで使用される言語またはライブラリは、サイズと移植性に関する考慮事項。

サイズに関して：追加の言語用のインタープリターをすべての標準モジュールおよび通常使用されるアドオンモジュールと共に追加すると、ストレージ要件に数百メガバイトを簡単に追加できます。ライブラリファミリ、特にGnomeやKDEなどの主要なデスクトップ環境に関連するライブラリファミリについても同様です。さらに悪いことに、多くのメモリを共有できるので、実行nからn+1Perlプログラムに移行してもメモリ使用要件はそれほど増えないかもしれませんが、nPerlプログラムと0 PythonプログラムからnPerlプログラムと1つのPythonプログラムにより、メモリ使用量が大幅に増加します。これは、フリーソフトウェアを記述するすべての愚か者が、自分がプログラミングしたい独自のお気に入りのスクリプト/ radtool言語を持っている場合、さらに問題になります... Perl、Python、PHP、Ruby、JavaScript、Bourne shell、Bash、Csh、...

移植性について：多くのインタプリタ言語（およびライブラリフレームワーク）は、大きなLinuxデスクトップ/サーバーシステムで利用できるが、小規模/組み込み/ MMUのないシステムでは必ずしも利用できない機能を多用しています。.so実行時の動的モジュール読み込みへの依存が頭に浮かぶ...