Dlaczego aplikacje Linux często umieszczają język, w którym został napisany, w podsumowaniu?

Podczas prezentowania aplikacji Windows i Mac najczęściej mówią o funkcjach. Z drugiej strony aplikacje Linux mają więcej szczegółów na temat tego, w jakim języku został napisany (i towarzyszących bibliotek), a nie na temat funkcji. Dlaczego?

Zrozumiałem, znając różnicę między GTK + a QT, robiąc różnicę tylko ze względu na wymagania dotyczące integracji pulpitu, ale C vs C ++ vs Python vs Assembly vs. itd.? Naprawdę?

Na przykład: foo to prosta bla bla napisana w C / GTK +.

Myślę, że tradycyjny użytkownik Linuksa (maniak komputerowy, który sam zainstalował system) dba o takie informacje (jaka technologia kryje się za tym narzędziem?). Jestem także jednym z tych dziwacznych facetów, którzy na przykład powstrzymaliby się od instalowania i używania pakietu tylko dlatego, że używa on technologii, której nie lubię. Niektórzy nazywają to zachowanie oczywiście religią. Głupie, prawda?

W każdym razie mogę wymyślić dwa powody:

• Programy pakujące są tak samo maniakalne (jeśli nie więcej) niż ci użytkownicy Linuksa, więc uznali, że dobrym pomysłem jest dodanie takich informacji.

• Myślę, że kiedy ci pakujący umieszczają takie informacje w opisach swoich paczek, prawdopodobnie robią to jako formę promocji. Czasami działa (działało na mnie całkiem sporo razy).

To tylko przypuszczenie.

Mam wrażenie, że odnosi się to do drugiej z czterech swobód oprogramowania :

Swoboda studiowania działania programu i zmieniania go, aby działał tak, jak chcesz (wolność 1). Dostęp do kodu źródłowego jest warunkiem tego.

Publikowanie języka (lub innych funkcji technicznych) wspiera zdolność ludzi do wyboru i zachęca do udziału w projektach osób biegle posługujących się tymi językami.

To może być częściowo historyczne. Nawet w nie tak odległej przeszłości indywidualni administratorzy systemów zwykle budowali i instalowali wszystko, co działało w ich systemie.

Uwagi na temat tego, co język i biblioteki zostały wykorzystane do wdrożenia narzędzia dać wskazówkę do administratora o tym, jak dużo pracy, że proces będzie dla ich systemu.

W dobie wszechobecnych i dalekosiężnych narzędzi do zarządzania pakietami jest to trochę anachronizm, ale kultura unixowa jest konserwatywna w tym sensie, że nie wyrzuca rzeczy, które wydają się działać, więc minie trochę czasu, zanim nawyk zniknie.

W uzupełnieniu do odpowiedzi Jasonwryans :

Jeśli podasz język, w którym został napisany, osoba, która go otrzyma, może oszacować, jak trudno będzie dostarczyć łatkę, uzyskać wgląd lub rozszerzyć program.

Oczywiście ma to sens tylko wtedy, gdy jesteś programistą.

Gdzie widziałeś podsumowania? W repozytorium lub w pakiecie takim jak .deb lub .rpm?

Jeśli zbudujesz go ze źródła, informacje mogą być pomocne w określeniu, czy musisz zainstalować inne rzeczy (kompilator, biblioteki, narzędzia do budowania).

Unix, a teraz LInux i BSD, zawsze miały naprawdę złamaną bazę programową, a znacznie bardziej zróżnicowana baza sprzętowa istniała w dość niedawnej przeszłości. Ważne było, aby wiedzieć, że niektóre programy działały w interpretatorach posiadanych w systemie lub że można skompilować kod źródłowy. Jeśli nie masz tłumacza Common Lisp, tłumacza Tcl lub innego tłumacza, nie chciałeś zawracać sobie głowy pobieraniem źródła, tylko po to, aby dowiedzieć się, że nie możesz go uruchomić.

Posiadanie opisu, w jakim języku było coś, zapobiegło marnowaniu czasu.

Po wyświetleniu monitu „co to jest?” Programista będzie miał tendencję do opisywania swojej natury, która jest związana z kodem źródłowym, a nie funkcją. Miejmy nadzieję, że ktoś przepisze opis, aby był bardziej zorientowany na użytkownika, zanim trafi do pakietu, ale wspomnienie o języku może być nadal istotne, na przykład w zakresie rozszerzalności i skryptowalności, lub przydatne w celu przyciągnięcia autorów.

