Superfície Reflexiva

Smalltalk e Seaside dominando no FISL: notícia boa vinda do Randal Schwartz em seu blog:

But the biggest news is that based on the preliminary interest in Seaside because of my talk, the FISL conference organizers offered an **entire room for next years conference*** (the full three days with 12 hours per day), as well as four or five main-track hour talks, if I could help organize the subconference details! This is quite a gift, because it will mean that we can expose the 7000 conference attendees to a variety of Smalltalk programs, without paying for rooms or badging or promotion. The conference asked if I could get some corporate sponsors on board, and I immediately fired off email to James at Cincom and Monty at GemStone, and thank goodness they read email on Saturday, because they offered their support quickly. Of course, we have many details to work out, but everyone agrees that we will move forward!

Smalltalk é uma linguagem que está retornando com força total depois de mais de 20 anos vivendo às margens de outras linguagens tecnicamente não tão interessantes e isso é muito bom. Seaside é possivelmente o framework Web mais avançado em existência atualmente e muitas das idéias que vão influenciar o mercado nos próximos anos estão sendo testadas na prática no projeto–sem contar também os inúmeros projetos associados que estão avançando outras áreas. A comunidade Smalltalk é uma das poucas que está produzindo conteúdo real que implicará em mudanças de paradigmas e avanço na parte essencial da computação (dentro da divisão feita por Fred Brooks).

A palestra do Randal Schwartz já tinha um título provocativo de Seaside: Your Next Web Framework. No meio da palestra, ele ainda solta que Seaside é o framework que tornará obsoletos a maioria dos outros (não por si só mas pelas idéias geradas) e que Smalltalk é o próximo Ruby. Eu não tenho dúvidas que ele está, em grande parte, correto. A inovação atual não está ocorrendo em frameworks semi-orientados a objetos, mas em projetos que estão jogando fora a sabedoria convencional.

Eu, que nunca escondi minha admiração tanto pelo Smalltalk e Seaside, confesso que estou sorrindo até as orelhas. Se metade das idéias de Seaside pegarem em outros frameworks Web, os próximos anos serão muito mais produtivos.

Terceiro e último dia do FISL. Mantive o mesmo padrão de ontem e participei de palestras sem esquecer das conversas no meio tempo. O dia foi bem legal com oportunidades extensas de conversas e encontrar com mais gente que eu não via há muito tempo.

Nas palestras, a primeira da qual participei foi a de Seaside com o Randal Schwartz. Muito boa, é claro, e deu para ver que o pessoal na platéia ficou impressionado. Houve expressões literais de surpresa quando ele mostrou o debugger em ação e erros sendo corrigidos diretamente em uma aplicação em execução. Infelizmente, ele só teve 35 minutos para falar e acabou ficando um pouco apertado para fazer tudo o que ele pretendia. Não tive tempo de conversar com ele depois porque já queria em outra palestra mas não tem problema: ele publicou no blog dele que a organização do FISL lhe ofereceu uma sala para três dias inteiros no ano próximo para sessões sobre Squeak, Seaside e Smalltalk em geral. Impressionante, para dizer o mínimo. Com Cincom, Gemstone e outros aumentando seu suporte para Seaside, eu acho que finalmente a Web vai começar a se mover novamente e uma linguagem que merece uma exposição maior vai ter um bom lugar ao sol.

Depois disso, assisti a palestra do Sérgio Amadeu com o tema “Internet sob ataque”. Muita demagogia, pouco conteúdo e eu fiquei bem surpreso com o que escutei porque tinha ouvido o Amadeu em outras ocasiões e ele não me parecia um xiita tão incômodo. Gritando, atiçando o povo, estava mais para um Stallman escandaloso do que um sujeito mais centrado como das outras palestras que vi. Sinceramente, não gostei.

A palestra seguinte foi sobre Scrum e não consegui ouvir nem quinze minutos. O assunto era bom, a sala estava lotada, mas é como a Thaís disse no Twitter: saber de algo não é o mesmo que saber falar. A palestra estava sem rumo, slides misturando português e inglês e acho que quem estava lá não conseguiu extrair muito do que Scrum e XP realmente são. Eu confesso que passei os 30 minutos da palestra lendo um livro.

