sexta-feira, agosto 12, 2005

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.

2 comentários:

  1. Ronie, vc ja viu algum resultado sobre manutenção desse tipo de código?

    ResponderExcluir
  2. Bom, dizem que DSLs externas (que precisam de parser) são mais trabalhosas de dar manutenção, pq vc tem que dar manutenção na linguagem ALÉM de no negócio.

    Já DSL internas, como usam a própria linguagem, não deveriam ter esse problema.

    Mas não tenho experiência sobre isso. Fiz uma pequena DSL externa pra teste em Java, só de brincadeira, e não me pareceu muito complicado dar manutenção naquilo do jeito que foi feito. Mas como foi só de brincadeira não dá pra tirar uma base séria.

    ResponderExcluir