paulo1205
(usa Ubuntu)
Enviado em 10/11/2025 - 21:00h
Script é mais genérico, até a hora em que não é mais.
Para quem trabalha só com Linux, isso não é tão problemático. Mas eu costumava trabalhar, na empresa em que trabalho, com Linux, Solaris e AIX, e acabava preferindo scripts em ksh (que é muito melhor para programação do que o Bash, especialmente o ksh93 oficial) ou Perl (eu sou velho, anterior à ascensão do Python), e tudo ia muito bem, até esbarrar em especificidades de cada sistema, em que a genericidade das linguagens de
script passava a ser mais um problema incontornável do que uma vantagem, e a gente acabava tendo de apelar à programação em mais baixo nível mesmo.
Mais recentemente, usando somente Linux, eu precisei fazer algumas coisas com LDAP usando autenticação Kerberos, e tive dificuldades tanto com Perl quanto com Python, porque uma delas (não lembro qual) simplesmente não suportava autenticar com Kerberos, e a outra, que suportava, engasgava com algum outro aspecto de que minha aplicação precisava (também não lembro exatamente o quê — talvez consultas paginadas?). O resultado foi que eu acabei fazendo um
wrapperzinho em C++ em torno das funções da API em C da biblioteca do OpenLDAP, que é suficiente para fazer tudo o que eu preciso com conveniência, com muito menos enrolação do que tanto as bibliotecas em Perl quanto em Python.
Esse
wrapper chegou a compilar até no AIX, antes de o aposentarmos (na minha área; outras áreas possivelmente ainda têm um AIX ou outro).
Mas voltando à pergunta original, o bom programador tem de ter mais de uma ferramenta na sua caixa de ferramentas. A melhor solução para o problema de hoje pode ser terrível do problema de amanhã.
Especificamente sobre linguagens de
script, o vasto poder computacional atual, aliado a técnicas como
caches de
scripts que já foram transformados de texto para a representação interna da árvore sintática ou outras representações binárias ainda mais avançadas, tais como compiladores
just-in-time, fazem com que, para tarefas com necessidade de uso de CPU não muito grande,
scripts sejam quase imbatíveis em termos de eficiência no uso do recurso mais caro, que é o salário de quem o desenvolve. E é esperado que uma migração tecnológica impacte um
script menos do que um programa executável.
Cada vez mais, usar código nativo é somente o desempenho da execução é uma condição muito importante, quando se esbarra numa limitação que não tem como ser facilmente transposta com as linguagens de
scripts, quando já se tem pronta boa parte do serviço na linguagem usada para gerar código nativo, ou quando o
script, por ser tipicamente legível, pode trazer um risco de propriedade intelectual ou mesmo de segurança.
No caso que eu descrevi do LDAP com Kerberos. a primeira implementação foi por causa do segundo fator, e o que veio depois continuou sendo feito em C++ porque eu já tinha a biblioteca pronta. Mas eu admito que eu não consultei muito tempo para ver se Perl e Python teriam
outras bibliotecas, diferentes das bibliotecas “nativas” de suas respectivas distribuições, que implementariam as partes de que eu senti falta quando tive em mãos o projeto que esbarrou nas limitações que eu indiquei acima.
... Então Jesus afirmou de novo: “(...) eu vim para que tenham vida, e a tenham plenamente.” (João 10:7-10)
