Fragmental

Nossa, tanta coisa que nem sei o que postar. Neste tempo que fiquei afastado –quase um mês!- juntei um bando de idéias para postas mas agora falta tempo.

Neste período terminei mais um projeto. Estou alocado no mesmo cliente e temos dezenas de pequenos projetos que fazem parte de um projeto maior que faz parte de um projeto tão gigantesco que toda semana tem uma festa para comemorar que alguém lá em Perth terminou uma parte que você nem sabia que existia. Segunda-feira devo ser movido para outra parte, desta vez é apenas para prestar ajudar um grupo de desenvolvedores do cliente que está com problemas num sistema baseado em mensagens assíncronas. Deve durar até Maio, creio.

Mas não é o trabalho que me tem afastado, pelo menos não é o maior causador. O problema é a minha pesquisa. Eu tenho dedicado boa parte do meu tempo livre a me aprofundar nos assuntos necessários para uma boa compreensão de Language-Oriented Programming e Domain-Specific Languages.

Infelizmente existe duas áreas de Ciência da Computação nas quais eu nunca me interessei muito: linguagens de programação e inteligência artificial. IA é algo que eu ainda não estudo mas para entender DSLs uma das coisas mais importantes é entender como as linguagens são criadas. Isso está me fazendo tentar aprender em um mês o que eu negligenciei por anos, incluindo a leitura capa-a-capa do SCIP. Eu sei um pouco de Common Lisp mas ainda que não soubesse não seria problema, o livro usa Scheme mas você não precisa saber Scheme ara começar a ler –bem no estilo de Bertrand Meyer que ensina Eiffel no seu livro de OO.

Depois disso vem o Concepts, Techniques, and Models of Computer Programming - que é uma recomendação do Rafael- e The Seasoned Schemer. For a as dezenas de papers da ACM que tenho pesquisado.

É trabalhoso, é complicado mas é uma das coisas que me fizeram vir ara a Austrália e mudar de emprego. Na ThoughtWorks eu tenho acesso a um material seleto sobre iniciativas no mundo real destas tecnologias, e acesso à pessoas com um conhecimento sobrenatural sobre este assunto. Apesar de eu adorar fazer parte de um time fixo desenvolvendo um produto e focado em melhoria, trabalhar como consultor me dá mais liberdade para focar no meu interesse atual, que em grande parte é essa pesquisa. Eu trabalho de 9 as 17h no cliente -sem hora extra- levanto da minha mesa e em 15 minutos estou no meu apartamento.

Antes que comecem as especulações entre meus três leitores não, eu não pretendo fazer nada de útil com o resultado da pesquisa. O resultado, na verdade, não importa, para mim importa o que eu aprender no caminho.

Se tudo der errado eu faço uma aplicação em Lisp pro Facebook e fico rico :)

Mais um texto no fragmental.tw, desta vez algo mais genérico sobre modificações em linguagens. Eu ando lendo bastante sobre linguagens embutidas em outras (DSLs Internas) e outras formas de modificação de linguagem como Fluent Interfaces. É bem complicado chegar à qualquer conclusão em temas tão abstratos mas a experiência no uso destas técncias no dia-a-dia e no laboratório me mostraram que existem diferenças entre as formas de alterar uma linguagem. Em Language-Oriented Programming você cria linguagens, com Fluent Interfaces não.

Bom, mais sobre isso em Language Adaption.

Ainda não vi uma definição sobre o que seria uma linguagem elegante, então lá vai a minha:

Uma linguagem elegante é baseada em primitivas simples e extensíveis e, principalmente, sem muitas exceções.

Segundo esta definição Ruby, Smalltalk e LISP são elegantes. Java é um pouco, C# com suas centenas de exceções (sobrecarregar + é diferente de sobrecarregar [], dentre outras várias exceções) não é.

Uma linguagem elegante é simples e compacta. É de se esperar que não tenha sobrecarga de operadores, mas isso não é verdade. O problema das pessoas com sobrecarga de operadores é porque elas vêem isso como uma quebra da rule of least surprise. Essa regra diz (implora, eu diria) para não surpreendermos nossos usuários modificando o mundo que eles já conhecem para que uma ação traga consequências não esperadas. Por exemplo imagine que você vai modificar um programa como o ls para dar mais performance (uau, você é bom!). Faça o que quiser mas não mude os parâmetros de entrada e saída ou você vai quebrar um zilhão de programas e scripts pelo mundo todo. Caso introduza uma feature nova faça o usuário explicitamente solicitar por ela (passando um flag no estilo ls -lira –my-fancy-new-feature) e mantenha o default como o antigo.

