Bons programadores não programam em Python… nem em Ruby, nem em PHP, nem em JavaScript, nem em…

1
2
3
4
5

#PHP VS  JAVA
//JAVA VS PYTHON
/*C++ VS JAVA*/
'JAVA VS .NET
out.println("EU NAO SEI PROGRAMAR NADA!");

Eu tenho um amigo que é apaixonado por Python. Ele é muito gente boa e muito querido por mim e pela minha esposa e até é importante nos meios da comunidade Python. Mas se fosse apenas por ser nerd e gostar de Python provavelmente ele não me chamaria a atenção. Fato que gosto de conversar com ele e sua esposa sobre política, sobre economia, sobre trabalho e principalmente tudo sobre jogos. Jogos, sim, claro, ele é amante de jogos de tabuleiro e tem na casa dele uma estante recheada de jogos importados, uma pessoa destas pode ser uma má pessoa? A resposta é não =)

Mas voltando ao assunto original, ele defende muito Python e por 3X eu tentei aprender esta linguagem por conta das alfinetadas que ele dá. Mas não dá, simplesmente não dá. Não desce. Certa vez ele disse que foi a 1ª linguagem que aprendi foi Java e por isto eu não gosto de Python. Errado. A primeria linguagem que aprendi foi linguagem BAT do MS-DOS, depois foi Visual Basic, VBA, C++ e só então Java.

Então em outro momento ele disse “ah mas foi porque foi a última e você não teve mais paciência para aprender outras linguagens”. Errado também! Depois de Java eu ainda aprendi C#, PHP, lotus script e cold fusion. E coloco o Python em igualdade do cold-fusion em linguagens que não me descem a garganta.

Sei que vai ter muitos trolls que vão vir aqui pra me encher o saco, mas foda-se. Odeio Python. Se preciso, dou suporte (como já cansei de dar suporte na comunidade de L2J).

Aliás bem lembrado, a comunidade L2J começou a fazer scripts para quests em Python e terminou que ninguém conseguia dar suporte neles de tão mal escritos e confusos. Resultado? Todo script novo agora é em Java e muitos dos antigos foram convertidos para Java. Se Python fosse bom e fácil aparecia gente interessada em dar suporte. E até hoje tem vários scripts bugados em python no L2J que de tempos em tempos um programador Java refaz o código, pois os programadores de python mexem, mexem e a coisa toda continua porca. (para quem não sabe L2J é um projeto open source).

Mas ok, quais os argumentos? Dizer que uma comunidade migrou de python para java não é argumento, pois outras comunidades podem ter feito o contrário. Também não se pode jogar que linguagens scripts não são sérias devido apenas python. Tem o PHP por exemplo. Então vamos à eles:

Abertura de Código:

Linguagens scripts exigem que o código seja aberto, afinal se não for aberto e sim compilado deixa de ser scripts. Muitas vezes ser aberto inviabiliza modelos de negócios. Exemplo que posso citar são jogos. Muitos jogos sobrevivem com o fechamento do código, seja para impedir que o jogador roube (em modo multiplayer) ou para impedir que o jogo seja alterado (devido a direito autorais).

Outra situação é quando o cliente não confia onde vai ficar o código, afinal, nem sempre o código fonte fica onde o cliente confia. Então bibliotecas de conexões a bancos são criadas para que ninguém enxergue senhas e dados mais pessoais. Esta não é a saída mais elegante mas é a mais aceita se visualizar a quantidade de projetos onde o segredo fica oculto na forma de linguagem de máquina, para projetos baratos as vezes é o suficiente.

Claro que existem outras situações onde manter o código compilado seja o ideal, como manter segredos de algorítimos complexos que levaram anos de pesquisa etc., mas queria apenas demonstrar que existem motivos. Mesmo que existam formas caras de contorná-los eles não deixam de ser motivos.

Variáveis:

Para mim, linguagens sérias exigem que seja declarado variáveis (tipagem estática) e de preferência exija conversão (tipagem forte). No PHP você não é obrigado a declarar a variável e nem recebe um erro caso ela seja usada e ainda esteja nula. Da mesma forma no JavaScript (embora em casos raros ele reclame). Situações como estas podem levar o programador ao seguinte erro:

1
2
3
4
5
6
7

adminCount = getAdminCount();
(...)
if(admCount >  0)
{
   //remove deslogados
   admCount =  admCount - getAdminLogoutCount();
}

No exemplo acima, ele inicia a variável adminCount com a quantidade de administradors logados, e por um erro de digitação ele jamais entra no if onde atualizaria a variável que conta admins logados. Outro exemplo ainda pior é:

1
2
3
4
5
6

var noHaveAdminAcess = getAccessUser();
if(noHaveAdminAces ==  1)
{
	//habilita acesso de admin, pois não foi bloqueado o acesso de admin
        (...)
}

No exemplo acima, um código pode levar a liberar acessos proibitivos no sistema, apenas porque a variável em script foi declarada e iniciada automaticamente com zero. Outros erros podem fazer o programador perder horas valiosas do dia dele tentando descobrir a encrenca. Alguns scripts trazem a possibilidade de configurar isto, mas se o padrão é permissivo já é um erro! Por quê? Porque você depende da boa fé de que o servidor vai ter esta possibilidade de configuração, coisa que qualquer programador sabe que não funciona bem assim.

No Python (e acredito que em Ruby) e em outras linguagens mais novas, eles pegam um terceiro caminho. Você não é obrigado a declarar, mas é obrigado a dar um valor para ela antes de acessá-la. Resolve metade dos problemas, mas ainda leva os programadores ao erro. Esta situação pode levar a seguinte encrenca:

1
2
3
4
5
6
7
8
9
10
11
12
13

noHaveAdminAccess = 0; //tem acesso de admin
(...)
 
if(userBanned ==1)
{
   noHaveAdminAces = 1; //usuario banido remove o acesso de admin
}
(...)
if(noHaveAdminAccess ==  1)
{
	//habilita acesso de admin, pois não foi bloqueado o acesso de admin
        (...)
}

Se reparar, inicialmente o usuário tem acesso de admin. Por conta de um erro, quando o usuário tem o status banido ele não remove o acesso de admin, no lugar disso ele cria uma nova variável com valor 1, valor que jamais vai ser lido (ou até pode ser lido se o erro ocorrer em outros lugares), causando uma tremenda falha de segurança e confusão.

São exemplos bestas, que criei de cabeça mas já passei por alguns casos, já tive que corrigir muita cagada em scripts por conta destas falhas de linguagem e me aborrece muito quando alguém vem defender linguagens scripts contra linguagens robustas como C, C++, Java e C#. Ai você pode dizer “Ah mas se programar direito não acontece isto!”, ok mas se a linguagem favorece programadores preguiçosos, que tipo de código você acha que vai cair nas tuas mãos pra arrumar?

Blocos de comandos não obrigatórios

Linguagens scripts costumam ignorar o fechamento de blocos, no caso de JScript e PHP se não me engano ambos permitem ignorar os últimos “fechas” de bloco. Tornando assim um perigo, pois se existe a falta de “}” nada garante que não esteja faltando mais coisas, ou elas não estejam tremendamente erradas.

Novamente o Python pega um terceiro caminho, no entanto outra vez ele só cria um novo caminho que na minha opinião mais atrapalha que ajuda. Para definir blocos ele usa apenas identação. Soa lindo na teoria mas uma merda na prática pois na teoria visualmente teria o mesmo efeito, um código:

1
2
3
4

if(cont==1)
{
   (...)bloco de comandos
}

seria aceito em linguagens que exigem apenas identação, ficando apenas assim:

1
2

if(cont==1)
   (...)bloco de comandos

Parece ótimo não precisar digitar os braços (ô preguiça) mas eu (opinião pessoal minha), acho extremamente deselegante depender do editor de texto, espaços e tabs pra marcar algo tão sólido como um bloco de códigos numa estrutura condicional.

Aliás da mesma maneira ele não tem terminador de linha “;” por exemplo, mas ai acho que a quebra de linha cumpre bem o papel visual.

Tipologia

OO que me perdoe, mas se tu quer desenvolver em OO puro, por favor use Smaltak. Tipologia de variáveis existem, não por acaso. Estão aí para garantir que o código será escrito sem erros. A maioria esmagadora dos scripts não exigem definição de tipos, e ai começa a encrenca:

1
2
3
4
5
6

   havePermission = "false";
 
   if(havePermission)
   {
        (...)//libera permissão
   }

O exemplo acima é apenas “um exemplo”. Existem outros, mas é apenas para demonstrar como podem ocorrer falhas de codificação esperando que o conteúdo seja um tipo e na realidade é outro.

A exigência de tipos causa um erro de compilação*, avisando ao programador que ele cometeu um engano, ou ele usou a variável errada ou esperou que a variável contivesse um tipo de valor (boleano no exemplo) e na realidade tem outro. Este tipo de coisa salva o programador de erros no futuro, e como tudo que pode ser deixado para depois, este erro pode causar desastres lá adiante.

*dependendo do editor, até um erro de edição. Porém como não podemos contar com o editor, o compilador segura as pontas.

