A próxima linguagem a aprender

January 21st, 2008 § 10 comments § permalink

O Daniel Martins elegeu Python como a linguagem que vai aprender durante esse ano. Ele é fã de Java, que eu não tolero, e acho que Python é uma boa escolha depois de uma linguagem estática em todos os sentidos.

Mas, mesmo sendo um fã de Java, o Daniel tem um ponto legal em seu texto:

Felizmente, não me arrependo de nenhum programa que fiz, de nenhuma certificação que tirei e de nenhum livro que li. O simples uso do Java me ensinou coisas que eu provavelmente nunca aprenderia caso escolhesse outra linguagem. Em outras palavras, Java me ensinou uma coisa que poucos sabem (ou muitos ignoram): é difícil fazer software.

Isso é algo que eu sempre repito quando estou falando de linguagens: todas são valiosas e você pode aprender alguma coisa com qualquer uma delas desde que procure problemas interessantes para resolver. Embora eu respeito muito o trabalho de Edsger W. Dijkstra, eu discordo completamente de sua asserção de que aprender Basic mutila a mente de um programador–principalmente depois de começar a ler Beautiful Code, onde um dos capítulos mais interessantes (o de número 30; veja o sumário no endereço anterior) usa Visual Basic 6 como ferramenta primária.

Mas estou me desviando do que eu queria escrever. Embora eu também defenda a prática de aprender uma nova linguagem por ano, nos últimos três anos, principalmente por causa do meu trabalho primário na minha própria empresa, eu me limitei a incrementar o meu conhecimento de C# e Ruby. Já está passando da hora de progredir em algum outro campo.

O ano passado me deixou bem interessado em Erlang, Scala e Io. As três são boas opções e estão ganhando momentum entre os partidários de linguagens dinâmicas, o que significa que material bom está começando a aparecer.

O foco de Erlang é em processamento multi-tarefa e de alta disponibilidade. É um campo interessante, e eu tenho um certo interesse nas possibilidades por trás do mesmo e até algumas aplicações possíveis para a parte de multi-tarefa escalável.

Scala é uma linguagem derivada do Java, o que tira um pouco a graça da mesma. Mas o fato de ter características funcionais e ser mais parecida com Ruby do que Java nesse sentido é um bom atrativo. Rodando sobre a JVM, provavelmente oferece a melhor possibilidade de ser usada como uma linguagem de scripting e integração com bibliotecas externas.

Io é bem interessante, sendo baseada em protótipos e contendo uma série de características fascinantes com um interpretador bem pequeno e extensível. Além disso, tanto a extrema reflexibilidade como a forte meta-programabilidade são atrativos enormes. A sintaxe não é lá essas coisas, mas dá para agüentar. Eu tolero Ruby, com seus sublinhados e inconsistências e poderia muito bem tolerar Io cuja BNF é minúscula.

Além dessas três, há Haskell que eu comecei a aprender há dois anos e acabei deixando de lado também quando o .NET se tornou o foco principal do meu trabalho. Haskell me atrai por ser puramente funcional mas a dificuldade que a mesma tem de servir como uma linguagem genérica é um pequeno empecilho.

Io me parece a mais interessante no momento porque parece oferecer a maior possibilidade de trabalhar as idéias sobre DSL e meta-programação que estão aparecendo em meu radar agora. Por outro lado, é bem imperativa e eu gostaria de algo um pouco mais funcional. Mas a parte de meta-programação deve vencer.

Algo que eu gostaria de ter também é a possibilidade de escrever uma GUI portável sem maiores problemas. Nesse quesito eu não sei absolutamente nada sobre as linguagens mas é o que pretende explorar agora.

Outras opções são Lua, Rebol e Objective-C mas essas provavelmente só se eu acabar rejeitando as opções anteriores. Hora de estudar um pouquinho mais.

A anomalia Pioneer

January 21st, 2008 § 6 comments § permalink