A palestra final foi a do John “maddog” Hall que deu um banho em todos os palestrantes do evento. Eloqüente, alegre, sincero e bem humorado, controlou os trinta minutos que falou e as perguntas seguintes com uma presença que os outros palestrantes ganharia muito em emular. Ele falou sobre recuperar a parte divertida do código livre e a importância do mesmo para o mundo de uma maneira que evitou completamente a demagogia do Amadeu e o extremismo do Stallman. É quase impossível descrever a palestra porque o velinho gente boa (que foi comparado ao Papai Noel em uma pergunta) tem–como diria o povo–as manhas completas. E de quebra, é super-acessível. Só a palestra dele valeu o FISL inteiro.

Durante os intervalos das palestras, mais conversas com o pessoal que foi aparecendo. De tarde, mais um papo legal com o Vinicius Telles e o resto da galera de Rails que estava lá. Durante o dia encontrei também com o Bruno Torres.

E depois de seis anos, finalmente me encontrei com o Guaracy Monteiro, meu guru programático espiritual, o cara que estava me falando para usar Ruby dois anos antes de que eu pensasse na idéia e publicando screencasts de Seaside antes que qualquer pessoa, eu inclusivo, tivesse ouvido sequer falar nisso.

Acabou que no final fomos todos para uma churrascaria local, a 35, para um rodízio insano de carnes e mais conversa maluca sobre tudo e mais um pouco. Estavam lá o Thiago Silva, Bruno Torres, Guaracy Monteiro, Thais Camilo, Gabriel Reis, Lucas Húngaro, Jony dos Santos, Vinicius Telles, Carlos Eduardo e mais uma porção de gente que eu, como sempre, não vou conseguir lembrar precisamente. Eu, Bruno, Thiago e Guaracy ficamos até quase meia noite batendo papo sobre novos paradigmas Web, hipermídia, transclusão, o futuro hiper-tecnológico, especiação social, REST, e mais um bilhão de tópicos enquanto a picanha rolava solta. E isso sem contar o engraçadíssimo “show” de danças regionais que é o espetáculo local do restaurante. Barulhento em extremo, mas divertido.

O saldo de três dias do FISL foi uma experiência incrível que valeu a pena cada segundo. Clichè, eu sei, mas nem por isso menos verdadeiro. Palestras excelente, conversas com um pessoal super-interessante (gente como o Thiago Silva, Metal e Guaracy Monteiro sempre me deixam com a sensação de que eu ainda nem arranhei certas áreas da profissão e que existe um universo inexplorado). E também a oportunidade de conversar com ídolos da área, gente que você nunca imagina serem tão acessíveis.

Muito bom e espero repetir a dose ano que vêm.

Segundo os logs de acesso deste blog, o dia de hoje representou o momento em que o mesmo ultrapassou os mil leitores conhecidos nos diversos feeds disponíveis. Eu não sei se acredito nas estatísticas ou não, mas vou supor por um momento que sejam verdadeiras e aproveitar para brincar um pouco.

Concurso

A primeira brincadeira é um concurso. Leitores freqüentes sabem que este ano eu estou pensando bastante sobre a questão de paradigmas de programação–especialmente no que tange ao desenvolvimento Web. O objetivo do concurso é simples: escreva um texto sobre esse assunto. Você pode:

• Descrever algo que está pensando sobre o assunto
• Introduzir algo que aprendeu e que modificou sua forma de pensar sobre desenvolvimento Web
• Explicar as falhas do seu framework favorito e como você as corrigiria
• Etc

De fato, qualquer coisa nesse linha vale. O prêmio vai para o texto que eu pessoalmente considerar mais interessante sobre o assunto. Para participar, basta enviar um e-mail como a URL do texto ou criar um trackback ou pingback para este texto.

E falando no prêmio: eu tenho uma cópia–nova, intocada–do Code Complete, segunda edição, do Steve McConnell, considerado um melhores livros sobre boas práticas em desenvolvimento. Não é autografado, mas é um livro muito bom e acho que cabe bem em qualquer biblioteca de programação.

Conceitos de Programação

