Quais são as Desvantagens do Python? 5 Casos Para Não Usar

Cada linguagem tem características que podem ser apropriadas ou não para algum caso de uso.

Assim, perguntar quais são as desvantagens do Python é o mesmo que perguntar quando não se deve usar a linguagem Python.

A resposta é simples:

As desvantagens do Python aparecem nas aplicações onde a performance é importante, mas o hardware não é escalável. Ou quando a empresa espera que a vida útil do sistema seja muito longa.

Eu criei essa lista para te ajudar a entender os cenários onde o uso da linguagem de programação Python não é recomendado.

Aplicações que Lidam Diretamente com o Hardware

Se você já leu outros posts aqui do site, sabe que eu defendo que todo mundo deve programar em Python.

Python é uma linguagem de altíssimo nível e eu acredito até que o Python deve ser a primeira linguagem de programação para quem está começando.

Não é à toa que ela é a queridinha das startups, já que o time-to-market de um Produto Viável Mínimo feito em Python é pequeno, se comparado ao de outras linguagens como Java e C++.

Mas isso não significa que você deve usar Python como uma bala de prata para resolver todos os tipos de problemas.

As abstrações da linguagem, a facilidade de ser executada em um interpretador e a tipagem dinâmica têm um custo sobre a performance em tempo de execução.

Vou tentar explicar isso de forma resumida.

A única linguagem que o computador entende é o código binário, representado por 0 e 1.

Para que o programador não precise lidar com isso, foi criada a linguagem Assembly, que traduz um código escrito em inglês em código de máquina. Essa é uma linguagem mais próxima do “metal”, ou seja, do hardware.

No entanto, a linguagem Assembly é complexa e prolixa, além de ser específica para cada família de processadores.

Só para você ter uma ideia, para executar uma instrução simples em Assembly, como imprimir uma mensagem na tela, são necessárias dezenas de linhas de código.

Então, para facilitar o desenvolvimento, foram criadas linguagens mais próximas do inglês, como C, em um nível de abstração acima do Assembly.

No entanto, a linguagem C ainda é considerada uma linguagem de baixo nível e próxima do “metal”, ou seja, não possui muitas estruturas de dados que representam abstrações sobre o hardware.

Essa proximidade do hardware é o principal motivo pelo qual muitos sistemas operacionais e drivers de dispositivos são escritos em C.

Tudo isso faz com que a linguagem C seja muito rápida, mas o programador tem mais trabalho na hora de criar um programa nessa linguagem, já que ele precisa fazer o gerenciamento de memória e lidar com descritores de arquivos, por exemplo.

Então, para que o programador ganhasse produtividade, foram criadas linguagens que são interpretadas em máquinas virtuais.

Essas linguagens têm alto nível de abstração e nem precisam ser compiladas pelo programador. É como se o código-fonte rodasse diretamente no interpretador.

O Python é uma dessas linguagens interpretadas, com sintaxe simplificada, gerenciamento de memória automático e distante do hardware.

Python tem muitas aplicações porque tem abstrações de altíssimo nível que facilitam a vida do programador e reduzem o tempo de desenvolvimento, além de ser fácil de aprender. Essas características da linguagem fazem com que o programador Python seja muito produtivo.

No entanto, também são essas características que fazem com que o Python não seja adequado para programas que precisem lidar diretamente com o hardware.

Agora que você já entendeu como o Python funciona no computador e porque ele tem muitas aplicações, veja uma lista de cenários onde o Python pode não ser a melhor opção.

Aplicações Onde o Hardware não é Escalável

É muito comum ouvir um monte de gente dizer que Python é lento.

Então, vou tentar derrubar esse mito com um exercício de lógica.

Python é Lento?

Outro dia eu li um comentário em um artigo sobre Python, onde o sujeito jurava que tinha feito uma comparação de performance e que o código escrito em C++ era 1.000 vezes mais rápido que o mesmo código em Python!

Ainda que isso seja verdade, eu pergunto…

