¿Por qué las aplicaciones de Linux a menudo ponen el idioma con el que fue escrito en el resumen?

Cuando se muestran aplicaciones, Windows y Mac hablan principalmente de características. Las aplicaciones de Linux, por otro lado, tienen más detalles sobre qué lenguaje se usó para escribirlo (y las bibliotecas que lo acompañan) en lugar de las características. ¿Porqué es eso?

¿Podría entender saber la diferencia entre GTK + versus QT que hace la diferencia solo por los requisitos de integración de escritorio, pero C vs C ++ vs Python vs Assembly vs etc.? De Verdad?

Por ejemplo: foo es un bla bla simple escrito en C / GTK +.

Creo que el usuario tradicional de Linux (un ingeniero friki que realmente instaló el sistema por sí mismo) se preocupa por dicha información (¿qué tecnología hay detrás de esta herramienta?). También soy uno de esos tipos geek que, por ejemplo, se abstendrían de instalar y usar un paquete solo porque usa alguna tecnología que no me gusta. Algunos llaman a este tipo de comportamiento religión, por supuesto. ¿No es tonto?

De todos modos, puedo pensar en dos razones:

• Los empaquetadores son tan geeky (si no más) que esos usuarios de Linux también, por lo que les pareció una buena idea agregar dicha información.

• Creo que cuando estos empaquetadores ponen esa información en las descripciones de sus paquetes, es probable que lo hagan como una forma de promoción. Funciona a veces (me funcionó varias veces).

Esto es solo una suposición, por supuesto.

Mi sentido es que se relaciona con la segunda de las cuatro libertades de software :

La libertad de estudiar cómo funciona el programa y cambiarlo para que haga lo que desea (libertad 1). El acceso al código fuente es una condición previa para esto.

La publicidad del idioma (u otras características técnicas) respalda la capacidad de las personas para elegir y fomenta la participación en proyectos de personas que dominan esos idiomas.

Esto puede ser parcialmente histórico. Incluso en un pasado no muy lejano, era habitual que los administradores de sistemas individuales construyeran e instalaran todo lo que se ejecutaba en su sistema.

Las notas sobre qué idioma y bibliotecas se usaron para implementar una herramienta dan una pista al administrador sobre cuánto trabajo va a ser ese proceso para su sistema.

En esta era de herramientas de gestión de paquetes ubicuas y de largo alcance, esto es un poco anacrónico, pero la cultura unix es conservadora en el sentido de no tirar cosas que parecen estar funcionando, por lo que pasará un tiempo antes de que el hábito desaparezca.

En extensión a la respuesta de jasonwryans :

Si nombra el idioma en el que se escribió, la persona que lo recibe puede estimar lo difícil que será proporcionar un parche, obtener algunas ideas o extender el programa.

Por supuesto, esto solo tiene sentido si eres un programador.

¿Dónde viste los resúmenes? ¿En un repositorio o en un paquete como .deb o .rpm?

Si lo compila desde la fuente, la información puede ser útil para identificar si tiene que instalar otras cosas (compilador, bibliotecas, herramientas de compilación).

Unix, y ahora LInux y los BSD, siempre han tenido una base de software realmente fracturada, y existía una base de hardware mucho más diversa en el pasado más reciente. Era importante saber que algún software se ejecutaba en los intérpretes que tenía en su sistema, o que podía compilar el código fuente. Si no tiene un intérprete de Common Lisp, o un intérprete de Tcl o cualquier otro intérprete, no quería molestarse en descargar la fuente, solo para descubrir que no podía ejecutarlo.

Tener una descripción de en qué idioma se encontraba algo evitaba perder mucho tiempo.

Cuando se le pregunta "¿qué es esto?", Un desarrollador tenderá a describir su naturaleza, que para ellos está vinculada al código fuente, en lugar de su función. Es de esperar que alguien reescriba la descripción para que se centre más en el usuario antes de que termine en un paquete, pero mencionar el lenguaje aún puede ser relevante, por ejemplo, para la extensibilidad y la capacidad de escritura, o útil para la oportunidad de atraer contribuyentes.