Por volta de 1998 ou 1999, eu me lembro de ter ficado intrigado com um relatório sobre as missões Pioneer 10 e Pioneer 11 que indicava que as duas sondas estavam sofrendo ligeiros desvios de velocidade e trajetória em seus continuado caminho para fora do Sistema Solar.

O relatório causou bastante especulação na época e vários explicações foram dadas incluindo erros de interpretação de dados, vazamentos minúsculos de gás, e, é claro, influência alienígena. Vários testes foram feitos e várias explicações descartadas, mas não se chegou a nenhuma conclusão.

O que eu não tinha percebido na época, e só descobri recentemente, é que o efeito estava sendo observado também na Galileo e Ulysses, lançadas bem depois e em vetores completamente diferentes. De lá para cá, o fenômeno, que ganhou o nome popular de Pioneer Anomaly já foi estudado exaustivamente e sua soluções continua a eludir a comunidade científica. Vários esforços estão sendo feitos para normalizar dados de várias missões e finalmente descartar artefatos nas leituras de dados, buscando então uma solução real se essa existir.

Enquanto isso não acontece, vários físicos estão propondo soluções principalmente considerando que várias das novas missões–Rosetta e Cassini-Huygens incluídas–estão experimentando efeitos similares. É possível também que a sonda New Horizons, que está a caminho de Plutão, possa ser usada para verificar algumas embora muito do que se pode fazer dependa de fatores quase que imprevisíveis.

Obviamente, eu estou muito curioso sobre futuros desenvolvimentos relacionados ao problema e achei incrível um novo trabalho publicado recentemente que sugere que as anomalias possam ser causadas por algo conhecido como radiação Unruh. Eu não pretendo dizer que entendo um décimo do que o artigo está falando, mas aparentemente, corpos sendo acelerados além de um certo limite experimentam mudanças inerciais causadas por essa radiação cujo comprimento de onda em baixas acelerações é maior que o diâmetro do Universo. As mudanças são consistentes com o que foi observado nas sondas, embora as conclusões ainda sejam completamente teóricas.

É nessas horas que eu sinto vontade de fazer um curso de física ou astronomia. O Universo é certamente um local extremamente fascinante.

Twitter: o teste de meia hora

January 20th, 2008 § 11 comments § permalink

Escolha randomicamente entre as pessoas que você segue, e assim por diante com cada pessoa escolhida. Repita por meia hora ou até que você saia do nerddom.

Interessante o resultado, não?

Kenna

January 19th, 2008 § 0 comments § permalink

A leitura de Blink acabou rendendo uma outra pequena surpresa. Um dos exemplos citados por Malcolm Gladwell é o músico Kenna que, segundo o autor, é um artista excepcional mas cujo talento vai contra o que o mercado espera embora entendidos consigam perceber de imediato o seu potencial.

Resolvi ouvir alguma coisa de Kenna e gostei tremendamente. Gladwell não estava enganado ao dizer que a música de Kenna é virtualmente inclassificável e que é uma mistura muito poderosa de vários estilos. As combinações são muito bem pensadas e se mesclam casualmente de uma forma que é bem satisfatória.

As músicas que eu estou ouvindo são do segundo álbum, Make Sure They See My Face e a variação é espantosa.

A primeira música, por exemplo, se chama Daylight e abre com um trecho bem New Age que logo evolui para uma mistura de eletrônica e soul que mais tarde vai se transformar em um rock operático.

Be Still, por outro lado, é bem soft com as características melódicos de um rock mais tradicional e algumas pontas de um synth pop bem leve.

As demais músicas apresentam composições similares que incluem hip hop, house and uma série de outras influências muito bem trabalhadas. A influência de U2 está bem visível em <Sun Red, Sky Blue e isso dá um toque adicional à música que eu gostei bastante.

No geral, uma adição muito boa ao meu conjunto de artistas interessantes. Vale a pena dar uma explorada se você gosta dessas misturas.

Um novo paradigma em desenvolvimento Web