E onde entra sobrecarga de operadores nisso? Lá no seu primeiro curso de programação (ou no seu primeiro livro se você opta pelo caminho mais difícil) deve ter aprendido sobre literais, variáveis, condicionais e… operadores. Operadores são caracteres especiais com uma função bem definida na linguagem, por exemplo o operador de divisão, de resto, de adição…

Em Java, quando você chama:

String texto = "abc".toUpperCase();


É fundamentalmente diferente de quando chama:


int numero = 12 + 24;


Porque um método e um operador são coisas diferentes e você aprendeu a pensar desta forma. Se amanhã eu puder sobrescrever o operador + para que escreva algo na tela você vai se surpreender porque não era isso que o manual da linguagem te disse.

Ainda assim, existem muitas ocasiões onde sobrecarga de operador são mais que convenientes, são semânticos. Imagine o exemplo do nosso BigDecimal:


BigDecimal a = new BigDecimal("100");
BigDecimal b = new BigDecimal("300");


Some os dois. Ok, você é um programador Java esperto e sabe que vai ter que fazer algo como:


BigDecimal resultado = a.add(b);


Mas disso até me dizer que é melhor que usar ‘+’ é outra história.

Mas e a simplicidade? Não é legal termos um conjunto pequeno de operadores que faz coisas previsíveis e que servem na maioria das vezes? Sim, é! Mas num mundo onde tudo migra para mais expressividade, com Model-Driven Development e Domain-Specific Languages ter este tipo de limitação não é interessante. As melhores linguagens para construir DSLs são as mais flexíveis e por acaso as mais elegantes, que coincidência, não? E como Ruby, que se enquadra nestes dois aspectos, lida com isso?

Simples. Em Ruby não existem operadores, pelo menos não como você está acostumado em Java, operadores são apenas apelidos para métodos. A vantagem disso é que se muda o modelo mental, a partir do momento que você sabe que um operador e um método são a mesma coisa você tem com operadores o mesmo cuidado que tem com métodos. Ao chamar add() do BigDecimal você tem que saber se o método vai retornar o resultado como um objeto separado, se vai modificar os objetos passados como parâmetros, etc. Como você faz isso? Lendo a documentação até se familiarizar com a classe e seu idioma. Após familiarizado você começa a usar sem pensar.

E quando você espera estar lidando com uma classe que sobrescreve um operador e na verdade recebe como parâmetro uma subclasse dela? Sem problemas! Se o autor seguiu os princípios básicos da Orientação a Objetos, que derivam do Design by Contract e o Princípio de Substituição de Liskov a subclasse tem que obedecer o contrato da classe-pai, e se você obedeceu os mesmos princípios não precisa de nada que não esteja no contrato.

Esse tipo de resistência com funcionalidades é o tipo de coisa que se elimina aprendendo várias linguagens e estudando suas motivações. Existem algumas linguagens como as citadas que merecem ser estudas ainda que você nunca as vá utilizar de fato. Elas abrem a sua cabeça.

Estava conversando com uns amigos e chegamos a uma dúvida bem interessante: por que as empresas acham normal gastar fortunas em infra-estrutura(CPUs, cores, memória, máquinas, RAC, cluster, cache, replicação) e não acham sequer razoável gastar esse investimento para migar para uma plataforma mais eficiente?.

A empresa típica hoje tem na sua linha de frente programadores..uhm… “não-ótimos” para o serviço. Estes programadores geralmente são “adquiridos” por um valor baixo e possuem como característica básica o “trabalho não otimizado” e err… a “rápida depreciação e eventual substituição da mão de obra”.

Ok, sem mais eufemismos porque este blog não se gaba por ser enterprisey: contratam pessoas ruins que ficam pulando de empresa em empresa porque podem pagar pouco (comparado ao preço de um desenvolvedor de verdade) para elas.

E como isso dá certo? Bom, macacos digitando infinitamente não reproduzem a obra de Shakespeare, mas eu garanto que se eles martelarem um teclado por algum tempo eles escrevem boa parte das aplicações Java EE ou .Net criadas hoje em dia. Desenvolvedores ruins sempre existiram mas desde o advento de ferramentas como Visual Basic e Delphi, além de plataformas gerenciadas como Java e .Net se tornou viável contratar um bando deles de largá-los amrtelando teclados sendor egidos por gerentes de pojeto que se gabam de ter sua ‘arte’ surgida na Roma antiga e acabam aplicando práticas de gestão desta época.