Você precisa que o seu código rode 1000 vezes mais rápido?

Para entender melhor essa pergunta, veja o exemplo abaixo.

Imagine que você escreveu um programa que roda uma vez por mês e processa milhões de registros em 8 horas.

Agora imagine que você gastou 6 meses de trabalho para conseguir reescrever esse programa em C++.

Com essa alteração, o programa passou a rodar em meia hora.

Esse investimento, de 6 meses de trabalho, valeu a pena?

Depende… É preciso avaliar se havia algumanecessidade de reduzir o tempo de execução desse programa.

Afinal de contas, o tempo que você gastou reescrevendo a versão otimizada do software poderia ter sido gasto para desenvolver um novo produto.

Por isso, antes de dizer que o programa é lento porque é escrito em Python, ou de tomar uma decisão como essa, há várias outras perguntas que devem ser feitas:

• Era um problema de escalabilidade, ou seja, havia previsão de aumentar o número de registros a processar?
• Esse processamento era importante para a tomada de decisão e o resultado não podia demorar 8 horas para sair? Mesmo rodando só uma vez por mês?
• Não era mais fácil só colocar mais hardware para reduzir o tempo de execução?
• Havia algum requisito de redução do consumo de energia?
• E a lista continua…

Talvez você já tenha entendido o que deve ser levado em consideração quando alguém diz que um programa é lento.

Se um software tem um prazo de 30 dias para rodar e roda em 8 horas, ele não pode ser considerado lento, ainda que uma outra versão dele rode em alguns minutos.

Com esse exemplo, eu tentei mostrar que a sua primeira preocupação deve ser entender se o programa precisa ser mais rápido.

E isso leva ao verdadeiro problema…

Situações Onde O Hardware Não Escala

E se o seu programa tiver restrições mais complicadas?

Por exemplo, se ele precisar processar muitos dados, mas rodar em um hardware limitado, como um Raspberry Pi ou em uma controladora embutida em um equipamento proprietário.

Para entender essa restrição, imagine uma placa controladora de voo de um drone.

Ela recebe informações de vários sensores ao mesmo tempo, entre eles o acelerômetro, o giroscópio, o altímetro e o GPS, além dos comandos do controle remoto.

O algoritmo que roda na placa controladora de voo usa todas essas informações em cálculos complexos que resultam no aumento ou na diminuição da velocidade de cada um dos rotores.

É assim que o drone se mantém estável ou se movimenta de maneira previsível.

Tudo isso acontece várias vezes por segundo.

E não dá para colocar mais hardware. O espaço dentro do drone é pequeno para um número maior de placas controladoras.

Além disso, quanto maior e mais complexa for a controladora de voo, mais pesada ela tende a ser, consumindo ainda mais energia.

Mais peso e menos eficiência da bateria é o contrário do que se espera de um drone…

Esse é um exemplo de cenário em que o Python, ou qualquer outra linguagem interpretada, não é a melhor opção.

Nesse caso, uma linguagem mais próxima do tipo específico de processador da controladora de voo daria um resultado mais eficiente.

O exemplo do drone já deixa claro qual é o problema, mas essa situação se aplica a qualquer equipamento com restrições de tamanho ou de fornecimento de energia.

Outros exemplos poderiam ser: um desfibrilador, um relógio inteligente ou um aparelho de ultrassom portátil.

A vantagem de ter um tempo de desenvolvimento menor em Python seria nula se comparada à dificuldade de fazer o software rodar em um hardware limitado.

Mas há um outro tipo de aplicação onde o uso do Python pode causar problemas ainda maiores.

Aplicações de Missão Crítica que Processam Dados em Tempo Real

Esse cenário é bem parecido com o exemplo do drone na seção anterior.

No entanto, o problema aqui não é a restrição do hardware, mas sim a disponibilidade do processador durante todo o tempo de execução do programa.

Mais uma vez, um exemplo rápido vai deixar as coisas mais claras:

