Warum geben Linux-Anwendungen in der Zusammenfassung häufig die Sprache an, in der sie geschrieben wurden?

Bei der Präsentation von Anwendungen sprechen Windows und Mac hauptsächlich über Funktionen. Auf der anderen Seite enthalten Linux-Anwendungen mehr Details zu der Sprache, in der sie geschrieben wurden (und den zugehörigen Bibliotheken), als Features. Warum das?

Ich könnte verstehen, dass der Unterschied zwischen GTK + und QT nur aufgrund der Desktop-Integrationsanforderungen einen Unterschied ausmacht, aber C vs C ++ vs Python vs Assembly vs usw.? "Ja wirklich?"

Zum Beispiel: foo ist ein einfaches bla bla, geschrieben in C / GTK +.

Ich denke, der traditionelle Linux-Benutzer (ein geeky Bastler, der das System selbst installiert hat) kümmert sich um solche Informationen (welche Technologie steckt hinter diesem Tool?). Ich gehöre auch zu den Geeky, die zum Beispiel davon absehen würden, ein Paket zu installieren und zu verwenden, nur weil es eine Technologie verwendet, die ich nicht mag. Manche nennen diese Art von Verhalten natürlich Religion. Blöd, nicht wahr?

Trotzdem kann ich mir zwei Gründe vorstellen:

• Die Packager sind ebenso geeky (wenn nicht sogar mehr) als diese Linux-Benutzer, daher fanden sie es eine gute Idee, solche Informationen hinzuzufügen.

• Ich denke, wenn diese Paketanbieter solche Informationen in ihre Paketbeschreibungen aufnehmen, tun sie dies wahrscheinlich als eine Form der Werbung. Es funktioniert manchmal (es hat ziemlich oft bei mir funktioniert).

Dies ist natürlich nur eine Vermutung.

Meiner Meinung nach bezieht es sich auf die zweite der vier Software-Freiheiten :

Die Freiheit, die Funktionsweise des Programms zu studieren und es so zu ändern, dass es das tut, was Sie möchten (Freiheit 1). Voraussetzung hierfür ist der Zugriff auf den Quellcode.

Die Veröffentlichung der Sprache (oder anderer technischer Merkmale) unterstützt die Auswahlmöglichkeiten der Menschen und fördert die Teilnahme an Projekten durch Personen, die diese Sprachen beherrschen.

Dies kann teilweise historisch sein. Selbst in nicht allzu ferner Vergangenheit war es üblich, dass einzelne Systemadministratoren alles erstellten und installierten, was auf ihrem System lief.

Hinweise zu den Sprachen und Bibliotheken, mit denen ein Tool implementiert wurde, geben dem Administrator einen Hinweis darauf, wie viel Arbeit dieser Prozess für sein System bedeuten wird.

In einer Zeit allgegenwärtiger und weitreichender Paketverwaltungstools ist dies ein gewisser Anachronismus, aber Unix-Kultur ist konservativ in dem Sinne, dass Dinge, die funktionieren, nicht verworfen werden, sodass es eine Weile dauern wird, bis die Gewohnheit vergeht.

In Erweiterung der Antwort von jasonwryans :

Wenn Sie die Sprache angeben, in der es geschrieben wurde, kann die Person, die es erhält, abschätzen, wie schwierig es sein wird, einen Patch bereitzustellen, einige Einblicke zu erhalten oder das Programm zu erweitern.

Das macht natürlich nur Sinn, wenn Sie Programmierer sind.

Wo hast du die Zusammenfassungen gesehen? In einem Repository oder einem Paket wie .deb oder .rpm?

Wenn Sie es aus dem Quellcode erstellen, können die Informationen hilfreich sein, um festzustellen, ob Sie andere Komponenten (Compiler, Bibliotheken, Build-Tools) installieren müssen.

Unix, und jetzt LInux und die BSDs, hatten schon immer eine wirklich zerbrochene Softwarebasis, und in der jüngeren Vergangenheit gab es eine weitaus vielfältigere Hardwarebasis. Es war wichtig zu wissen, dass auf Ihrem System Software für die Interpreter installiert ist oder dass Sie den Quellcode kompilieren können. Wenn Sie keinen Common-Lisp-Interpreter oder Tcl-Interpreter oder einen beliebigen Interpreter haben, wollten Sie sich nicht die Mühe machen, den Quellcode herunterzuladen, nur um herauszufinden, dass Sie ihn nicht ausführen konnten.

Eine Beschreibung der Sprache, in der sich etwas befand, verhinderte viel Zeitverschwendung.

Wenn ein Entwickler gefragt wird, was ist das ?, beschreibt er in der Regel seine Natur, die für ihn eher an den Quellcode gebunden ist, als an seine Funktion. Es ist zu hoffen, dass jemand die Beschreibung umschreibt, um sie benutzerorientierter zu gestalten, bevor sie auf einem Paket landet. Die Erwähnung der Sprache kann jedoch weiterhin relevant sein, beispielsweise für die Erweiterbarkeit und Skriptfähigkeit oder für die Gelegenheit, Mitwirkende zu gewinnen.