Vamos e venhamos: as aplicações criadas na maioria das empresas são estupidamente simples, qualquer zé mané faz. E também na maioria das aplicações basta se comprar um servidor de R$2.000,00 e qualquer aplicação construída por uma menina de 3 anos roda bem que é uma beleza. Claro que a aplicação precisa escalar, ou precisamos ainda já começar pensando grande (pense numa empresa de telecomunicações), se nosso software foi construído por macacos de Shakespeare como podemos fazê-la escalar?

Com hardware.
Máquina. Memória. CPU. Banco de Dados replicado. Particionado. Cache. Quemt em aço e silício dispensa cérebros.

E porque é tão inpensável contratar bons profissionais (que, segundo estudos, podem substituir 10 ou mais code monkeys) e dar a eles uma ferramenta eficaz e eficiente como Ruby/Rails, JRuby/Jython/IronPython/Groovy, PHP, Seaside ou Python?

Por definição uma plataforma de mais alto nível é menos performática mas quase sempre podemos vencer isso na infra-estrutura.

Que tal parar de gastar numa aplicação ruim, que vai dar problema de manutenção frequente, numa plataforma complexa por algo que tem o mesmo custo total, foi feito por 1/10 das pessoas numa plataforma simples?

Update: Faltou a conclusão: por isso que uma empresa de centenas de pessoas e milhares de verdinhas se mata para imitar o que quatro garotos que vivemd e mesada criam nos fins de semana (e não conseguem nem chegar perto!).
Ok, não é por isso, mas é um dos motivos.

Ótimo painel sobre o futuro da programação no JAOO. Especialmente o comentário do PragDave:

Dave: I’d like to predict that the current stacks of software by 10-15 years are going to be in a much worse legacy and more of a nightmare to maintain. You’re going to have employment forever maintaining this stuff. C++, Java code, C# code, this stuff is very complicated and very brittle with all these class libraries and frameworks. We’re digging ourselves in a really big hole and there will be a lifetime of opportunities for you people to maintain this stuff that you’re creating.

Prepare-se e pense nisso antes de comprar aquela ferramenta mágica ou criar mais um framework que faz a mesma coisa que todos os outros.

Ou pelo menos o que eu estou lendo é.

O livro começa com um Hello World, até aí tudo bem… mas o primeiro exemplo mais concreto te ensina a criar uma base de dados simples, um mapa. Ok, nada demais apra um programador experiente. Um mapa com uma função que reproduz uma clásusula WHERE em SQL, com AND, OR e o escambau.

Detalhe que você implementa e entende razoavelmente isso antes de entender como assignalar valores a uma variável!!

Outro fato legal é que quase todo livro moderno traz um pouquinho sobre como utilizar o framework de Unit Test padrão na sua linguagem. Este livro, até odne eu vi, traz um capítulo sobre como implementar um framework de teste.

O exemplo principal do livro poderia ser uma simples biblioteca para catalogar MP3. Mas os caras fazem um servidor com streaming.

Mas não, não se assuste! O livro é totalmente claro e fácil de entender para um programador experiente. Não faz muito minha cabeça essa coisa de exemplo atrás de exemplo (prefiro livros tradicionais) mas o resutlado final é ótimo!

Como alguns já sabem iniciei meus estudos de LISP há pouco. Estou lendo o Practical Common LISP e me divertindo muito com uma linguagem totalmente diferente de tudo que já vi (o mais próximo que cheguei disso foi Python, Ruby e Smalltalk).

Este ano eu decidi que vou aprender uma linguagem de programação a cada, pelo menos, 3 meses. Ainda que não consiga fazer nada real para meus projetos ‘de verdade’ (i.e. aquilo que você faz fora do quarto e duranto o horário comercial) em LISP, aprender uma linguagem diferente te ensina cosias que você pode aplicar em várias tarefas do seu dia-a-dia. Foi assim com Ruby por exemplo, programar em Ruby me faz pensar em soluções idferentes quando programo em Java, que por enquanto é a linguagem de aplicações que eu uso durante a maior parte do dia (com intervalos de Python, Ruby, C e PERL).

Aliás, este também é um dos conselhos do My Job Went to india ;)

Nota: é interessante que eu sempre tô atrasado com relação ao TaQ :D