Olha como sou bom programador, tudo que faço compila!

Não irei citar aqui todos os casos, mas é fácil notar que linguagens scripts têm o intuito de acelerar a produção do código, nem que deixe passar alguns erros que estourem lá adiante. Esta aí algo que não curto, pois é o efeito borboleta passando propositalmente debaixo do nariz do programador. O erro vai passando pra ser resolvido depois, mas o depois não se sabe quem irá receber a bomba, talvez não seja você, ou talvez você não se lembre mais do que programou há um ano atrás. E aí você se mata em procurar o erro que poderia ter sido evitado já em tempo de compilação, ocasionando maior gasto para a empresa e para o programador.

Teve um sujeito que chegou para mim e disse “poxa você deveria fazer o site do Taulukko em Ruby, teria ficado bem melhor”. É como o líder do L2J falou uma vez que alguém disse o mesmo para ele a respeito de não ter feito a engine em C++ pela velocidade, “existe algum projeto em C++ para emular L2 que vingou ? Não né?” Mesma coisa. Meu servidor nem tem suporte a Ruby, eu não tenho conhecimento profundo na linguagem Ruby como tenho em Java, tenho centenas de bibliotecas e códigos prontos em Java, e o cara me fala que teria sido melhor se eu tivesse feito em Ruby? São pensamentos pequenos como estes que me fizeram criar este post. Eu não chego e falo que o Twitter teria menos baleias se fosse feito em Java, falo? Pronto falei!

Apesar disso respeito muito Ruby pois dentre as linguagens scripts é na minha opinião a mais fácil de achar erros e corrigir problemas. Mas também não trabalhei nela a fundo para poder levantar seus defuntos, mas conheço alguns dos seus defeitos, como no exemplo abaixo que é o slogan do site do Ruby:

1
2
3
4
5
6
7
8
9
10
11

cidades  = %w[ Londres
              Oslo
              Paris
              Amsterdão
              Berlim ]
visitadas = %w[Berlim Oslo]
 
puts "Ainda me falta " +
     "visitar " +
     "as cidades:",
     cidades - visitadas

Onde você tem duas listas subtraindo uma da outra. Então você acredita que vai dar um erro? Errado, se você acha que vai dar a diferença de quantidade das duas listas? Errado de novo, ela exibe os nomes das cidades não visitadas, separadas com quê? Pois é… Se fosse uma linguagem menos preocupada com o desenvolvedor e mais com a consistência seria algo como:

1
2
3
4
5
6
7

String cidades []   = { "Londres", "Oslo", "Paris", "Amsterdão", "Berlim" };
String visitadas [] = {"Berlim", "Oslo"};
 
pront( "Ainda me falta " +
     "visitar " +
     "as cidades:",
     EString.join(cidades.remove(visitadas),",") );

Onde o remove fica óbvio que está removendo os elementos da lista visitadas, e o join deixa óbvio que está transformando a lista num objeto string só separado por vírgula.

Leeento

Eu acho que reclamar de lentidão é a coisa mais baixa que um programador pode fazer ao reclamar de alguma linguagem. Desde a criação do PC os processadores não param de acelerar a cpu, então o que é lento hoje não é amanhã. E se for, otimizações na engine tornam os códigos mais rápidos. O Java quando nasceu era dezenas e dezenas de vezes mais lento do que o C++, hoje ele chega a ser mais rápido que o C++ em programas que ficam muito tempo na memória, pois as otimizações possíveis em Java superam a velocidade do código já compilado em C++.

Mas é um fato. A princípio, toda linguagem script é lenta. Mas eu não deixaria de usar uma delas por conta disto a não ser que fosse algo muito pesado que seria rodado.

Então jogo fora meus códigos em script?

Pera lá! Não estou dizendo que são inúteis, acho a linguagem do Visual Basic 6 e Delphi porcas mas até eles têm sua vez. Cada caso é um caso. O PHP pela simplicidade de teste, e de desenvolvimento. Além da facilidade de montar servidores WEB, perto do Java, se tornou uma linguagem ótima para sites. Como exige pouco conhecimento de programação, programadores mesmo amadores dão suporte a complexos códigos. E comunidades bem estruturadas deixam a parte grossa do trabalho (a criação das engines que exigem mais cabeça e poderiam gerar erros mais difíceis de arrumar e contornar) para programadores mais antigos e treinados. Fazer um projeto Open Source em Java para web não é uma boa escolha. PHP mata a pau!

Mesma coisa para alguns scripts simples e básicos, onde se deseja permitir que programadores iniciantes dêem suporte. Estes podem ser feitos em linguagens como Python, PHP, Jscript e outros.