A segunda brincadeira é tentar continuar a série Conceitos de Programação através de textos de convidados. Se você tem interesse em escrever um texto no estilo dos que eu estava fazendo–e eu espero poder contribuir novamente a partir da semana que vem–entre em contato comigo no email mtblog [arroba] reflectivesurface [ponto] com.

O único requisito é que o texto seja similar aos que já foram feitos (balanço de material explicativo e código de exemplo). Obviamente, eu me reservo o direito de adequar o texto ao estilo do Superfície Reflexiva, mas isso não significa mudar o conteúdo do mesmo. Quando muito, inserir alguns sub-títulos, reformatar código para se encaixar na coluna de texto e coisas similares.

Espalhem

Agora é hora de testar se existem leitores mesmo. Quem sentir vontade, espalhe a notícia do concurso e quem sabe podemos criar um diálogo interessante sobre o tema e presentear alguém.

Se há uma coisa que eu gosto na tradição Zen são os kōan. Poucas coisas expressam tanto, para o espírito ocidental, a natureza ambígua e intuitiva do Budismo. Embora eu não me subscreva ao Budismo, eu acho bem interessante o tipo de exercício por trás de um kōan.

Dois exemplos em particular na página da Wikipedia sobre o assunto estão entre os meu favoritos.

O primeiro expressa muito bem a contradição inerente em um kōan bem construído:

Se você encontrar o Buda, mate-o.

— Linji

O o segundo talvez expresse melhor a necessidade de uma compreensão intuitiva do que o kōan está tentando dizer:

Quando duas mãos batem, há um som. Qual é o som de somente uma mão?

— Hakuin Ekaku

Nos tempos modernos, os kōan acabaram se tornando também uma parte inerente da cultura hacker. Veja esse exemplo citado por Eric Raymond em seu Jargon File:

Um dia, quando Sussman era um calouro e estava programando no PDP-6, Minsky sentou-se ao seu lado.

— O que você está fazendo? — perguntou Minsky.

— Estou treinando uma rede neural randômica para jogar o jogo da velha — Sussman respondeu.

— E porque a rede é randômica? — perguntou Minsky.

— Eu não quero que ela tenha conceitos prévios sobre como jogar — disse Sussman.

Minsky então fechou os olhos.

— Para quê você está com os olhos fechados? — Sussman perguntou ao seu professor.

— Para que a sala fique vazia.

Naquele momento, Sussman alcançou a iluminação.

Esse kōan tem uma resposta definida, o que não é o caso da maioria deles, mas representa um exercício similar. Aliás, ao contrário dos kōan Zen, os relacionados com programação tendem a ser um tanto ou quanto humorísticos, representando muito da indisciplinada arte que é o desenvolvimento.

Neste aspecto, um outro exemplo fascinante vem de Guy Steele em uma longa discussão sobre Scheme na lista Lightweight Languages:

O venerável mestre Qc Na estava caminhando com seu estudante, Anton. Com a esperança de levar seu mestre a uma discussão, Anton disse:

— Mestre, ouvi dizer que objetos são um boa coisa. Isto é verdade?

Qc Na olhou com pena para seu estudante e respondeu:

— Pupilo ignorante! Objetos são somente uma pobre versão de closures.

Entristecido, Anton pediu licença ao seu mestre e retornou à sua célula, intento em estudar closures. Ele leu cuidadosamente toda a série de artigos Lamdba: The Ultimate e seus primos e implementou um pequeno interpretador Scheme com um sistema d eobjetos baseado em closures. Aprendeu muito e esperou o momento de encontrar-se com seus mestre e informá-lo de seu progresso.

Na sua próxima caminhada com Qc Na, Anton tentou impressionar seu mestre dizendo:

— Mestre, eu estudei diligentemente o assunto, e agora entendo que objetos são realmente uma versão pobre de closures.

Qc Na respondeu batendo em Anton com seus cajado e dizendo:

— Quando você vai aprender? Closures são uma pobre versão de objetos.

Naquele momento, Anton alcançou a iluminação.

Esse é especialmente interessante porque não tem uma resposta específica mas serve como um excelente ponto de partida para um estudo sobre o que paradigmas realmente representam. O que, obviamente, me leva a pensar que deve existir algum kōan sobre REST. Eu só não encontrei ainda.

