Know Thy Tools!
Há alguns anos a minha linguagem de eleição era claramente o C... minimalista, elegante, consistente... o caminho certo para produzir software altamente performante e livre de gorduras, a forma de ter total controlo sobre a máquina sem ter de recorrer ao assembly*.
O Java era para os fracos... Os programadores a sério não têm medo de fazer mallocs e resolver segmentation faults. E as chamadas linguagens de scripting... só serviam para desenvolver código descartável ou automatizar pequenas tarefas, nada mais.
Hoje... Não deixei de considerar o C uma linguagem potente e elegante, mas deixei de o considerar a minha linguagem de eleição...
Como diz o Donald Knuth...
Na maioria dos casos o design é bem mais importante para a performance do que uns quantos ciclos de CPU poupados em cada chamada de função, ou uns quantos bytes de memória poupados à custa do controlo manual da alocação de memória.
Uma linguagem que facilite a implementação de bons algoritmos e boas estruturas de dados pode permitir chegar a um nível aceitável de performance, sem consumir demasiada memória. Tudo isto poupando muito tempo de programação, com muito menos erros, e com robustez acrescida**.
Noutros casos os pontos críticos para a performance do sistema estão bem definidos e podem ser desenvolvidos (em C) como módulos que expõem uma API para uma linguagem de mais alto nível, conseguindo-se o melhor dos dois mundos.
Podemos começar por desenvolver tudo em Python, por exemplo, e depois reimplementar os pontos críticos em C. Esta é, aliás, a forma como muitos dos módulos da biblioteca standard do Python são desenvolvidos...
E ainda existem aquelas situações onde os gargalos estão fora do âmbito da aplicação, e qualquer penalização imposta pelas linguagens de alto nível acaba por ser irrelevante... Não faz sentido perder muito tempo a optimizar código que vai estar quase sempre à espera de resultados vindos de uma base de dados.
Resumindo... hoje não tenho propriamente uma linguagem de eleição, tenho várias. Umas vezes será o C, outras vezes Java, outras vezes Python. Os requisitos de performance, o tempo disponível, e as características e complexidade do problema são factores importantes na escolha, e devem ser avaliados em conjunto.
* Não, nunca fui assim tão maluco...
** Levante a mão quem verificar o return value de cada
O Java era para os fracos... Os programadores a sério não têm medo de fazer mallocs e resolver segmentation faults. E as chamadas linguagens de scripting... só serviam para desenvolver código descartável ou automatizar pequenas tarefas, nada mais.
Hoje... Não deixei de considerar o C uma linguagem potente e elegante, mas deixei de o considerar a minha linguagem de eleição...
Como diz o Donald Knuth...
Premature optimization is the root of all evil.
Na maioria dos casos o design é bem mais importante para a performance do que uns quantos ciclos de CPU poupados em cada chamada de função, ou uns quantos bytes de memória poupados à custa do controlo manual da alocação de memória.
Uma linguagem que facilite a implementação de bons algoritmos e boas estruturas de dados pode permitir chegar a um nível aceitável de performance, sem consumir demasiada memória. Tudo isto poupando muito tempo de programação, com muito menos erros, e com robustez acrescida**.
Noutros casos os pontos críticos para a performance do sistema estão bem definidos e podem ser desenvolvidos (em C) como módulos que expõem uma API para uma linguagem de mais alto nível, conseguindo-se o melhor dos dois mundos.
Podemos começar por desenvolver tudo em Python, por exemplo, e depois reimplementar os pontos críticos em C. Esta é, aliás, a forma como muitos dos módulos da biblioteca standard do Python são desenvolvidos...
E ainda existem aquelas situações onde os gargalos estão fora do âmbito da aplicação, e qualquer penalização imposta pelas linguagens de alto nível acaba por ser irrelevante... Não faz sentido perder muito tempo a optimizar código que vai estar quase sempre à espera de resultados vindos de uma base de dados.
Resumindo... hoje não tenho propriamente uma linguagem de eleição, tenho várias. Umas vezes será o C, outras vezes Java, outras vezes Python. Os requisitos de performance, o tempo disponível, e as características e complexidade do problema são factores importantes na escolha, e devem ser avaliados em conjunto.
* Não, nunca fui assim tão maluco...
** Levante a mão quem verificar o return value de cada
scanf, ou de cada write, em C... O que acontece à vossa aplicação se a função retornar sem ter processado todo o input, ou sem ter escrito a totalidade do buffer? E para quem levantar a mão... Conseguem ver código útil no meio de toneladas e toneladas de error handling?
Carlos Rodrigues - 14.6.06 |
permalink
Eu posso até nem ter muita experiência em programação (apesar de já conhecer algumas linguagens de vários tipos como as faladas no artigo), e uma das coisas que consegui meter logo na cabeça foi: para cada situação, uma linguagem. No entanto, vejo que há por aí muita gente com muito mais experiência e que deveria avaliar muito melhor as situações e não o sabem fazer. Umas vezes por teimosia, outras vezes pelas chamadas "pet languages", outras vezes por...sei lá...estupidez ?
Um dos excelentes exemplos é o actual panorama do desktop linux, em que muitas boas novas aplicações estão a ser implementadas nas linguagens erradas, como por exemplo muitos dos novos media players "itunes like". Se é uma aplicação que vai estar grande parte do tempo a correr para quê estar a implementá-la em algo como python (quodlibet, exaile...)? Não que eu não goste do python, mas acho que no caso é perfeitamente inútil.
Por
Tiago Rodrigues, em 14 Junho, 2006 03:07
O desktop realmente é uma área onde existem requisitos particulares de performance. As aplicações não têm de ser rápidas (em termos de velocidade de cálculo) mas têm de permitir tempos de resposta adequados, e têm de evitar roubar CPU a outras aplicações que possam estar a correr em simultâneo.
No entanto, pode ser perfeitamente aceitável fazer um media player em Python... Os pontos críticos (a framework multimédia e o toolkit gráfico) são desenvolvidos em C, e é aí que a aplicação vai passar quase todo o tempo, o resto é cola e não contribui significativamente para a sensação de lentidão.
O problema é a crescente lentidão dos toolkits gráficos em Linux (pelo menos do GTK, onde a mudança para o Cairo piorou as coisas neste aspecto).
O que tu sentes como lentidão vinda do Python, provavelmente é resultado de um dos erros mais frequentes no desenvolvimento de aplicações gráficas: falta de feedback instantâneo para cada operação.
Eu noto isto especialmente em aplicações desenvolvidas em Java... A malta tende a pensar que o SWING é irremediavelmente lento, mas eu já vi aplicações SWING muito rápidas e agradáveis de usar, simplesmente porque quem as desenvolveu teve o bom senso de partir o processamento útil em fatias comestíveis, evitando pendurar a interface por mais de alguns milisegundos.
Um dos melhores exemplos de como uma aplicação de grandes dimensões pode ser desenvolvida numa linguagem interpretada e ainda assim ser (suficientemente) rápida é o Firefox, que usa um misto de Javascript, CSS e XML (o XUL). Tudo isto porque os pontos críticos estão implementados em C sob a forma do motor XULRunner, composto por peças como o Gecko (parser CSS/HTML/XML), Necko (rede), etc., etc..
Eu não concordo com a malta que diz que hoje em dia podemos deitar ciclos de CPU fora só porque temos máquinas muito mais potentes do que há apenas 10 anos, porque o software tem tendência para se expandir até ocupar todos os ciclos disponíveis...
Mas também estamos a tentar hoje resolver problemas bastante mais complexos do que há 10 anos, e com prazos bastante mais apertados. Com estas restrições, o C deixa de ser mais do que uma linguagem para implementar primitivas, e sacrificar 10% de performance no código "cola" também não vai tirar o sono a ninguém (até porque, se esse código fosse desenvolvido em C também acabaria por ser ineficiente, já que ninguém iria perder tempo a optimizá-lo e, com um pouco de sorte, a "inteligência" dos interpretadores/VMs acaba por conseguir optimizar o que o programador não optimizou).
Por
Carlos Rodrigues, em 14 Junho, 2006 12:46