Por que os aplicativos Linux geralmente colocam o idioma em que foram escritos no resumo?

Ao exibir aplicativos, o Windows e o Mac falam principalmente sobre recursos. Os aplicativos Linux, por outro lado, têm mais detalhes sobre qual idioma foi usado para escrevê-lo (e as bibliotecas que os acompanham) em vez dos recursos. Por que é que?

Eu pude entender sabendo a diferença entre GTK + e QT fazendo a diferença apenas por causa dos requisitos de integração de desktop, mas C vs C ++ vs Python vs Assembly vs etc.? Sério?

Por exemplo: foo é um simples blá blá escrito em C / GTK +.

Eu acho que o usuário tradicional do Linux (um nerd que realmente instalou o sistema sozinho) se importa com essas informações (que tecnologia está por trás dessa ferramenta?). Eu também sou um daqueles caras nerds que, por exemplo, evitariam instalar e usar um pacote apenas porque ele usa alguma tecnologia que eu não gosto. Alguns chamam esse tipo de comportamento de religião, é claro. Bobo, não é?

De qualquer forma, posso pensar em duas razões:

• Os empacotadores são tão nerds (se não mais) do que os usuários do Linux, então acharam uma boa ideia adicionar essas informações.

• Acho que quando esses empacotadores colocam essas informações em suas descrições de pacotes, provavelmente estão fazendo isso como uma forma de promoção. Às vezes funciona (funcionou comigo várias vezes).

Isso é apenas um palpite, é claro.

A meu ver, isso se refere à segunda das quatro liberdades de software :

A liberdade de estudar como o programa funciona e alterá-lo para fazer o que você deseja (liberdade 1). O acesso ao código-fonte é uma condição prévia para isso.

A divulgação do idioma (ou outros recursos técnicos) apóia a capacidade de escolha das pessoas e incentiva a participação em projetos de pessoas que são proficientes nesses idiomas.

Isso pode ser parcialmente histórico. Mesmo em um passado não tão distante, era comum os administradores de sistemas individuais criarem e instalarem tudo o que executava em seu sistema.

As anotações sobre qual idioma e bibliotecas foram usadas para implementar uma ferramenta dão uma dica ao administrador sobre quanto trabalho esse processo será para o sistema deles .

Nesta era de ferramentas de gerenciamento de pacotes onipresentes e abrangentes, isso é um pouco anacronista, mas a cultura unix é conservadora no sentido de não jogar fora as coisas que parecem estar funcionando, por isso levará um tempo antes que o hábito morra.

Em extensão à resposta de jasonwryans :

Se você nomear o idioma em que foi escrito, a pessoa que o receber poderá estimar o quão difícil será fornecer um patch, obter algumas idéias ou estender o programa.

Claro que isso só faz sentido se você é um programador.

Onde você viu os resumos? Em um repositório ou em um pacote como .deb ou .rpm?

Se você construí-lo a partir da fonte, as informações podem ser úteis para identificar se você precisa instalar outros itens (complilador, bibliotecas, ferramentas de construção).

O Unix, e agora o LInux e os BSDs, sempre tiveram uma base de software realmente fraturada, e uma base de hardware muito mais diversa existia no passado recente. Era importante saber que alguns softwares rodavam nos intérpretes que você tinha no seu sistema ou que você poderia compilar o código-fonte. Se você não possui um intérprete Common Lisp, intérprete Tcl ou qualquer outro intérprete, não quis se preocupar em baixar a fonte, apenas para descobrir que não pode executá-la.

Ter uma descrição de qual idioma havia algo impedia muito tempo perdido.

Quando solicitado "o que é isso?", Um desenvolvedor tenderá a descrever sua natureza, que para eles está vinculada ao código-fonte, e não à sua função. É provável que alguém reescreva a descrição para ser mais centrada no usuário antes de terminar em um pacote, mas mencionar o idioma ainda pode ser relevante, por exemplo, para extensibilidade e capacidade de script ou útil para a oportunidade de atrair colaboradores.

