Canos ao invés de Camadas

Isso é o germe de uma idéia ainda. Mas já vou postar pra ver se a discussão evolui a idéia. Eu e o Marlus aqui estávamos discutindo sobre camadas (de software) e como é difícil você controlar isso porque camadas podem ter uma "superfície de contato" muito grandes entre si. Sem falar que frequentemente você não consegue isolar uma camada inteiramente do contato com outras duas. Aí, pensando em algumas coisas que implementamos aqui, encontramos uma outra metáfora que leva a um design ligeiramente diferente: CANOS. Imagina que seu módulo não é uma camada, mas um componente isolado que só se comunica com outros através de uma única classe, nosso "cano". Módulos (pacotes ou componentes) só se conecta a outro através de um único cano. Dessa forma, se a comunicação precisar de modificações, validações ou restrições, você pode trabalhar somente na classe que faz a conexão ao invés de ter toda uma superfície de contato para caçar. É como se todo componente/pacote/módulo tivesse obrigatoriamente um façade. (hmmmm....) Essa idéia levou a outra. Se eu tenho um cano e preciso transportar dados, como eu transporto? Minha sugestão é "enlatar" os dados em uma estrutura que ambos os componentes/módulos/pacotes entendam. Os dados só podem ser obtidos dali. Essa idéia de lata de dados foi aplicada em um framework aqui e deu resultados muito bons. Toda a transformação de dados necessário para comunicar os componentes pôde ser feito na lata ao invés de ficar espalhado. Canos e latas.... será que dá pra evoluir a idéia?

Duck Typing?

Pra mim, isso é duck typing. Mas obviamente o cara tá pensando em algo muuuuito mais avançado, baseado em reconhecimento de padrões.

...Computer architectures as we know them were first designed around simulated wires. Source code is a simulation of pulses that can be sent sequentially down a wire, as are passed variables or messages. Now, I think that's a notion that can be extended very, very, far. And if you really want to, you can even use it to describe all of nature, but it's not the only idea that could be extended that far. And it does get kind of awkward because this is not the way that natural systems work. For example, if you want to describe the connection between a rock and the ground that the rock is resting on, as if it were information being sent on a wire, it's possible to do that, but it's not the best way. It's not an elegant way of doing it. If you look at nature at large, probably a better way to describe how things connect together is that there's a surface between any two things that displays patterns.

-- Entrevista com Jaron Lanier no site da Sun (ênfase minha) Por enquanto, eu fico com o básico "Duck Typing". Pra mim (opinião bem pessoal) é exatamente isso que o cara falou de ter padrões entre as partes que são reconhecíveis. Talvez dê pra estender a idéia um pouco, mas que sei eu?

Qualidade implícita e Fábrica de Software

Bom, não é novidade pros meus amigos que tenho minhas restrições quanto ao termo "Fábrica de Software", porque ele implica em algumas coisas que eu não concordo muito. Pra poder ser "Fábrica de Software" tem que ter uma estrutura que eu não vi em nenhuma empresa que se auto-intitula isso. Então, fico com a impressão que eles estão vendendo gato como lebre. Outra reclamação minha, a mais básica, é que "Fábrica" tenta seguir o modelo de produção em massa de montadoras: "Coloque o design na ponta da fábrica, os programadores seguem as instruções e o software fica pronto". Isso é uma maravilha sob o ponto de vista gerencial já que é um processo previsível e vc só precisa de uns poucos analistas muito experientes e um tanto de programadores de baixo custo. Por mais que eu tente, não consigo me convencer que isso funcione (por motivos bastante óbvios). Outro fator, que é simplesmente crítico, é que em toda "Fábrica" seu comprador espera que você tenha um processo muito bem definido de qualidade. Ninguém paga 60K num carro pra ele vir parcialmente completo, entregue depois do prazo e com uns defeitos aqui e ali. Imagine então um produto que chega a custar várias vezes um carro desses. Agora eu pergunto pra quem trabalha e gerencia uma fábrica: "Você tem métricas e métodos para produzir um software com a qualidade implicitamente esperada?". Seja sincero pra você mesmo, sem essa de "estamos nos preparando" e "temos mas o prazo não permite". Não é de se admirar que os clientes fiquem nervosos com nossa área. Dou razão à eles. PS: AH! E se vc acha que ter um CMMi garante essa qualidade, olhe o processo atentamente e pense de novo: onde no processo você detecta, corrige ou mesmo previne (ênfase aqui) os defeitos? Preenchendo relatórios e gerando mais ordens de serviço? E onde está o método de detecção? É do tipo: "Q&A vai lá, senta e testa?", "Isso é um processo a ser definido pelo Q&A". Ceeeeerto.....

O programador padrão

Acabei de pensar quando finalizava o tópico anterior... Até onde será que vai o conhecimento da maior parte dos programadores? UML? Padrões? Aspecto? Anotações? Testes de Unidade? Geração de código? Parsers de linguagem? Expressões regulares? Não estou pensando em questão de coisas ou programadores mais avançados ou menos avançados, acho que nem dá pra classificar isso. Mas no que 80% dos programadores profissionais conhecem em comum. Seria essa a nossa base mínima de conhecimento hoje? Daria pra fazer alguma aproximação útil com isso? Hmmmm... coisas a se pensar...

Sobre Orientação a Objeto e Domain Specific Languages, sempre abstrações.