Z mojego punktu widzenia takie informacje są niezbędne, aby przyciągnąć nowych autorów, a także dać potencjalnym użytkownikom natychmiastowe wyobrażenie o tym, ile pracy może wymagać zintegrowanie aplikacji z ich systemem.

• Ogólnym aspektem są biblioteki używane podczas uruchamiania aplikacji.

Niektóre instalacje są ograniczone do kilku wybranych zestawów narzędzi, takich jak GTK +, ale nie QT, i odwrotnie. Dla administratora, który utrzymuje system i regularnie aktualizuje jego komponenty przez długi czas, może to być wyłącznie kwestia praktyczna, a nie religijna.

• Kolejnym aspektem są używane biblioteki i wymagania wstępne niezbędne do skompilowania aplikacji.

To znaczy dla użytkowników źródłowej dystrybucji Linuksa robi to dużą różnicę, czy aplikacja jest napisana w C, czy w Objective-C, ponieważ ich kompilator musi przede wszystkim obsługiwać język. Inne języki mogą wymagać zainstalowania ogromnego stosu bibliotek. Pytanie zatem brzmi, ile pracy jesteś gotów podjąć, aby skompilować tę aplikację.

• Innym aspektem jest chęć przyciągnięcia autorów.

Większość programistów preferuje niewielką liczbę języków lub może po prostu brakować doświadczenia w innych. Aby umożliwić większej liczbie osób współtworzenie aplikacji, niektóre projekty nawet podzieliły swoje źródła na dwa różne języki (np. Wesnoth, Vega Strike, Naev, żeby wymienić tylko kilka). Jeden z nich do podstawowej aplikacji (jak C lub C ++), drugi do łatwej modyfikacji (jak Python lub Lua). Oto link do rozdziału „Architektura aplikacji Open Source”, który opisuje, w jaki sposób i dlaczego zostało to zrobione w Wesnoth.

• Wreszcie, istnieje oczywiście wiele stronniczości i uprzedzeń wobec niektórych języków.

Powiem tylko, że widziałem okropnie nieefektywne oprogramowanie napisane w dowolnym języku. Jeśli pytasz mnie o wydajność, jakość kodu aplikacji jest znacznie ważniejsza niż język, w którym jest napisana.

Myślę, że wiele z tego ma związek z reklamą wydajności. Aplikacja napisana w skompilowanym języku (C, C ++, ...) będzie działała o wiele lepiej niż aplikacja napisana w języku skryptowym (perl, python, ...).

Ale wiąże się również z kompatybilnością. Aplikacja napisana w języku skryptowym może być również bardziej przenośna w różnych architekturach i systemach operacyjnych, z niewielkimi modyfikacjami lub bez modyfikacji.

W dzisiejszych systemach komputerowych / serwerowych może to nie być tak istotne, ale w przypadku mniejszych systemów, od systemów wbudowanych po netbooki i tablety SSD, języki lub biblioteki używane przez program mogą być problemem, zarówno ze względu na rozmiar, jak i względy przenośności.

Jeśli chodzi o rozmiar: dodanie interpretera dla dodatkowego języka, wraz ze wszystkimi standardowymi modułami i zwykle używanymi modułami dodatkowymi, może łatwo dodać setki megabajtów do wymagań dotyczących pamięci. To samo dotyczy rodzin bibliotek, szczególnie tych związanych z głównymi środowiskami graficznymi, takimi jak Gnome i KDE. Co gorsza, przejście od uruchamiania programów ndo n+1Perla może nie zwiększyć wymagań dotyczących wykorzystania pamięci, ponieważ wiele pamięci może być współdzielonych, ale przejście z nprogramów Perla i 0 programów Python donProgramy Perl i 1 program Python powodują znaczny wzrost zużycia pamięci. Staje się to jeszcze bardziej problematyczne, gdy każdy głupiec piszący wolne oprogramowanie ma swój ulubiony język skryptowy / radtool, w którym chce programować ... Perl, Python, PHP, Ruby, JavaScript, powłoka Bourne'a, Bash, Csh, ...

Jeśli chodzi o przenośność: wiele interpretowanych języków (a także frameworków bibliotecznych) intensywnie wykorzystuje funkcje, które mogą być dostępne w dużych systemach Linux / desktop, ale niekoniecznie dostępne w mniejszych / osadzonych / MMU systemach. .soPrzychodzi na myśl zależność od dynamicznego ładowania modułu w czasie wykonywania ...