Почему приложения Linux часто помещают язык, на котором они написаны, в резюме?

При демонстрации приложений Windows и Mac в основном говорят о функциях. Приложения Linux, с другой стороны, содержат больше подробностей о том, какой язык использовался для его написания (и сопутствующие библиотеки), а не о возможностях. Это почему?

Я мог бы понять, зная разницу между GTK + и QT, что делает разницу только из-за требований к интеграции с рабочим столом, но C против C ++ против Python против Assembly против сборок и т. Д.? В самом деле?

Например: foo - это простой бла-бла, написанный на C / GTK +.

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

В любом случае я могу думать о двух причинах:

• Упаковщики такие же отвратительные (если не больше), как и те пользователи Linux, поэтому они посчитали хорошей идеей добавить такую ​​информацию.

• Я думаю, что когда эти упаковщики помещают такую ​​информацию в свои описания пакетов, они, скорее всего, делают это как некоторую форму продвижения. Это работает время от времени (это работало на меня довольно много раз).

Это всего лишь предположение, конечно.

Я чувствую, что это относится ко второй из четырех свобод программного обеспечения :

Свобода изучать, как работает программа, и изменять ее, чтобы она делала то, что вы хотите (свобода 1). Доступ к исходному коду является предварительным условием для этого.

Публикация языка (или других технических особенностей) поддерживает способность людей выбирать и поощряет участие в проектах людей, владеющих этими языками.

Это может быть частично историческим. Даже в недалеком прошлом отдельные системные администраторы обычно собирали и устанавливали все, что работало в их системе.

Замечания о том, какой язык и библиотеки использовались для реализации инструмента, дают подсказку администратору о том, сколько работы этот процесс будет выполнять для их системы.

В наш век повсеместных и далеко идущих инструментов управления пакетами это немного анахронизм, но культура Unix консервативна в том смысле, что не выбрасывает вещи, которые, кажется, работают, поэтому пройдет некоторое время, прежде чем привычка умрет.

В продолжение ответа Джейсонвриана :

Если вы назовете язык, на котором он написан, человек, который его получит, сможет оценить, насколько сложно будет предоставить патч, или получить некоторое представление, или расширить программу.

Конечно, это имеет смысл, только если вы программист.

Где вы видели резюме? В репозитории или в пакете типа .deb или .rpm?

Если вы собираете его из исходного кода, информация может быть полезна для определения того, нужно ли устанавливать другие вещи (компилятор, библиотеки, инструменты сборки).

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

Наличие описания того, на каком языке что-то было, предотвратило много потерянного времени.

При появлении запроса «что это такое?» Разработчик будет стремиться описать его природу, которая для них связана с исходным кодом, а не его функцию. Надеемся, что кто-то перепишет описание, чтобы оно было более ориентированным на пользователя, прежде чем оно окажется в пакете, но упоминание языка все еще может быть актуально, например, для расширяемости и написания сценариев, или полезно для возможности привлечения участников.

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

• Общий аспект - это библиотеки, используемые при запуске приложения.

Некоторые установки ограничены несколькими выбранными наборами инструментов, такими как GTK +, но не QT, или наоборот. Для администратора, который обслуживает систему и регулярно обновляет ее компоненты в течение длительного периода времени, это может быть исключительно практическим, а не религиозным вопросом.

• Другой аспект - это используемые библиотеки и необходимые условия для компиляции приложения.

Т.е. для пользователей исходного дистрибутива Linux очень важно, написано ли приложение на C или в Objective-C, потому что их компилятор должен поддерживать язык в первую очередь. Другие языки могут потребовать установки огромного стека библиотек. Тогда снова возникает вопрос, сколько работы вы готовы принять для составления этого приложения.

• Другим аспектом является намерение привлечь участников.

Большинство разработчиков предпочитают небольшое количество языков или могут просто не иметь опыта работы с другими. Чтобы позволить большему количеству людей внести свой вклад в приложение, некоторые проекты даже делят свои источники на два разных языка (например, Wesnoth, Vega Strike, Naev, только некоторые из них). Один из них для основного приложения (например, C или C ++), другой для легкой модификации (например, Python или Lua). Вот ссылка на главу «Архитектура приложений с открытым исходным кодом», которая описывает, как и почему это было сделано в Wesnoth.

• Наконец, очевидно, что есть много предубеждений и предубеждений по отношению к некоторым языкам.

Я просто скажу, что я видел ужасно неэффективное программное обеспечение, написанное на любом языке. Если вы спросите меня, для эффективности, качество кода приложения гораздо важнее, чем язык, на котором оно написано.

Я думаю, что многое из этого связано с рекламой производительности. Приложение, написанное на скомпилированном языке (C, C ++, ...), будет работать намного лучше, чем приложение, написанное на языке сценариев (perl, python, ...).

Но это также связано с совместимостью. Приложение, написанное на языке сценариев, также, вероятно, будет более переносимым между архитектурами и ОС практически без изменений.

В современных настольных / серверных системах это может быть не так актуально, но для небольших систем - от встроенных систем до нетбуков и планшетов с твердотельным накопителем - языки или библиотеки, используемые в программе, могут быть проблемой, как из-за размера, так и из-за соображения переносимости.

Что касается размера: добавление переводчика для дополнительного языка вместе со всеми стандартными модулями и обычно используемыми дополнительными модулями может легко добавить сотни мегабайт к требованиям к хранилищу. То же самое касается библиотечных семейств, особенно тех, которые связаны с основными средами рабочего стола, такими как Gnome и KDE. Что еще хуже, переход от запуска nк n+1программам на Perl может не так уж сильно увеличить требования к использованию памяти, поскольку большая часть памяти может быть распределена, но переход от nпрограмм на Perl и 0 к программам на PythonnПрограммы на Perl и 1 программа на Python значительно увеличивают использование памяти. Это становится еще более серьезной проблемой, когда у каждого дурака, пишущего бесплатное программное обеспечение, есть свой любимый язык сценариев / языка программирования, на котором они хотят программировать ... Perl, Python, PHP, Ruby, JavaScript, оболочка Bourne, Bash, Csh, ....

Относительно переносимости. Многие интерпретируемые языки (а также библиотечные среды) интенсивно используют функции, которые могут быть доступны в больших системах Linux на настольных компьютерах и серверах, но не обязательно доступны в небольших / встроенных / без MMU-системах. На .soум приходит зависимость от динамической загрузки модуля во время выполнения ...