No princípio era o macarrão! Grandes blocos de código em sequência com saltos arbitrários que faziam com que rastrear um programa fosse um exercício de desatar nós para escoteiros. Então os gurus disseram - "Que se criem funções", e a programação estruturada surgiu. Pequenos blocos de códigos espalhados por arquivos, às vezes nem tão pequenos, uns referenciando outros. As funções se tornaram comandos e algumas vezes era difícil saber o que era um comando criado dado pela linguagem de outro criado por usuários. As linguagens se expandiam naturalmente. Tempos de ouro das "Bibliotecas". Então os gurus olharam, acharam bom, e criaram a orientação a objeto. Blocos de código que continham seus próprios dados, com a intenção de serem modelos mais próximos das coisas reais. Ela se expandiu, tomou forma, agora, além de comandos, podíamos ter nossos próprios tipos de dados inteligentes e que sabiam interagir uns com outros. As bibliotecas ganharam nome de API, começou a era de ouro dos Patterns e Frameworks. Agora alguns gurus olham e apontam: Linguagens orientada a linguagens, aspectos, linguagens específicas de domínio... precisamos de mais flexibilidade/velocidade! As linguagens específicas de domínio andam me interessando bastante. Usando um pouco delas comecei a perceber que o que fazemos na verdade não passa de criar abstrações específicas para nossos problemas. Isso fazemos o tempo todo, nenhuma novidade, a diferença é que agora, além de criarmos as abstrações, queremos organizá-las em uma sintaxe que seja mais adequada para representar uma solução. Há um monte de implicações nisso: não-programadores podendo escrevendo definições na área onde são experts, mais solução por linha de código, etc, etc. Mas não vou entrar nisso. O que me interessa é que acho a evolução do software sempre nos guiou a criarmos nossa própria "linguagem" com as abstrações para o negócio para o qual estamos programando. Mas isso era implícito, ou talvez não completamente percebido. Agora, com DSL, linguagens de script e outras coisas tomando foco talvez a ficha caia de vez. Talvez não seja nada disso e eu esteja enganado, ou talvez isso só alcance o programador padrão daqui uns trocentos anos. Quem sabe? Enquanto isso, vou testando minha teoria e batendo a cabeça por conta própria.

Padrão nada importante: "Result named variable"

Um padrão sobre nomenclatura que eu adoto faz uns anos, e já vi alguns outros birutas usando também (é bom saber que não sou o único retardado da área). Problema: Você tem um método que retorna uma coleção, uma das primeira linhas do método é atribuir uma coleção à variável local que vai ser retornada. Você não encontrou um bom nome para a variável. Solução: Chame a variável de "result". Isso parece besta, mas sabe que torna o método muito legível? Ando usando essa nome de variável pra quase todo método onde eu acumulo coisas e retorno o resultado. Não sei se foi pq acostumei com o padrão, mas sempre bato o olho e já entendo o que acontece. Isso estende pra outra idéia que ando experimentando: variáveis locais nomeadas segundo sua função no método. Se é um contador: counter, x ou i; se é um pedaço da string de nome de cachorro:string_part e não dog_name_part. Ainda estou experimentando pra ver se isso é bom. A gente só sabe se fica bom mesmo depois que tem que mexer no mesmo programa depois de seis meses. Então leva um tempo pra ver se é útil de fato.

Limite de popularidade de uma linguagem

Agora cedo eu e o Alessandro conversamos rapidamente sobre linguagens como Ruby e Python estarem ficando cada vez mais populares.

Ronie  x-arnie  .NET e Java são mainstream, depois vem PHP,
                Python e lá na rabeira, Ruby 
Ronie  x-arnie  Contudo, com o framework de web deles, o Rails,
                estão ganhando espaço, só não sei até onde. 
x-arnie  Ronie  hum.., complicado dizer 
x-arnie  Ronie  mas não vai ficar muito além do python ou php,
                eu diria que no máximo igual ao php
x-arnie  Ronie  pelo que costumo ver nessas evoluções 
Ronie  x-arnie  Por aí. 
Ronie  x-arnie  Sem suporte de uma grande empresa,
                não atinge a "diretoria" 
x-arnie  Ronie  that´s the point! ;) 

Taí, se dá pra fazer uma aposta sobre até onde vai a popularidade de uma linguagem, ou o tamanho da sua comunidade, podemos chutar que não vai além do PHP se não atingir a diretoria. O Ruby e o Rails mudariam isso? Eu gostaria, mas duvido muito.

DSL (Domain Specific Languages)

Volta e meia eu pego algo sobre DSL para ler. Hoje achei um artigo do tio Fowler que é muito bom. Ele explica DSL de cabo a rabo e dá uns links muito legais. Language Workbench (DSLs) Eu nessa história prefiro as DSLs internas. Estou tendo um dose maciça de exposição a Ruby (e Rails) recentemente e percebi que é muito simples criar estruturas que se parecem muito com comandos de linguagem usando a forma funcional de chamada (sem "self", igual java sem "this") e closures. Exemplos simples são o "transaction { blah blah }" e um que nós criamos (muito específico para nossas aplicação) "show_if_relevant { blah blah }". Ambos com forma funcional, blocos e a sintaxe relaxada do Ruby. É... sinto que os próximos anos serão interessantes para linguagens de programação.