Чому програми Linux часто резюмують мову, на якій було написано?

Під час демонстрації програм Windows та Mac в основному говорять про функції. З іншого боку, додатки Linux мають більше деталей про те, якою мовою для його написання (та супровідними бібліотеками) користувалися, а не про функції. Чому так?

Я міг би зрозуміти, знаючи різницю між GTK + та QT, змінившись лише через вимоги до інтеграції на робочому столі, але C vs C ++ проти Python vs Assembly vs тощо? Дійсно?

Наприклад: foo - простий бла-бла, написаний на C / GTK +.

Я думаю, що традиційний користувач Linux (примхливий майстер, який фактично встановив систему самостійно) дбає про таку інформацію (яка технологія стоїть за цим інструментом?). Я також один з тих причудливих хлопців, які, наприклад, утримаються від встановлення та використання пакету тільки тому, що він використовує певну технологію, яка мені не подобається. Деякі називають таку релігію поведінки звичайно. Нерозумно, чи не так?

У будь-якому випадку я можу придумати дві причини:

• Пакувальники такі ж прихильні (якщо не більше), ніж ті користувачі Linux, тому вони вважають гарною ідеєю додати таку інформацію.

• Я думаю, коли ці пакувальники розміщують таку інформацію у своїх описах пакунків, вони, ймовірно, роблять це як певна форма просування. Це працює часом (на мене працювало досить багато разів).

Це, звичайно, лише здогадка.

Я розумію, що це стосується другої з чотирьох свобод програмного забезпечення :

Свобода вивчати, як працює програма, і змінювати її, щоб вона зробила те, що ти бажаєш (свобода 1). Доступ до вихідного коду є необхідною умовою цього.

Оприлюднення мови (або інших технічних особливостей) підтримує здатність людей вибирати та заохочує участь у проектах людей, які володіють цими мовами.

Це може бути частково історичним. Навіть у не такому далекому минулому окремі системні адміністратори звично створювали та встановлювали все, що працювало на їхній системі.

Примітки про те, якою мовою та бібліотеками використовувались для впровадження інструменту, підказують адміністратору про те, яка робота над цим процесом буде працювати їх систему.

У цю епоху всюдисущих та далекосяжних інструментів управління пакунками це є трохи анахронізмом, але культура Unix є консервативною у сенсі не викидати речі, які, здається, працюють, тому пройде деякий час, перш ніж звичка вмирає.

На додаток до додаток до відповіді язонврійців :

Якщо ви назвете мову, якою вона написана, людина, яка її отримує, може оцінити, наскільки важко буде надати виправлення, або отримати деяку інформацію, або розширити програму.

Звичайно, це має сенс лише якщо ви програміст.

Де ви побачили підсумки? У сховищі або в пакеті на зразок .deb чи .rpm?

Якщо ви будуєте його з джерела, інформація може бути корисною для визначення того, чи потрібно вам встановлювати інші речі (компілятор, бібліотеки, інструменти для збирання).

У Unix, а тепер LInux і BSD, завжди була по-справжньому розбита база програмного забезпечення, а в досить недавньому минулому існувала набагато різноманітніша база обладнання. Важливо було знати, що деяке програмне забезпечення працювало в інтеграторах, які у вас були у вашій системі, або що ви можете скласти вихідний код. Якщо у вас немає спільного перекладача Lisp або інтерпретатора Tcl або будь-якого іншого перекладача, ви не хочете заважати завантажувати джерело, лише щоб дізнатися, що не можете його запустити.

Опис опису того, якою мовою було щось, заважало витрачати багато часу.

Коли буде запропоновано "що це за річ?", Розробник буде схильний описувати його природу, яка для них прив'язана до вихідного коду, а не до його функції. Хтось сподівається переписати опис, щоб бути більш орієнтованим на користувачів, перш ніж він опиниться на пакеті, але згадка про мову все ще може бути актуальною, наприклад, щодо розширюваності та написання, або корисною для можливості залучення дописувачів.