Desde mi punto de vista, dicha información es esencial para atraer nuevos contribuyentes, así como para darles a los posibles usuarios una idea inmediata de cuánto trabajo puede implicar integrar la aplicación en su sistema.

• Un aspecto general son las bibliotecas utilizadas al ejecutar la aplicación.

Algunas instalaciones están restringidas a algunos kits de herramientas seleccionados, como GTK + pero no QT, o viceversa. Para un administrador que mantiene un sistema y actualiza regularmente sus componentes durante un largo período de tiempo, esto puede ser únicamente una cuestión práctica y no religiosa.

• Otro aspecto son las bibliotecas utilizadas y los requisitos previos necesarios para compilar la aplicación.

Es decir, para los usuarios de una distribución de Linux basada en la fuente, hace una gran diferencia si una aplicación está escrita en C o en Objective-C, porque su compilador necesita admitir el lenguaje en primer lugar. Otros idiomas pueden hacer que sea necesario instalar una gran pila de bibliotecas. La pregunta es, nuevamente, cuánto trabajo está dispuesto a aceptar para compilar esta aplicación.

• Un aspecto diferente es la intención de atraer contribuyentes.

La mayoría de los desarrolladores tienen preferencia por un pequeño número de idiomas, o simplemente pueden carecer de experiencia en otros. Para permitir que un mayor número de personas contribuyan a una aplicación, algunos proyectos incluso dividen sus fuentes en dos idiomas diferentes (como Wesnoth, Vega Strike, Naev, solo por nombrar algunos). Uno de ellos para la aplicación principal (como C o C ++), el otro para una fácil modificación (como Python o Lua). Aquí hay un enlace a un capítulo de "La arquitectura de las aplicaciones de código abierto" que describe cómo y por qué esto se hizo en Wesnoth.

• Finalmente, obviamente hay muchos prejuicios y prejuicios contra algunos idiomas.

Solo diré que he visto un software terriblemente ineficiente escrito en cualquier idioma. Si me preguntas, por eficiencia, la calidad del código de la aplicación es mucho más importante que el idioma en el que está escrito.

Creo que mucho tiene que ver con la publicidad de rendimiento. Una aplicación escrita en un lenguaje compilado (C, C ++, ...) funcionará muchísimo mejor que una escrita en un lenguaje de script (perl, python, ...).

Pero también se vincula con la compatibilidad. También es probable que una aplicación escrita en un lenguaje de script sea más portátil en arquitecturas y sistemas operativos con poca o ninguna modificación.

En los sistemas de escritorio / servidor actuales puede que no sea tan relevante, pero para sistemas más pequeños que van desde sistemas integrados hasta netbooks y tabletas SSD, los idiomas o bibliotecas utilizados por un programa pueden ser un problema decisivo, tanto por el tamaño como por la interrupción. consideraciones de portabilidad.

En cuanto al tamaño: agregar un intérprete para un idioma adicional, junto con todos los módulos estándar y los módulos complementarios que se usan normalmente, puede agregar fácilmente cientos de megabytes a los requisitos de almacenamiento. Lo mismo ocurre con las familias de bibliotecas, especialmente las asociadas con los principales entornos de escritorio como Gnome y KDE. Lo que es peor, pasar de ejecutar na n+1programas Perl podría no agregar tanto a los requisitos de uso de memoria, ya que se puede compartir mucha memoria, pero pasar de nprogramas Perl y 0 programas Python anLos programas Perl y 1 programa Python dan como resultado un aumento significativo en el uso de memoria. Esto se convierte en un problema aún mayor cuando cada tonto que escribe software libre tiene su propio lenguaje de script / radtool favorito en el que desea programar ... Perl, Python, PHP, Ruby, JavaScript, Bourne shell, Bash, Csh, ...

Con respecto a la portabilidad: muchos lenguajes interpretados (así como marcos de bibliotecas) hacen un uso intensivo de las funciones que pueden estar disponibles en los grandes sistemas de escritorio / servidor Linux, pero no necesariamente en sistemas más pequeños / incrustados / sin MMU. .soMe viene a la mente la dependencia de la carga dinámica de módulos en tiempo de ejecución ...