Pegando carona no exemplo anterior, imagine como funciona o software de controle de voo de um avião.

O clima a uma altitude de 11.000m talvez seja a coisa mais aleatória que existe.

Por isso, o software recebe dados de centenas de sensores e comandos, centenas de vezes por segundo.

Vários desses dados são usados para calcular a pressão aerodinâmica sobre cada uma das asas.

Cada vez que a pressão aumenta em uma das asas, uma resposta do software pode ser aumentar a potência somente nos motores daquele lado, compensando qualquer perda e mantendo a trajetória em linha reta.

Se esses dados chegam ao computador de voo 200 vezes por segundo, isso significa que é preciso gerar uma resposta a cada 5 ms.

E se o software pausar por 20 ms para rodar o garbage collector, isso pode até parecer um tempo irrisório, mas são perdidas nada menos que 4 leituras.

O resultado disso seria um equipamento pouco confiável.

Veja que, mesmo sendo possível colocar um data center inteiro no avião, isso não resolveria o problema.

O gerenciamento automático de memória, uma das principais características da arquitetura das linguagens interpretadas, inviabiliza o seu uso em sistemas onde o software precisa estar sempre disponível.

Outros exemplos desse cenário seriam foguetes, usinas nucleares, switches de rede e jogos.

E por falar em jogos, imagine o GTA V no PC, rodando a 60 fps (frames por segundo) em resolução 4k.

Isso significa que cada quadro com mais de 8 milhões de pixels precisa ser todo renderizado em menos de 16,6 ms.

E esse é só o esforço gráfico. Ainda sobra toda a carga da IA, comunicação de rede, salvamento automático…

Com certeza, essa não é uma tarefa para uma linguagem interpretada.

Aliás, quando se trata de interfaces gráficas, surge mais um cenário onde o uso do Python não é recomendado.

Aplicações Nativas com Interfaces Gráficas

O fato de uma linguagem ser interpretada não faz com que ela se torne imprópria para desenvolver sistemas com interfaces gráficas.

No entanto, as interfaces gráficas mais eficientes são aquelas que conversam diretamente com o sistema operacional e se beneficiam dos elementos gráficos que o próprio S.O. desenha na tela.

Por esse motivo, cada fabricante de sistema operacional define as APIs e as linguagens mais adequadas para a construção de interfaces gráficas.

Por exemplo, no Windows você pode usar as linguagens da plataforma .NET, como C#, Visual Basic ou C++.

No macOS e iOS, as linguagens usadas são Objective-C ou Swift.

E no Android, Java ou Kotlin.

Mas isso não significa que é impossível criar interfaces gráficas em Python, ou em qualquer outra linguagem interpretada.

Nesse caso, você tem duas opções:

• Escrever o programa em Python e usar uma ferramenta para converter esse código em uma das linguagens recomendadas para o sistema operacional.
• Usar bibliotecas que desenham os elementos na tela, imitando os componentes nativos, como janelas, abas e botões.

O problema é que os aplicativos desenvolvidos dessa maneira são inferiores em termos de performance e confiabilidade, quando comparados aos aplicativos desenvolvidos nas linguagens nativas.

Além disso, seja lá qual for a abordagem que você use, sempre vai haver trabalho extra para o programador, já que será necessário entender como formatar os componentes na tela, coisa que a biblioteca padrão do Python não faz.

No Kivy, por exemplo, é preciso usar uma linguagem chamada “Kv Design” para montar as telas.

Assim, você vai acabar perdendo a principal vantagem do Python, que é o ganho de produtividade durante o desenvolvimento.

Isso sem falar que algumas dessas bibliotecas não são gratuitas.

O Qt, por exemplo, é vendido no modelo de assinatura anual e custa quase US$4.000 por ano, por desenvolvedor.

Portanto, nesse caso, se você vai desenvolver um sistema nativo com interface gráfica, eu recomendo que você use uma das linguagens específicas para o sistema operacional onde esse sistema vai rodar.