З моєї точки зору, така інформація є важливою для залучення нових учасників, а також надання потенційним користувачам негайного уявлення про те, скільки роботи може спричинити інтеграція програми у свою систему.

• Загальний аспект - це бібліотеки, які використовуються під час запуску програми.

Деякі установки обмежені кількома вибраними наборами інструментів, наприклад, GTK +, але не QT, або навпаки. Для адміністратора, який підтримує систему і регулярно оновлює її компоненти протягом тривалого періоду часу, це може бути виключно практичним, а не релігійним питанням.

• Інший аспект - це використовувані бібліотеки та необхідні умови для складання програми.

Тобто для користувачів джерельного дистрибутиву Linux, це має велике значення, чи програма написана на C, або в Objective-C, оскільки їх компілятору потрібно підтримувати мову в першу чергу. Інші мови можуть змусити встановити величезний стек бібліотек. Знову ж таки, питання, скільки роботи ви готові прийняти, щоб скласти цю заявку.

• Інший аспект - це намір залучати дописувачів.

Більшість розробників надають перевагу невеликій кількості мов або можуть просто бракувати досвіду в інших. Щоб дозволити більшої кількості людей зробити свій внесок у додаток, деякі проекти навіть розділили свої джерела на дві різні мови (наприклад, Wesnoth, Vega Strike, Naev, лише декілька). Один з них для основної програми (наприклад, C або C ++), інший для легкої модифікації (наприклад, Python або Lua). Ось посилання на розділ "Архітектура програм з відкритим кодом", який описує, як і чому це було зроблено у Wesnoth.

• Нарешті, очевидно, що існує багато упередженості та забобонів щодо деяких мов.

Я просто скажу, що я бачив жахливо неефективне програмне забезпечення, написане будь-якою мовою. Якщо ви запитаєте мене, для ефективності якість коду програми набагато важливіша, ніж мова, на якій написано.

Я думаю, що багато чого має стосунок до рекламної діяльності. Додаток, написаний на компільованій мові (C, C ++, ...), виконуватиме хек набагато краще, ніж один, написаний мовою скрипту (perl, python, ...).

Але це також пов'язано з сумісністю. Додаток, написаний на мові сценаріїв, також, ймовірно, буде більш портативним для архітектур та ОС, не змінюючи жодних змін.

У сучасних настільних / серверних системах це може бути не так актуально, але для менших систем, починаючи від вбудованих систем до нетбуків та планшетів SSD, мови чи бібліотеки, які використовує програма, можуть бути проблемою, що стосується виправлення або перерви, як через розмір, так і міркування щодо переносимості.

Щодо розміру: Додавання інтерпретатора для додаткової мови разом із усіма стандартними модулями та типово використовуваними модулями доповнення може легко додати сотні мегабайт до вимог зберігання. Те саме стосується бібліотечних сімей, особливо тих, які пов'язані з основними середовищами настільних ПК, такими як Gnome та KDE. Що ще гірше: перехід від запуску nдо n+1програм Perl може не додати стільки вимог до використання пам'яті, оскільки багато пам'яті можна спільно використовувати, але переходячи від nпрограм Perl та 0 програм Python доnПрограми Perl та 1 програма Python призводять до значного сплеску використання пам'яті. Це стає ще більшою проблемою, коли кожен дурень, що пише вільне програмне забезпечення, має власну улюблену мову скрипта / радоула, яку він хоче програмувати ... Perl, Python, PHP, Ruby, JavaScript, оболонка Bourne, Bash, Csh, ....

Щодо переносимості: Багато інтерпретованих мов (як і бібліотечні рамки) активно використовують функції, які можуть бути доступні у великих настільних / серверних системах Linux, але необов'язково доступні для менших / вбудованих / MMU без систем. .soПриходить на думку залежність від динамічного завантаження модуля під час виконання ...