Dentro da contradição, ambigüidade e necessidade intuitiva dos kōan, eu acho que eles dão um casamento perfeito com a arte que nós, programadores, praticamos. Como eu disse acima, isso vem da parte que não pode ser disciplinada e que depende de uma compreensão interna que todo programador possui do quê e como ele deve fazer o que faz. O que os torna, é claro, naturalmente interessantes para longas discussões sobre a prática da arte.

De qualquer forma, seja para filosofar ou programar, kōan dão uma bela leiura. E vocês, conhecem algum bom kōan?

Continuando minhas reflexões sobre novas possibilidades em paradigmas de desenvolvimento Web, eu comecei a pensar um pouco mais sobre a questão de fragmentação conceitual e como isso é possivelmente o maior problema com os frameworks atuais.

Fragmentação conceitual, no sentido que eu estou usando aqui, é a tentativa de quebrar um determinado domínio de problema em trechos de código gerenciáveis ao invés de tentar tratar o problema com um todo e resolvê-lo em termos do processo que o mesmo representa.

Isso me levou a pensar que a maioria dos frameworks atuais, ao tentar resolver essa questão, adota um faceta mais procedural. Isso pode ser visto até mesmo na organização das URLs que a aplicação expõe. Geralmente são direcionadas a um determinado objeto dentro do programa, a um método específico e dentro de certos parâmetros fixos. Raramente é feita uma tentativa de coordenar o estado entre múltiplas requisições e múltiplos objetos. O resultado final é que a aplicação é uma coleção de métodos fragmentados–daí o conceito–que não tem muita relação entre si além de pertenceram a um escopo comum.

Pensar nesse aspecto deixou claro para mim o que eu considero o maior problema com as implementações REST atuais: elas não são realmente orientadas a recursos como entidades completas que obedecem a um determinado protocolo de acesso e modificação. Antes, a maioria delas é usada como forma de mapear transições independentes entre diferentes estados de uma aplicação (ou um domínio de problema) sob uma capa de recursos. Mesmo frameworks que não usam REST acabam sofrendo de um problema similar.

Um dos motivos pelos quais eu gosto tanto de Seaside vem da sua heresia em dizer que REST é algo fundamentado em uma visão arcaica da Web que não tem muito a ver com as possibilidades atuais. Seaside, ao deixar REST de lado, adota a visão processual de uma aplicação–em contrapartida à visão procedural. A aplicação é vista com um todo, tendo estados específicos que são manipulados através de representações igualmente específicas. Isso não quer dizer que Seaside esteja absolutamente correto no que faz. É uma evolução, mas não o estado final.

A ressurgência de MVC nos frameworks atuais talvez tenha a maior parcela de culpa nesse fechamento. O surgimento de controllers em aplicações Web como um endpoint REST talvez não seja a melhor alternativa. Da mesma forma, limitar modelos como recursos é algo tão fundamentalmente incorreto que eu fico imaginando de onde teria vindo essa interpretação incorreta do que é MVC e REST–e simultaneamente.

Para finalizar, eu devo repetir que o que estou postando aqui são considerações sobre o meu próprio trabalho e sobre o que está norteando meu pensamento nesse momento. Eu posso–e devo–estar errado em muitas considerações e gostaria do feedback de leitores interessados nos mesmos assuntos.

Esqueci de anunciar aqui ontem, mas o segundo episódio do Pão de Cast desse ano já está disponível. Nessa edição falamos de portabilidade de dados, a controvérsia sobre o IE8 e discutimos paradigmas de desenvolvimento Web.

O episódio S02E01 está atrasado por um pequeno detalhe técnico: o Luiz Rocha saiu de férias antes que eu percebesse que precisava de um arquivo que está com ele. Assim que ele retornar, disponibilizarei o arquivo no mesmo lugar de sempre.

Enquanto isso, divirtam-se com o novo episódio. E linchamentos realmente são permitidos.

Continuando a pensar sobre a necessidade de um novo paradigma de desenvolvimento Web, algumas perguntas para me ajudar a formular o que eu mesmo quero:

1. Considerando o relacionamento entre MVC e REST dentro do Rails, me parece que controllers são essecialmente uma cola supérflua. Seria possível eliminá-los com uma representação direta de recursos?

