Por que os aplicativos do Linux geralmente colocam o idioma no qual ele foi escrito no resumo?

Question

Ao apresentar aplicativos, o Windows e o Mac falam principalmente sobre recursos. Os aplicativos Linux, por outro lado, têm mais detalhes sobre qual linguagem foi usada para escrevê-lo (e acompanhar as bibliotecas) em vez de recursos. Por que isso?

Eu poderia entender sabendo a diferença entre GTK + versus 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? Realmente?

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

    

Answer 1

Eu acho que o usuário tradicional do Linux (um geeky tinkerer que realmente instalou o sistema por conta própria) se preocupa com essas informações (qual tecnologia está por trás dessa ferramenta?). Eu também sou um desses caras nerds que, por exemplo, evitam instalar e usar um pacote só porque ele usa alguma tecnologia que eu não gosto. Alguns chamam esse tipo de religião de comportamento, é claro. Tola não é?

De qualquer forma, posso pensar em dois motivos:

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

• Eu acho que quando esses empacotadores colocam essas informações em suas descrições de pacotes, eles provavelmente estão fazendo isso como alguma forma de promoção. Funciona às vezes (funcionou em mim algumas vezes).

Isso é apenas uma suposição, é claro.

    

Answer 2

Meu sentimento é relacionado à segunda das quatro liberdades de software :

The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.

A divulgação do idioma (ou outras características técnicas) apóia a capacidade de escolha das pessoas e incentiva a participação em projetos de pessoas com proficiência nessas línguas.

    

Answer 3

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

Notas sobre qual linguagem e bibliotecas foram usadas para implementar uma ferramenta dão uma dica para o administrador sobre quanto trabalho esse processo será para o sistema deles.

Nesta era de ferramentas de gerenciamento de pacotes onipresentes e de longo alcance isso é um pouco de um anacronismo, mas a cultura unix é conservadora no sentido de não jogar fora coisas que parecem estar funcionando, então será um tempo antes do hábito morre.

    

Answer 4

Em extensão à resposta do jasonwryans :

Se você nomear o idioma em que foi escrito, a pessoa que o receber poderá estimar o quanto será difícil fornecer um patch, obter algumas informações ou estender o programa.

Claro que isso só faz sentido se você for 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 do código-fonte, as informações podem ser úteis para identificar se você precisa instalar outras coisas (compilador, bibliotecas, ferramentas de construção).

    

Answer 5

O Unix, e agora o LInux e o BSDs, sempre tiveram uma base de software realmente fraturada, e uma base de hardware muito mais diversificada existia no passado bastante recente. Era importante saber que algum software rodava nos intepreters que você tinha em seu sistema, ou que você poderia compilar o código-fonte. Se você não tem um intérprete Common Lisp, ou um interpretador Tcl ou um interpretador, você não quer se incomodar em baixar o código-fonte, apenas para descobrir que não pode executá-lo.

Ter uma descrição do idioma em que algo estava evitou muito tempo perdido.

    

Answer 6

Quando solicitado "o que é isso?", um desenvolvedor tenderá a descrever sua natureza, que para eles está ligada ao código-fonte, e não à sua função. Alguém reescreverá a descrição para ser mais centrada no usuário antes que ela chegue a um pacote, mas mencionar a linguagem ainda pode ser relevante, por exemplo, para extensibilidade e capacidade de leitura de scripts, ou útil para a oportunidade de atrair colaboradores.

    

Answer 7

Do meu ponto de vista, essas informações são essenciais para atrair novos colaboradores, além de dar aos usuários em potencial uma ideia imediata de quanto trabalho pode ser necessário para integrar o aplicativo em seu sistema.

• Um aspecto geral são as bibliotecas usadas quando é executado o aplicativo.

Algumas instalações estão restritas a alguns kits de ferramentas selecionados, como o GTK +, mas não o QT, ou vice-versa. Para um administrador que mantém um sistema e atualiza regularmente seus componentes durante um longo período de tempo, 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 em fontes, faz uma grande diferença se um aplicativo é escrito em C, ou em Objective-C, porque seu compilador precisa suportar a linguagem em primeiro lugar. Outras linguagens podem tornar necessário instalar uma enorme pilha de bibliotecas. A questão então é, novamente, quanto trabalho você está disposto a aceitar para compilar esta aplicação.

• 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 duas línguas diferentes (como Wesnoth, Vega Strike, Naev, apenas para citar algumas). Um deles para o aplicativo principal (como C ou C ++), o outro para facilitar a modificação (como Python ou Lua). Aqui está um link para um capítulo de "A Arquitetura de Aplicações de Código Aberto" que descreve como e por que isso foi feito em Wesnoth.

• Finalmente, há obviamente muito preconceito e preconceito contra alguns idiomas.

Só direi que vi softwares horrivelmente ineficientes escritos em qualquer idioma. Se você me perguntar, por eficiência, a qualidade do código do aplicativo é muito mais importante do que a linguagem em que está escrito.

    

Answer 8

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

Mas também está ligado à compatibilidade. Um aplicativo escrito em uma linguagem de script também é mais portável entre arquiteturas & SOs com pouca ou nenhuma modificação.

    

Answer 9

Nos sistemas de desktop / servidor atuais, pode não ser tão relevante, mas para sistemas menores, desde sistemas incorporados a netbooks e tablets SSD, os idiomas ou bibliotecas usados por um programa podem ser um assunto decisivo, às considerações de tamanho e portabilidade.

Em relação ao tamanho: Adicionar um intérprete para um idioma adicional, juntamente com todos os módulos padrão e módulos complementares normalmente usados, pode facilmente adicionar centenas de megabytes aos requisitos de armazenamento. O mesmo vale para as famílias de bibliotecas, especialmente aquelas associadas aos principais ambientes de desktop, como o Gnome e o KDE. O pior é que a execução de programas n to n+1 Perl pode não adicionar muito aos requisitos de uso de memória, já que muita memória pode ser compartilhada, mas passando de n programas Perl e 0 programas Python a n Programas Perl e 1 programa Python resultam em um aumento significativo no uso da memória. Isso se torna ainda mais um problema quando todo software livre de escrita de bobo tem sua própria linguagem de script / radtool favorita que eles querem programar em ... Perl, Python, PHP, Ruby, JavaScript, shell Bourne, Bash, Csh, ....

Com relação à portabilidade: muitas linguagens interpretadas (bem como estruturas de bibliotecas) fazem uso pesado de recursos que podem estar disponíveis em grandes sistemas de desktop / servidor Linux, mas não necessariamente disponíveis em sistemas menores / embutidos / sem MMU. Dependência do carregamento dinâmico do módulo .so em tempo de execução vem à mente ...