Perigos de cada linguagem

Cada linguagem de programação induz um tipo de comportamento no programador, por exemplo perl induz à gambiarras, já java induz over-engineered e Lisp induz a reescrita de código (Porque usar X se eu posso reimplementar isso em Y dias).

Não que esses comportamentos sejam obrigatórios nessas linguagens, mas existe uma cultura e uma facilidade de se agir segundo o esteriótipo de cada linguagem. Por exemplo, o perl permite programação OOP, mas não é fácil nem tão pouco elegante e esse é um motivo para que a maioria dos programadores em perl não use OOP. Porém o principal motivo é cultural, programadores em perl valorizam resolver o problema rapidamente, mesmo que para isso tenham que fazer um copy-and-paste do código, já programadores em Java criam soluções genéricas e complexas que precisam de 3 arquivos XML para serem configuradas porque eles ficariam com vergonha do código se fizessem de outra maneira.

Por isso é importante dominar mais de uma linguagem, para poder saber quando é necessário programar em Java como se fosse perl ou Lisp. Dizem que um programador em Fortran pode programar Fortran em qualquer linguagem, um bom programador também pode programar em Fortran em qualquer linguagem, a diferença é que ele sabe quando fazer isso.

MySQL Anoyances

Descobri mais uma amolação do MySQL, o nome das tabelas é case sensitive. Até ai, nada de muito grave, muitas linguagens de programação são case sentives e as pessoas se habituam a utilizar convenções, porém, o MySQL só é case sensitive se o filesystem o for (lembrem-se que no MyISAM cada tabela é um arquivo), ou seja, o programa idiota passa para a o fopen o nome da tabela como o usuário digita no SQL.

Tive que implantar um sistema que foi desenvolvido em que uma tabela é referenciada com diferentes convencões de case em diferentes partes do sistema. Como o sistema provavelmente foi desenvolvido no windows, esse problema passou despercebido.

Por sorte o script que criava o banco não especificava o Engine a ser utilizado, por isso eu pude editar o my.cnf para que o InnoDB fosse o engine default, e neste caso a lower_case_table_names=1 faz com que o MySQL seja case insentitive [1].

Aproveitei para corrigir outra chateação, o MySQL vem configurado como latin1 (até ai tudo bem) e ordencão de palavras em Sueco (??????). Para um configuracão razoável é preciso adicionar as seguintes linhas no my.cnf:

character-set-server=utf8
collation-server=utf8_general_ci


[1] http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html

Aprendendo ruby

O Akita passou hoje na minha mesa e me disse que publicou um micro tutorial pra iniciantes em ruby como eu. É um micro-tutorial-não-tão-micro em três partes.

Ioke

Acabou de sair na InfoQ, uma entrevista com o Ola Bini sobre o ioke, uma nova linguagem dinâmica que roda sobre a JVM. A entrevista da InfoQ é muito boa, vale dar uma olhada.

Uma passada rápida pelos meus feeds antes de ir pro trabalho ...

Bancos de dados orientdos a objeto

O banco de dados é um elemento que dificulta o desenvolvimento ágil. Em primeiro lugar existe a impedância entre o mundo relacional e o mundo dos objetos, o segundo é a sincronização do esquema do banco com o código.

O primeiro problema pode ser resolvido parcialmente através do ORM, Object Relational Mapping, que é a abordagem do ActiveRecord, do Hibernate e outros. Essa não é uma solução completa, não existe, por exemplo, nenhuma solução totalmente satisfatória para mapear a herança dos objetos nas tabelas do banco de dados relacional.

O problema de sincronização possui soluções menos satisfatórias ainda. No mundo do java existem gerados de código que olham para o banco e geram os objetos, o que é uma péssima solução, já que é muito fácil desincronizar o código gerado. O ruby soluciona o problema gerando dinamicamente as classes apartir das tabelas, portanto o programador faz alterações no esquema do banco e estas são refletidas dinamicamente no código. O problema dessa abordagem é evoluir o esquema do banco, o que pode ser feito de duas maneiras: editando diretamente o banco através de uma ferramenta como o MySQL Query Browser ou o PgAdmin, etc, o que faz com que se perca completamente o histórico de mudanças, ou então utiliza-se algo como as Migrations do ruby, que também não são triviais de manter.

Todas esses problemas desaparecem com um banco de dados orientado à objeto, basta declarar a classe, armazena-la no banco e pronto. As mudanças também são triviais, no sistema que eu testei, db4o, ele detecta automaticamente mudanças nas classes e atualiza do banco de dados da maneira apropriada. Em termos de facilidade de desenvolvimento um OODBMS (Oriented Object Database Management System) ganha muito em relação à um RDBMS (Relacional Database Management System). Porém existe um custo, a performance das operações é muito diferente entre os dois tipos de bancos de dados, o banco orientado à objetivo é muito rápido para carregar objetos com um grafo complexo, porém operações de agregação (sum, count, group by) são muito mais rápidas no banco relacional.

Dependendo do tipo de aplicação que se deseja desenvolver, um OODBMS pode dar ao programador alguns graus de liberdade a mais.