2. Ainda pensando em recursos, Seaside é componentizado e entende que cada componente deve ser capaz de criar sua própria representação primária. Como lidar com múltiplas representações e combinações de representações nesse caso? Multi-dispatch aplicada a uma linguagem específica de representação pode ser algo interessante aqui.

3. REST não é necessário para todas aplicações e forçar isso tende a quebrar o workflow natural. Rails e Django permitem uma quebra e preferem recursos; Seaside ignora recursos em troca de continuidade de requisição. Seria possível modelar ambos com uma linguagem transversal?

4. De onde a requisição deve partir, principalmente considerando necessidades atuais como RIA, Ajax e Comet?

5. Uma representação como máquina de estados seria interessante? Principalmente ao se considerar a pergunta anterior e se descartarmos a separação explícita de modelos, uma representação como estados pode ser algo mais interessante (e em tese, até compilável). Se os modelos fossem removidos em aplicações onde o domínio é mais individualizado, fazendo com que a aplicação seja uma seqüência de transformações, alguns problemas de mapeamento se tornam mais simples.

6. Se REST for descartado, como Seaside faz, e se considerarmos que sessões são contínuas, quais as possibilidades que temos quanto a transformar toda a aplicação em uma linguagem única específica para a mesma?

Respostas? Mais perguntas?

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?

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.

Esse é o primeiro artigo de uma série sobre DSL–Domain Specific Languages ou Linguagens Específicas de Domínio–que deve se estender por três ou quatro artigos.

O objetivo é explicar um pouco sobre o que é uma DSL e como você pode usá-las para facilitar o seu trabalho de programação, reduzindo e melhorando o seu código de maneira significativa. O conteúdo é baseado em palestras que eu dei anteriormente mas com algumas outras considerações que o tempo não permitiu durante as mesmas.

Linguagens

Um dos meus referenciais em relação ao aprendizado de programação é tentar seguir o que Alan Perlis disse sobre o assunto:

Se uma linguagem não é capaz de afetar o modo como você pensa sobre programação, não vale a pena aprendê-la.

Eu não sei se Perlis estava pensando em como linguagens podem afetar o modo como você programa, mas isso é algo que sempre me vêm à mente quando eu penso no que Perlis disse. Há uma cadeia lógica quando se pensa em linguagens, paradigmas e sintaxe. Paradigmas afetam a sintaxe da linguagem e a sintaxe afeta como você programa. Disso se segue que o desenho da linguagem necessariamente afeta como você programa. Isso parece óbvio mas o fato é que mesmo variações entre linguagens imperativas–o paradigma de maior sucesso na história da programação–podem ter um impacto significativo em com um programador é capaz de descrever os problemas em um dado domínio.

A extensão natural dessa progressão lógica é pensar o que poderia ser feito caso fosse possível implementar a sua própria linguagem. Um paradigma diferente ou uma sintaxe diferente poderiam modificar a maneira com um problema é tratado e simplificar enormemente sua resolução.

O que uma DSL se propõe a fazer é exatamente isso: tratar um problema específico, dentro de um domínio qualquer, através da criação de uma linguagem própria para o mesmo. E embora isso seja possível em maior ou menor grau em virtualmente qualquer linguagem de programação, existem certas características que facilitam esse tipo de programação. Um forte protocolo para objetos, uma sintaxe flexível e a capacidade de interceptar características da linguagem são essenciais para o aproveitamento máximo de uma DSL.

Nessa série de artigos usaremos Ruby para isso, embora os mesmos princípios possam ser aplicados em qualquer outra linguagem.

O que realmente é uma DSL?

O que hoje está se tornando conhecido como DSL atualmente já teve vários nomes dependendo da comunidade em que as mesmas eram usadas. Alguns desses nomes são:

• Pequenas linguagens: comunidade Unix
• Macros: usuários de Lisp e Scheme
• Linguagens de aplicação: BI e analistas
• Linguagens orientadas ao problema: designers de linguagens de programação

Não importa qual o nome, todos esses rótulos se referem ao mesmo conceito: linguagens (isto é, formas de expressar algum conceito) específicas (ou seja, com um propósito bem definido) de domínio (pertencentes a uma classe particular de problemas). Uma DSL é circunscrita por três definições:

• Ela resolve um problema específico. Em outras palavras, uma DSL não tenta abarcar todos os problemas possíveis de uma aplicação, mas se fixas em um único deles. Pode existir cooperação entre várias linguagens para resolver um problema maior, mas uma DSL resolve um único problema.
• Ela estreita o foco do domínio. Uma DSL permite que um domínio específico tenha o seu escopo reduzido através da abstração que a mesma providencia. Podem ser necessárias várias linguagens para esconder todo um problema, mas cada uma dela resolve uma parte e esconde a mesma atrás de uma abstração mais simples.
• Ela esconde a complexidade do código. A DSL não pode ser mais complicada do que o código que pretende substituir. A abstração deve ser inequívoca mas com uma interface significativamente reduzida.

Com base em todos esses conceitos é fácil perceber que usamos várias dessas linguagens:

• Um Makefile, por exemplo, usa uma DSL que permite especificar como determinados arquivos devem ser compilados/montados para formar uma aplicação.
• Comandos para o shell de um sistema operacional são uma DSL para manipular os fluxos de entrada e saída de programas sendo executados. Um script é uma mera aplicação dessa linguagem.
• SQL é uma linguagem específica para a definição e recuperação de dados descritos em um formato relacional. Por mais sofisticado que seja, ele se resume a quatro operações básicas: selecionar, inserir, atualizar e excluir.
• Todo arquivo XML ou SGML é uma DSL em si própria. Assim, o HTML e o XHTML são aplicações específicas que também forma uma DSL por sua vez.

Um dos exemplos mais interessantes de uma DSL é a linguagem usada pelo Graphviz. Essa linguagem, chamada de DOT permite a criação de virtualmente qualquer tipo de grafo através de comandos simples e intuitivos. O código abaixo é um exemplo simples:

digraph finite_state_machine 
{
    rankdir = LR;
    size = "8,5"
    
    node [shape = doublecircle]; LR_0 LR_3 LR_4 LR_8;
    node [shape = circle];
    
    LR_0 -> LR_2 [ label = "SS(B)" ];
    LR_0 -> LR_1 [ label = "SS(S)" ];
    LR_1 -> LR_3 [ label = "S($end)" ];
    LR_2 -> LR_6 [ label = "SS(b)" ];
    LR_2 -> LR_5 [ label = "SS(a)" ];
    LR_2 -> LR_4 [ label = "S(A)" ];
    LR_5 -> LR_7 [ label = "S(b)" ];
    LR_5 -> LR_5 [ label = "S(a)" ];
    LR_6 -> LR_6 [ label = "S(b)" ];
    LR_6 -> LR_5 [ label = "S(a)" ];
    LR_7 -> LR_8 [ label = "S(b)" ];
    LR_7 -> LR_5 [ label = "S(a)" ];
    LR_8 -> LR_6 [ label = "S(b)" ];
    LR_8 -> LR_5 [ label = "S(a)" ];
}

O resultado é o seguinte:

É fácil observar pela galeria de exemplos desse pacote que o uso da DSL esconde uma complexidade enorme por trás das cenas mas é bem específica no problema que resolve.

Uma DSL é uma linguagem, mas ela não se propõe a ser completa. Ao contrário de linguagens de programação que possui construções específicas para lidar com problemas genéricos de condições, iterações e definições, uma DSL é um conjunto limitado de comandos que descrevem um intento específico sobre um problema específico.

Interna versus Externa

Uma DSL pode ser interna ou externa. Uma DSL externa geralmente pode ser utilizada pelos usuários finais da aplicação–e muitas vezes eles são o público real das mesmas–possuindo tratamento de erro mais específico para o domínio que resolvem. Em contrapartida, uma DSL internal normalmente é usada pelos próprios programadores da aplicação e não possui um tratamento de erros tão robusto porque assume que sua utilização será mais constrita.

O foco dos nossos artigos são as linguagens internas embora os princípios aqui discutidos também possam ser utilizados nas externas. O nosso objetivo é mostrar como a aplicação de linguagens internas pode reduzir o código necessário para uma aplicação e simplificar o processo de testes.

Em nosso próximo artigo veremos como um problema comum pode ser convertido de sua implementação normal para usar uma DSL que o torna mais compacto e inteligível.