January 18th, 2008 § 8 comments § permalink

Ruminando nos últimos dias sobre o futuro do desenvolvimento em especial, pensando sobre o que eu andei escrevendo sobre testes e linguagens específicas de domínio, e principalmente sobre as coisas que tem chamado a minha atenção nos últimos tempos no campo, eu fiquei surpreso ao perceber que por mais que estejamos falando em novos paradigmas, nenhuma aplicação ou framework está explorando os conceitos mais novos de maneira significativa.

O histórico do área é abismal, é claro. Já estamos beirando os quarenta anos desde que alguma mudança significativa de paradigma aconteceu, e quase vinte anos desde que práticas mais estruturas se tornaram a base do que fazemos hoje. Apesar disso, a indústria permanece estagnada no campo minado que orientação a objetos, bancos relacionais, e design bottom-up representam.

Pensando em desenvolvimento Web, por exemplo, por mais inovadores que Rails e Django sejam, os dois possuem duas características que os tornam completamente inúteis a longo prazo.

A primeira característica é a fragmentação conceitual. Na tentativa de tornar o desenvolvimento “indolor”, esses dois frameworks e seus descendentes diluem o domínio da aplicação em uma série de pequenos pedaços que, embora representem uma forma mais gerenciável de desenvolvimento, também tende a criar uma desconexão entre o código e aquilo que ele deve representar.

A segunda característica é a fixação em soluções constritas. O uso de REST pelo Rails é um bom exemplo disso. Embora REST seja um conceito interessante e mesmo necessário para uma classe de aplicações, a implementação do Rails é limitada, dependente de truques, e sofre da mesma fragmentação citada acima.

De fato, muito do que a maioria dos frameworks modernos estão fazendo é pretender que a complexidade não existe ou que ela pode ser gerenciada com o uso de métodos pequenos e testes.

Desenvolvimento guiado por testes, ao contrário do que se prega atualmente, não é uma bala de prata. Antes, é mais uma prática que está sendo transformada através de uma falta de compreensão em uma panacéia–como algo, inclusive, que pode guiar o design de sua aplicação até o ponto em que não é necessário fazer uma análise apropriada do domínio do problema. A quantidade enorme de exemplos mostrando como testar algo que, por definição, já está testado é insana. Eu sou tão culpado quando o próximo programador ao fazer isso em minha própria documentação.

E por mais que eu defenda Seaside, por sua aplicação inovadora de conceitos antigos e por sua recusa em se ater às soluções supostamente provadas, o fato é que, a exemplo dos outros frameworks, Seaside também não é uma solução que parte de premissas radicalmente diferentes das que a indústria tem oferecido nos últimos anos.

Algo que está me dando esperança de que as coisas podem mudar logo é o interesse em programação orientada a linguagens. Se isso se transformar em uma característica dominante das linguagens que estão crescendo hoje, podemos experimentar uma renovação conceitual nos próximos anos.

Talvez o que precisamos é de uma forma de gerar especificações executáveis que seja realmente uma forma de criar aplicações e não uma maneira inferior de modelar o comportamento esperado de uma aplicação. Isso é algo para se pensar.

Talvez aqui esteja uma meta para esse ano: tentar descobrir uma forma de combinar as peças que estão soltas, peças geradas nos últimos vinte anos que parecem estar a uma pequena distância de uma revolução. Alguém de habilita?

Meta

January 18th, 2008 § 4 comments § permalink

Como a maioria dos leitores deve ter notado, o ritmo de postagem está um pouco diferente esse ano. Eu estou tentando manter uma certa regularidade, com uma forma de gerar um diálogo constante de idéias–até comigo mesmo–e o objetivo é fazer isso durante os próximos meses e ver o que acontece.

Por outro lado, como meus interesses estão meio divididos entre tecnologia e outros assuntos completamente não técnicos, eu reconheço que alguns leitores podem preferir uma visão mais específica do blog. Para isso, eu separei os textos em dois tags diferentes: tecnologia e miscelânea.

