Python import
Postado por Osvaldo Santana
Ao começar a trabalhar no desenvolvimento do Python para Maemo no INdT a gente percebeu que o CPython não apresentava problemas sérios de performance no 770 e que uma das poucas coisas que realmente incomodava era a demora para importar alguns módulos importantes na plataforma (principalmente o PyGTK).
Quando iniciamos a segunda fase do nosso projeto decidimos atacar a otimização da plataforma Python em duas frentes: uma na linha de pesquisa que daria resultados a longo prazo e uma outra com foco mais prático no CPython.
Eu assumi a segunda linha enquanto o Rafael Espíndola, que trabalha com a gente, assumiu a linha mais acadêmica (além de me dar uma ajuda valiosa com alguns testes que requerem mais conhecimento técnico). Esse trabalho envolve a criação de um backend ARM para o LLVM e posteriormente melhorar o backend LLVM do PyPy para que com essas duas ferramentas seja possível gerar código binário nativo para ARM a partir de código fonte Python.
Como o maior problema de performance do CPython no 770 era relacionado ao carregamento de módulos resolvi atacá-lo primeiro e para atacá-lo fui entender como ele funcionava. Não gostei muito do que vi.
Aparentemente o sistema de ‘import’ do Python nunca recebeu uma atenção muito grande e desde o começo ele vem recebendo patches em cima de patches. Muitas funcionalidades foram adicionadas sem muito planejamento ou, por manter compatibilidade retroativa, tiveram implementações pouco elegantes.
Decidi então fazer uma reforma nesse sistema tentando deixá-lo mais elegante e ao mesmo tempo não tentar quebrar compatibilidade retroativa gratuitamente.
Como estou interessado nessa parte do desenvolvimento do CPython eu me ofereci para ajudar o Brett Canon em uma das tarefas propostas para o Python Google Sprint. Infelizmente o Brett tinha outras prioridades para esse Sprint e pode se oferecer apenas para me ajudar quando eu precisasse. O Guido, por sua vez, também pediu para eu adicionar meu nome na tarefa.
Durante o período do Sprint eu desenvolvi um esboço (bem inicial e incompleto) do que eu planejava para que eles pudessem entender que rumo eu gostaria de seguir.
Mostrei o meu trabalho para o Brett e ele me diz que o que ele planejava era algo bem mais simples que serviria já para o 2.6 e consistia apenas em reescrever a função __import__() em Python e que o meu plano era maior e certamente não seria aceito para a série 2.6.
Me apontou também a PEP-302 onde algumas das minhas idéias já foram discutidas e não foram aceitas (principalmente por adicionarem incompatibilidade retroativa). E disse que como os nossos planos eram muito diferente ele iria trabalhar nos planos dele mas que continuaria me ajudando se eu precisasse.
A sensação que eu tenho é a de que eu devo seguir adiante com esse plano meu nem que seja para facilitar o nosso trabalho no Python para Maemo. Depois que tudo estiver pronto e funcionando eu vou escrever uma PEP e submeter na lista python-3k.
Se for aceito, legal. Se não for, paciência. Só espero que eles entendam o que eu quero com esse projeto e não façam como fizeram com o Gustavo Niemeyer quando ele propôs a inclusão do dateutil na biblioteca padrão do Python (por não terem entendido a proposta do módulo optaram por miná-la ao invés de entendê-la).
ITopia
Postado por Osvaldo Santana
Trabalho na área de informática há muitos anos. Sempre trabalhei com desenvolvimento de software, exceto por um período de tempo quando tentei seguir a carreira de publicitário por estar um pouco decepcionado com o trabalho na área de programação de computadores.
A minha desilusão nasceu com o tipo de trabalho que um programador, aqui no Brasil, mais faz: software de gestão empresarial. A capacidade criativa que o brasileiro desenvolveu nesse tipo de desenvolvimento causa inveja em diversos países do mundo. Isso é bacana.
Esse tipo de desenvolvimento nunca foi meu preferido mas eu devo admitir que sempre foi o que fizemos de melhor.
Mas de um tempo para cá eu venho notado que as empresas de desenvolvimento de software estão procurando buscar modelos de desenvolvimento de software vindos de fora. Opa! Se esse é o tipo de coisa que sempre fizemos bem aqui não deveríamos estar exportando?
O modelo de empresa de desenvolvimento que me deixa mais horrorizado é o triunvirato formado por engenharia-de-software, fábrica-de-software, STLs (sigla-de-três-letras como CMM, RUP e PMI).
Quando eu estudava Processamento de Dados em um colégio técnico estadual no interior de São Paulo eu tinha vários amigos que estudavam ‘Edificações’ que forma profissionais preparados para auxiliar os Engenheiros Civis. Alguns alunos amigos meus eram tão bons em seus trabalhos que os engenheiros somente ‘assinavam’ os projetos feitos por eles.
Se nessa época a minha visão-além-do-alcance me mostrasse o que está acontecendo hoje eu iria estudar Edificações e não mais Processamento de Dados. Estou esperando o dia que vão surgir os decoradores de sistemas, afinal, os engenheiros de software e arquitetos de software já existem.
Esse triunvirato parte da premissa de que software é algo criado em cima de padrões, normas e requisitos e esquecem de que essas três coisas produzem software mas nunca irão produzir software fantástico. O que diferencia um software de um software fantástico é o ‘toque de genialidade’ dos desenvolvedores. É aquela modificação elegante no código que o torna mais eficiente. É aquela idéia simples que torna o sistema mais robusto. É aquele momento de inspiração que faz surgir um excelente software. É aquela fuga do padrão, da norma, e até mesmo do requisito que fazem um software virar um software fantástico.
Os softwares de gestão brasileiros são (eram?) fantásticos por essa razão. Antes as normas eram menos rígidas, os padrões menos abrangentes e os requisitos quase sempre eram desconhecido. Sei que muito software ruim foi produzido naquela época mas tolher a criatividade não deve ser a solução para esse problema. Que solução então? Seleção natural. É isso. Software ruim ‘morre’ com o passar do tempo. Software que nasce ruim mas melhora com o passar do tempo sobrevive.
Para resumir, o desenvolvimento de software é, em minha opinião, muito mais uma atividade criativa do que simplesmente aplicar técnicas, regras, normas em cima de um teclado de computador.
Minha forma de pensar leva à uma outra questão importante a ser ponderada: Programador sem criatividade deve mudar de profissão? Sim e não.
Se ele está nessa área porque disseram para ele que “programador é a profissão do futuro” sim. Todas as pessoas devem fazer o que gosta e não o que disseram para ela fazer. Trabalhar com algo que não te inspira cria pessoas tristes. E não vale falar que vai continuar programando porque ‘não agrada nem desagrada’, tem que gostar mesmo de trabalhar.
Mas se esse programador ‘não-criativo’ realmente tiver paixão pela profissão que vai exercer o problema de criatividade dele pode ser solucionado.
“Moço! Me vê 2kg de criatividade?”
As pessoas acham que um ‘insight criativo’ é o resultado de um sopro de pó de pirlim-pim-pim que a Fada Sininho jogou na gente. Isso não é totalmente verdade (exceto talvez pela fada).
Os ‘insights criativos’ são criados pelo nosso cérebro o tempo todo (em momentos randômicos). O nosso cérebro então coleta uma série de informações dos nossos ‘bancos de memórias’ de acesso rápido (informações), acesso lento (conhecimento) e do disco (lembranças), bate tudo por uns minutos no liquidificador e joga no ‘pipeline’ de coisas em processamento. O resultado dessa mistura, se for bom, será aproveitado, caso contrário será descartado imediatamente.
Com essa explicação podemos perceber que uma série de fatores aleatórios que determinam se você terá um ‘insight criativo’.
Quando você vai apostar na mega-sena (ou outro jogo desse tipo) você sabe que quanto mais números você marcar no canhoto de apostas maiores serão as suas chances de ganhar o prêmio. O mesmo acontece com nosso cérebro. Quanto mais informação, conhecimento e lembranças a gente tiver para que o nosso cérebro trabalhe maiores são as nossas chances de ter uma idéia legal.
E é aí que entra o fator ‘paixão’ pela profissão. Se você for apaixonado pelo que faz será mais fácil para você ler um livro sobre o assunto, fazer um treinamento, prestar atenção às informações relacionadas ao teu trabalho e assim por diante.
É claro que existem alguns programadores que são absurdamente geniais e criativos, mas eles são uma exceção (boa) e não são reproduzíveis em laboratório.
Tem que ter técnica!
Dizer que o importante é ser criativo não pode levar ninguém a concluir que a técnica é dispensável. Não é mesmo. A técnica é tão importante quanto a criatividade. Ambas devem ser desenvolvidas por igual e nutridas da mesma maneira. A técnica fornece elementos para que a loteria criativa do cérebro crie coisas legais que, através da técnica irão virar realidade; um ciclo fechado.
Não pense que Da Vinci usou só de criatividade para pintar a Monalisa. Se ele não tivesse conhecimento de sombras, luzes, cores, anatomia, etc. certamente ele não teria criado essa obra de arte.