Agora, basear um projeto pago numa linguagem assim, acho uma medida errada. A menos que o foco do projeto seja criá-lo e depois não expandí-lo, deixando apenas que ocorra suportes pontuais. Aí necessitaria de mão de obra menos especializada e PHP por exemplo volta a ser uma boa escolha.

E as linguagens compiladas são perfeitas?

Claro que não. Mas elas geralmente priorizam a coerência do que facilitar a vida dos desenvolvedores.

C++ é extremamente complicada de desenvolver, mas tem diversos frameworks para te ajudar a não sofrer com ponteiros, manipulação de memória etc. Mas até você montar o ambiente…

C# é perfeita, e na minha opinião a melhor linguagem exceto por um ou outro detalhe. Mas o que queima o filme é que a melhor ferramenta para desenvolver em C# é da M$ (Visual Studio .Net) , e é anos luz mais atrasada do que outras similares para outras linguagens. Fora isto, tirando o Windows não existe nenhum OS que tem uma VM que rode o C# redondo, aliás, nem a VM da MS roda o .Net de forma redonda (e eu sei bem pois trabalho com isso há 5 anos).

Java é antigo, velho. Tem diversos conceitos que na época não existiram e foi costurado com o tempo, tornando a linguagem um mundo de remendos. Mas é onde tenho a maior parte das bibliotecas e ele funciona praticamente igual em qualquer OS. Além é claro que tem o Eclipse para ajudar (e muito).

VB 6, até hoje uso para pequenos programas visuais. Ele é de desenvolvimento rápido mas ele é um pouco a lá script. Também não tem necessidade de declarar variáveis mas resolvo isso colocando na ide para forçar a declaração. De qualquer jeito, só recomendo se for um programa muito pequeno, nada de projetos grandes. Ou então, para dlls COM+ para projetos WEB usando ASP (alias ASP é outra tranqueira).

Como vê, apesar de preferir o C# em matéria de conceito, prefiro programar em Java exceto quando preciso fazer algo visual extremamente pequeno para plataformas Win ai uso VB. Também uso muitos scripts quando é em páginas WEB, para subir ou executar pequenos programas em unix, ou até para alterar programas que usam scripts lua, python, pearl etc. Não tenho motivos para preferir uma linguagem e puxar sardinha de nenhuma delas, mas não me verá criando um projeto do zero em PHP ou Python a menos que o cliente assim exija (e olha que fiz esta merda uma vez para ver se perdia a birra com linguagens scripts e me fudi muito).

Conclusão:

Eu acredito que as linguagens de scripts têm seus lugares bem definidos: scripts. Poderão tomar o lugar de linguagens sólidas como C, C++, C#, Java, VB, Delphy etc apenas quando o gasto de desenvolvimento (empurrado com a barriga para depois) for melhor controlado e contabilizado para que empresas sérias desenvolvam seus projetos sabendo o real custo dele. A partir daí, os demais problemas devem ser resolvidos gradativamente, até lá as linguagens compiladas sempre serão melhor aceitas em projetos grandes.

Scripts são voltados para ajudar o desenvolvedor e não a coerência, e na minha opinião DEVERIAM manterem esta filosofia. Pois scripts hoje são linguagens ótimas para ambientes onde se precisa de pessoas com pouca ou nenhuma experiência em programação para dar suporte, afinal ela é de fácil aprendizado e geralmente pouco exigente. No caso do PHP, é também uma linguagem boa para Opensource visto a facilidade de se achar servidores com suporte PHP e a facilidade de instalar aplicativos PHP em servidores apache (tente fazer o mesmo com #C ou com java para ver que trampo que dá).

Mas pare por aí. Dizer que o mundo move melhor com Python, Ruby ou PHP. Ou dizer que são linguagens praticamente perfeitas? Perfeitas para quem cara-pálida?

Então se você programa em linguagem script por favor, utilize o tempo que sobrou do seu projeto para tentar procurar os erros que o compilador deixou passar, em vez de usar para tentar convencer os demais programadores a trabalharem com a sua linguagem querida.

Sobre o título

O título do artigo é uma referência a uma carta de Dijkstra que criticava linguagens que tinham goto e que foi largamente difundida no meio com variações do nome de “Programadores de verdade não programam em Pascal”. Ou seja, não quero dizer que não existem programadores de verdade usando scripts, como Dijkstra na época também não queria dizer o mesmo de Pascal. Mas sim, como ele, dizer que a linguagem proporciona aberturas que podem ser muito mal usadas por programadores ruins e dando dor de cabeça para todos.

Carta de Dijstra em PT
Carta de Dijstra original (em EN)