Aplicações com Vida Útil Muito Longa

Lembra que eu falei no início do post que a linguagem Python é a queridinha das startups?

Em geral, uma startup quer lançar um produto o mais rápido possível e evoluir sua base de código de acordo com a resposta do mercado.

E se o requisito é produtividade, a linguagem Python é uma excelente candidata.

Como o tempo de desenvolvimento é menor, o prejuízo de falhar depois de desenvolver um sistema em Python acaba sendo menor do que se o sistema tivesse sido feito em Java, C ou C++.

Depois de algumas rodadas de captação de recursos financeiros, a startup pode usar o dinheiro para reescrever todos os seus sistemas em uma dessas linguagens, buscando mais eficiência.

Ou não! (Veja mais sobre isso na seção a seguir.)

No entanto, em empresas grandes e mais conservadoras, a tolerância a mudanças costuma ser bem menor.

Esse tipo de empresa costuma olhar para um horizonte mais distante desde o início de um projeto.

Para você ter uma ideia, os bancos são as empresas que mais gastam com TI no Brasil, segundo a 31ª edição da Pesquisa Anual do Uso de TI da FGV.

Apesar disso, os maiores bancos ainda usam mainframes rodando sistemas em Cobol, feitos há mais de 50 anos!

Por isso, é difícil imaginar que uma empresa conservadora aceite escrever um sistema em Python somente para fazer uma entrega rápida e depois reescrever todo o sistema em outra linguagem, visando o longo prazo.

É provável que essa empresa nem consiga justificar esse processo de experimentação para os seus acionistas.

Além disso, o risco de introduzir bugs no software e as consequências disso para o negócio da empresa têm um peso grande no momento de tomar a decisão sobre qual linguagem usar.

Portanto, se você trabalha em uma empresa grande e conservadora, que espera que os sistemas tenham uma vida útil muito longa, talvez você nunca participe de um projeto que use a linguagem Python.

E se isso acontecer, é provável que esse projeto não esteja relacionado ao negócio principal da empresa.

Mas… E o YouTube?

Esse título pode não fazer muito sentido se você não souber que a maior parte do YouTube é feita em Python.

E não é só o YouTube.

A maior parte do backend  de outros sites com um volume enorme de acessos, como Instagram, Netflix, Uber, Spotify, Dropbox e Reddit também é feita em Python.

Mas como eles fazem isso?

Bem, nenhum desses serviços tem os requisitos que eu listei nesse post:

• A linguagem Python só é usada no backend. O frontend Web usa HTML, CSS e JavaScript. Os apps móveis também são feitos nas linguagens nativas de cada plataforma.
• A arquitetura é bem pensada e distribuída entre milhares de servidores, então pequenas pausas na execução são imperceptíveis. A latência de rede em sistemas Web é um problema muito maior do que esse e já foi resolvido para esses serviços.
• Com certeza nenhuma dessas empresas tem problemas para comprar mais hardware para o seu Data Center.

Mas apesar de todas essas características, há uma resposta muito simples para a pergunta acima.

Caso algum componente do serviço não tenha uma performance adequada, por ter sido desenvolvido em Python, a empresa reescreve só aquele componente usando uma outra linguagem, como Java ou C++.

Ou então, a equipe de desenvolvimento escreve suas próprias bibliotecas em C, para serem usadas a partir do código em Python, da mesma forma que funciona o pacote NumPy, por exemplo.

Conclusão

Nesse post eu listei alguns cenários onde o uso do Python não é recomendado.

Desse jeito, ficou fácil de entender que quanto mais específica e crítica for a necessidade do software, mais perto do hardware é preciso trabalhar.

Se você entendeu esse princípio, não vai ter dificuldade de perceber quando não deve usar a linguagem Python em um projeto.

Você consegue pensar em algum outro cenário onde o Python não deve ser usado? Então escreva nos comentários e explique por que você acha isso. E não esqueça de dizer como eu posso melhorar esse post!