Sendo assim, se você prefere ler somente um tipo dos textos que eu produzo, basta assinar o feed respectivo, seja o de tecnologia ou o de miscelânea.

É claro que se você quiser continuar assinando o principal, eu não estou reclamando. É somente uma opção para leitores tão dedicados quanto vocês. Se eu acreditar nos números dos logs, acho que vocês já estão em número suficiente para poderem exigir alguma coisa. :-)

Testando agressivamente com Ruby

January 17th, 2008 § 0 comments § permalink

Um dos maiores problemas com o desenvolvimento guiado por testes é saber se você está testando o que realmente interessa. Muitas vezes, detalhes triviais de como um determinado trecho de código é implementando tornam os testes completamente inúteis sem que você perceba.

Um ferramenta cobertura, por melhor que seja, é inútil nesse momento porque ela pode dizer somente que o código foi executado mas não de que forma foi executado. Condições de inicialização e valores assumidos são especialmente perigosos no que tange a essa faceta de TDD.

Uma ferramenta que está se tornando essencial para mim nos últimos tempos é o Heclke. O Heckle é um testador de mutações. O que ele faz é modificar seu código de maneiras inusitadas e rodar os testes novamente para ver se os mesmos ainda estão passando. Não é uma ferramenta perfeita–há momentos em que as mutações realmente são inúteis ou em que os testes entram em um loop infinito–mas já faz um trabalho enorme em identificar potenciais caminhas não tratados no seu código.

A instalação é simples:

sudo gem install heckle

E o uso também é bem simples:

heckle class_name [method_name] -t [test_file]

É possível usá-lo também com RSpec:

spec spec_file --heckle class_name[#method_name]

O nome do método é opcional e se não for informado, todos os métodos da classe serão modificados. Os testes podem levar um tempo maior para rodar nesse caso mas os resultados são bem positivos.

Para um exemplo mais detalhado, leia o texto do anúncio original do Heckle. O programa atualmente é bem mais sofisticado mas o princípio é o mesmo.

O efeito ASP

January 16th, 2008 § 13 comments § permalink

Muito do meu desenvolvimento diário, para minha infelicidade, ainda é feito em aplicações legadas em ASP e PHP. Desnecessário dizer, não é um trabalho muito agradável mesmo quando a aplicação foi construída com um cuidado maior do que simplesmente gerar arquivos e mais arquivos em uma tentativa de trazer ordem ao caos.

Aplicações ASP são capazes de infligir terror ao mais corajoso desenvolvedor Web. A mistura de lógica e apresentação vem sendo usada há vários anos para exemplificar o que há de pior da área e não sem razão. Atualmente, para falar a verdade, é muito raro que eu aceite um contrato de manutenção ASP se a aplicação não atende certas práticas que eu estabeleci como referência. O trabalho simplesmente não vale a pena, por melhor que seja o pagamento.

Nos últimos anos, é claro, eu tenho tentado me dedicar mais e evangelizar, sempre que possível, novos modelos e frameworks de desenvolvimento. Nem sempre a empresa aceita mudar para algo que ela considera esotérico e fora da realidade do mercado, mas algumas vezes a vontade de reduzir o time-to-market vence o medo e algo de interessante acontece.

Estamos hoje há mais de três anos do início da evolução do desenvolvimento Web que frameworks como Rails e Django começaram e acho que estamos começando a ver os reais efeitos que o desenvolvimento nestes novos paradigmas está tendo. O uso de MVC está se tornando uma constante e mesmo a questão de desenvolvimento guiado por testes está se firmando como algo mais comum em locais onde usualmente se via um processo menos elaborado.

Nos últimos tempos eu tenho recebido alguns propostas para completar ou manter aplicações Rails já existentes e estou surpreso com a baixa qualidade do que estou vendo. De fato, no que tange a falta de cuidado com o código e a mistura de lógica e apresentação, eu só não compararia o nível dessas aplicações ao que usualmente vejo com ASP porque pelo menos a parte de convenção versus configuração segura os abusos mais berrantes.

Eu ainda não tenho dados suficientes para dizer a mesma coisa de Django, mas é possível notar um pouco disso nas aplicações e projetos espalhados pela Web que pouco cuidam em promover técnicas como TDD ou mesmo um reuso mais efetivo de código. E quanto promovem, o que se vê são usos pouco significativos dessas técnicas como a eterna persistência em testar o funcionamento de camadas ORM. Isso é válido também para quase todos outros framework Web, independentemente de linguagem e estruturação.

Parte do motivo desse uso incorreto é explicada pela soma de dois fatores distintos: o fato de que poucos programadores são realmente capazes de entender o que OOP significa e o fato de que Rails, Django e todos esses outros frameworks promovem uma versão mais light, por assim dizer, de OOP que efetivamente isola muitos programadores de um desenho mais efetivo do domínio do problema.

Eu fico pensando no mercado daqui a cinco anos, quando o mesmo estiver inundado de aplicações nesses novos frameworks. Provavelmente, não haverá diferença nenhuma em termos de manutenção para o que vemos hoje. Aplicações realmente bem feitas permanecerão confinadas a um pequeno conjunto dentro da indústria. Um efeito ASP em ação.

A revolução ainda espera e Frederick Brooks continua mais válido do que nunca. Rails e Django podem ser indolores no começo, mas eu tenho pena dos programadores que terão que manter o que está sendo criado hoje.

O outro lado de Mercúrio

January 16th, 2008 § 7 comments § permalink

Depois de executar o seu primeiro fly-by em torno de Mercúrio, a sonda MESSENGER começa a retornar as primeiras fotos e elas são impressionantes.

A MESSENGER é a primeira sonda a visitar Mercúrio em 30 anos e começou sua missão em 2004. O fly-by executado ontem é o primeiro de três ao redor do pequeno planeta e a inserção orbital só acontecerá no começo de 2011. Mas, mesmo que o começo real da investigação de Mercúrio esteja distante, os resultados intermediários já estão valendo a pena.

A foto mostrada aqui (clique na mesma para versões maiores e mais informações) foi tomada de uma distância de 27 mil quilômetros e mostra um lado do planeta que ainda não havia sido visto nas outras vezes em que sondas visitaram o planeta por causa de suas trajetórias diferentes em relação ao modo como Mercúrio orbita o Sol.

Em preto e branco, Mercúrio se parece muito com a Lua, bombardeado e cheio de crateras, mas o site da missão está prometendo fotos coloridas que vão revelar em detalhe muito maior as características da superfície do menor planeta do Sistema Solar.

Eu confesso que fico completamente empolgado com essas missões. Eu passei o ano novo de 2000 acompanhando a Cassini e torcendo para que tudo desse certo no fly-by de Júpiter. Mercúrio é um planeta basicamente desconhecido e acompanhar as explorações dos próximos anos vai ser algo fascinante.

Caneta e Papel

January 15th, 2008 § 6 comments § permalink

Nessa era de computadores, muitos escritores migraram da caneta e papel para suas versões eletrônicas. Eu tenho um amigo que, depois de trabalhar por uma década no campo de tecnologia educacional, não consegue escrever a menos que esteja na frente de uma computador. Ele simplesmente perdeu o costume de usar uma caneta e sua mão dói, literalmente, se ele precisar usar uma por mais que alguns minutos.

Qualquer escritor, é claro, pode se beneficiar de uma bom processador de texto. Familiaridade com um editor preferido pode incrementar o processo de colocar as palavras no papel removendo muito do trabalho braçal de organizar o que está sendo escrito e deixando mais tempo para o que importa. O processo de edição, em especial, é muito mais fácil em um processador de texto com as funcionalidades para tal.

Eu sou um programador por profissão, o que significa que eu passo um tempo enorme da frente de computador. Sendo também um escritor, não no sentido publicado mas no de alguém que gosta de escrever, eu tendo a usá-los também para escrever. Especialmente quando eu estou escrevendo algo em inglês, uma segunda linguagem, um computador oferece vários recursos para lidar com as eventuais dúvidas ortográficas e gramaticais. A Internet, é claro, é uma ferramenta essencial.

Com tanto incentivo, é fácil ver porque muitos escritores preferem exercer sua profissão através de máquinas. É uma questão simples: caneta e papel tem um propósito única; um computador, por outro lado, é adaptável aos hábitos do escritor.

Algum tempo atrás, lendo uma entrevista já antiga com Neal Stephenson sobre o seu Baroque Cycle, que estou lendo no momento, fiquei surpreso ao descobrir que ele, extremo conhecedor e usuário de tecnologia, escreveu os livros à mão. Stephenson, que chega a programar macros para formatar seus livros no Emacs, achou que seria anacrônico escrever no computador sobre uma época onde só havia pena e papel para o mesmo tipo de tarefa e resolveu experimentar escrevendo à mão. Gostou do modo como o processo funcionou e o resto é história.

Embora os motivos de Stephenson sejam específicos para a série e ele provavelmente volte ao computador para seus próximos livros, eu fiquei intrigado com a descrição que ele fez do seu fluxo de trabalho e resolvi experimentar. Eu tinha uma idéia para uma estória curta sobre sonhos e memória e decidi escrevê-la inteiramente à mão. Comprei uma caderno e uma caneta confortável e me lancei ao trabalho.

No começo, achei o processo lento e pouco produtivo. Depois de usar tanto o computador e conhecendo minha velocidade, escrever com uma caneta parecia um retrocesso. Além disso, eu gosto de começar a editar o texto desde sua primeira versão. No computador, isso é uma mera questão de mover e remover texto. No caderno, o resultado foi quase uma página inteira de palavras e frases cortadas na primeira tentativa. Dez páginas depois, eu percebi que estava cortando quase tudo que escrevia. O texto que escapara aos cortes não daria duas páginas.

Decidi então esquecer o processo de edição e focar somente em escrever. A mudança no fluxo de escrita foi impressionante. As palavras começaram a fluir como nunca, seguindo a estória em minha mente de maneira mais rápida e mais concisa do que eu conseguiria de outra forma. Resistindo à ânsia de editar, eu descobri que cada sessão com o caderno e caneta rendiam muito mais do que no computador. E, surpreendentemente, com exceção do maior número de erros comuns de ortografia e gramática, remediados com facilidade na transcrição, a qualidade do que eu estava escrevendo não parecia ter mudando substancialmente. O processo de edição estava acontecendo inconscientemente no caderno ou estava exagerando no computador.

Eu não sei se continuarei a usar um caderno para escrever. Foi uma experiência muito boa, e que resultou em uma estória terminada em menor tempo. Mas eu não acredito que o problema seja o computador. Antes, é minha vontade de produzir boa prosa na primeira passagem. No caderno, me forçando a esperar, eu me concentro mais na estória e o resultado é melhor do que ficar me questionando frase a frase no computador. A facilidade de editar e reorganizar o texto exaustivamente talvez não seja o ideal para mim.

Seja o que for que eu venha a descobrir desses experimentos, uma coisa é certa: escrever à mão me fez sentir muito mais próximo do ato de criação. Digitar um texto no computador parece algo um tanto distanciado da realidade de ouvir uma caneta traçar linhas cada vez mais completas na superfície de uma folha. Talvez seja minha falta de experiência, talvez seja a novidade da situação, mas certamente a experiência me pareceu mais concreta–como seu eu pudesse ouvir a musa sussurrando em meus ouvidos, ao invés do tedioso e frio som de um teclado se espalhando pelo ar de uma forma completamente alienígena à pureza do momento.

Where am I?

You are currently viewing the archives for January, 2008 at Superfície Reflexiva.