Aus meiner Sicht sind solche Informationen unerlässlich, um neue Mitarbeiter zu gewinnen und potenziellen Benutzern eine sofortige Vorstellung davon zu geben, wie viel Arbeit es bedeuten könnte, die Anwendung in ihr System zu integrieren.

• Ein allgemeiner Aspekt sind die Bibliotheken, die beim Ausführen der Anwendung verwendet werden.

Einige Installationen sind auf einige ausgewählte Toolkits beschränkt, z. B. GTK +, jedoch nicht QT oder umgekehrt. Für einen Administrator, der ein System wartet und seine Komponenten über einen langen Zeitraum regelmäßig aktualisiert, ist dies möglicherweise nur eine praktische und keine religiöse Frage.

• Ein weiterer Aspekt sind die verwendeten Bibliotheken und Voraussetzungen, die zum Kompilieren der Anwendung erforderlich sind .

Dh für Benutzer einer quellbasierten Linux-Distribution macht es einen großen Unterschied, ob eine Anwendung in C oder in Objective-C geschrieben ist, da ihr Compiler die Sprache in erster Linie unterstützen muss. In anderen Sprachen muss möglicherweise ein großer Stapel von Bibliotheken installiert werden. Die Frage ist dann wiederum, wie viel Arbeit Sie bereit sind, um diese Anwendung zu kompilieren.

• Ein anderer Aspekt ist die Absicht, Mitwirkende anzuziehen.

Die meisten Entwickler bevorzugen eine kleine Anzahl von Sprachen oder haben einfach keine Erfahrung in anderen Sprachen. Damit eine größere Anzahl von Personen zu einer Bewerbung beitragen kann, teilen einige Projekte ihre Quellen sogar in zwei verschiedene Sprachen auf (wie Wesnoth, Vega Strike, Naev, um nur einige zu nennen). Eine davon für die Kernanwendung (wie C oder C ++), die andere für die einfache Modifikation (wie Python oder Lua). Hier ist ein Link zu einem Kapitel in "Die Architektur von Open Source-Anwendungen", das beschreibt, wie und warum dies in Wesnoth geschehen ist.

• Schließlich gibt es offensichtlich eine Menge Befangenheit und Vorurteile gegenüber einigen Sprachen.

Ich sage nur, dass ich schrecklich ineffiziente Software gesehen habe, die in einer beliebigen Sprache geschrieben wurde. Wenn Sie mich aus Gründen der Effizienz fragen, ist die Codequalität der Anwendung viel wichtiger als die Sprache, in der sie geschrieben ist.

Ich denke, vieles hat mit Performance-Werbung zu tun. Eine Anwendung, die in einer kompilierten Sprache (C, C ++, ...) geschrieben ist, wird eine Menge besser abschneiden als eine Anwendung, die in einer Skriptsprache (Perl, Python, ...) geschrieben ist.

Es hängt aber auch mit der Kompatibilität zusammen. Eine in einer Skriptsprache geschriebene Anwendung ist wahrscheinlich auch für Architekturen und Betriebssysteme portabler, ohne dass Änderungen erforderlich sind.

Auf heutigen Desktop- / Serversystemen mag dies nicht so relevant sein, aber für kleinere Systeme, die von eingebetteten Systemen bis zu SSD-Netbooks und -Tablets reichen, können die von einem Programm verwendeten Sprachen oder Bibliotheken sowohl aufgrund der Größe als auch aufgrund der Größe ein Problem darstellen Überlegungen zur Portabilität.

In Bezug auf die Größe: Durch Hinzufügen eines Interpreters für eine zusätzliche Sprache sowie aller Standardmodule und häufig verwendeten Zusatzmodule können Speicheranforderungen problemlos um Hunderte von Megabyte erweitert werden. Gleiches gilt für Bibliotheksfamilien, insbesondere für diejenigen, die mit wichtigen Desktop-Umgebungen wie Gnome und KDE in Verbindung stehen. Was noch schlimmer ist: Wenn Sie nicht nmit n+1Perl-Programmen arbeiten, erhöht sich der Speicherbedarf möglicherweise nicht so stark, da viel Speicher gemeinsam genutzt werden kann. Wenn Sie jedoch mit , steigt der Speicherbedarfn Perl-Programmen und 0 Python-Programmen aufnPerl-Programme und 1 Python-Programm führen zu einem erheblichen Anstieg der Speichernutzung. Dies wird noch problematischer, wenn jeder Narr, der freie Software schreibt, seine eigene bevorzugte Skript- / Radtool-Sprache hat, in der er programmieren möchte ... Perl, Python, PHP, Ruby, JavaScript, Bourne-Shell, Bash, Csh, ....

Portabilität: Viele interpretierte Sprachen (sowie Bibliotheks-Frameworks) nutzen häufig Funktionen, die auf großen Linux-Desktop- / Serversystemen verfügbar sind, jedoch nicht unbedingt auf kleineren / eingebetteten / MMU-freien Systemen. Die Abhängigkeit vom dynamischen .soLaden von Modulen zur Laufzeit wird deutlich ...