Na minha perspectiva, essas informações são essenciais para atrair novos colaboradores, além de fornecer aos possíveis usuários uma idéia imediata de quanto trabalho pode ser necessário para integrar o aplicativo ao seu sistema.

• Um aspecto geral são as bibliotecas usadas ao executar o aplicativo.

Algumas instalações estão restritas a alguns kits de ferramentas selecionados, como GTK +, mas não QT, ou vice-versa. Para um administrador que mantém um sistema e atualiza regularmente seus componentes por um longo período, isso pode ser apenas uma questão prática e não religiosa.

• Outro aspecto são as bibliotecas usadas e os pré-requisitos necessários para compilar o aplicativo.

Ou seja, para usuários de uma distribuição Linux baseada na fonte, faz uma grande diferença se um aplicativo é escrito em C ou em Objective-C, porque seu compilador precisa suportar o idioma em primeiro lugar. Outros idiomas podem tornar necessário instalar uma enorme pilha de bibliotecas. A questão é, novamente, quanto trabalho você deseja aceitar para compilar esse aplicativo.

• Um aspecto diferente é a intenção de atrair colaboradores.

A maioria dos desenvolvedores prefere um pequeno número de idiomas ou pode simplesmente não ter experiência em outros. Para permitir que um número maior de pessoas contribua para uma aplicação, alguns projetos até dividem suas fontes em dois idiomas diferentes (como Wesnoth, Vega Strike, Naev, apenas para citar alguns). Um deles para o aplicativo principal (como C ou C ++), o outro para fácil modificação (como Python ou Lua). Aqui está um link para um capítulo de "A arquitetura de aplicativos de código aberto" que descreve como e por que isso foi feito no Wesnoth.

• Finalmente, obviamente há muitos preconceitos e preconceitos contra alguns idiomas.

Vou apenas dizer que vi software terrivelmente ineficiente escrito em qualquer idioma. Se você me perguntar, por eficiência, a qualidade do código do aplicativo é muito mais importante do que o idioma em que está escrito.

Eu acho que muito disso tem a ver com propaganda de performance. Um aplicativo escrito em uma linguagem compilada (C, C ++, ...) terá um desempenho muito melhor do que um escrito em uma linguagem de script (perl, python, ...).

Mas também está vinculado à compatibilidade. Também é provável que um aplicativo escrito em uma linguagem de script seja mais portátil entre arquiteturas e sistemas operacionais, com pouca ou nenhuma modificação.

Nos sistemas atuais de desktop / servidor, pode não ser tão relevante, mas, para sistemas menores, que variam de sistemas embarcados a netbooks e tablets SSD, os idiomas ou as bibliotecas usadas por um programa podem ser um problema de improviso, devido ao tamanho e considerações de portabilidade.

Quanto ao tamanho: a adição de um intérprete para um idioma adicional, juntamente com todos os módulos padrão e módulos complementares normalmente usados, pode adicionar facilmente centenas de megabytes aos requisitos de armazenamento. O mesmo vale para as famílias de bibliotecas, especialmente as associadas aos principais ambientes de desktop, como o Gnome e o KDE. O que é pior: passar da execução npara n+1programas Perl pode não adicionar muito aos requisitos de uso de memória, pois é possível compartilhar muita memória, mas passar dos nprogramas Perl e 0 programas Python paranProgramas Perl e 1 programa Python resultam em um aumento significativo no uso de memória. Isso se torna ainda mais problemático quando todos os softwares livres de escrita tola têm sua própria linguagem de script / radtool favorita em que desejam programar ... Perl, Python, PHP, Ruby, JavaScript, Bourne shell, Bash, Csh, ....

Quanto à portabilidade: Muitas linguagens interpretadas (assim como as estruturas de bibliotecas) fazem uso pesado de recursos que podem estar disponíveis em grandes sistemas de desktop / servidor Linux, mas não necessariamente em sistemas menores / incorporados / sem MMU. A dependência do .socarregamento do módulo dinâmico em tempo de execução vem à mente ...