Blog do Renato, o Louro

Já faz tempo que eu digo que iria criar uma nova linguagem de programação. E já havia dito que seu nome seria Graphol. Mesmo aqui neste blog, já favia mencionado o nome Graphol no post Siga um Louco. Creio que tenha sido a primeira vez que falei publicamente sobre Graphol, embora nunca tenha entrado em detalhes. Pessoalmente só havia comentado sobre o que seria Graphol para pouquíssimas pessoas. Mas chegou a hora de disponibilizar a ideia para todos.

É claro que entendo que para que algo ter algum lugar ao sol, é importante que ela tenha uma ‘defesa de existência’. Ela deve ser boa em algo. Talvez ser a melhor sob determinado aspecto. Por exemplo:
- Em geral a linguagem é péssima. Mas é a melhor do mundo para se criar softwares de planilhas eletrônicas.
Pronto, está justificado. Pode não vir a ser muito utilizada no futuro mas tem uma razão de existir.
Mas, brincadeiras a parte, eu realmente estou convencido de que podemos – eu e aqueles que comprarem a idéia – contribuir com o mundo da programação oferecendo uma linguagem de programação legal de se trabalhar. Uma linguagem que, sob determinados cenários, possa realmente facilitar o desenvolvimento.

E realmente gostaria de fazer isso com a sua ajuda. Quero que esta linguagem seja também sua. Ela está sendo pensada agora. Se você gostar da idéia geral, se achar que realmente pode ‘dar samba’, é a hora de entrar e fazer a diferença. Pense em todas aquelas coisas legais que você sempre quis ver em uma mesma linguagem de programação? Talvez Graphol seja a linguagem que poderá transformar isso em realidade até porque estou te convidando, formalmente, a fazer parte desta idealização. Convido você a conhecer o site onde estamos rascunhando a linguagem Graphol.

Mas do que se trata a linguagem?

O próprio nome Graphol já carrega um significado, já mostra à que veio. Acho que deve ser fácil perceber que o nome Graphol vem de graph (grafo).

No meu curso de faculdade eu fui ‘poluído’ pela ideia de grafo de várias maneiras. Minha iniciação científica estava relacionada ao emprego de grafos para determinar regras de negócio em sistemas munidos com IA.

No meu projeto final eu criei um CMS onde os conteúdos, os relacionamentos entre os conteúdos, e o relacionamento entre usuários, permissões e conteúdos eram representados por grafos. Pessoas e conteúdos eram nodos e seus relacionamentos eram arestas. Se um usuário altera um conteúdo, significa a criação de uma aresta com a tag ‘alteração’ ligando o nodo daquela pessoa ao nodo daquele conteúdo. Para ver todos os documentos alterados por uma pessoa, bastava perguntar ao CMS por todos os nodos ligados àquela pessoa por nós ‘alteração’.

E não muito tempo depois, comecei a pensar que, a exemplo do CMS, como seria legal implementar uma linguagem que, nativamente, atuasse sobre grafos. Uma linguagem orientada a grafos. “Graph Oriented Language”, Linguagem Orientada a Grafos. Um novo paradigma? Talvez.

Fato é que eu estou incubando esta ideia e vontade de realização a quase uma década debatendo sobre o como seria esta linguagem com pouquíssimas pessoas. Acho que com umas 5. Entre elas @Chavao e @LucasZeta que estão comigo no projeto.

Ainda não tenho nada de fato. Nem uma especificação formal. Mas acredito que tornar pública a ideia e convocar pessoas interessadas pode ser a única forma de fazer algo acontecer.

Mas antes de dizer sobre Graphol, segue alguns problemas que Graphol terá que se preocupar em solucionar para ser uma linguagem respeitada:

Composição Vs Herança

Logo quando foi lançada por Simula 67 e redescoberta por Smalltalk-80, a ideia de herança entre classes sempre foi considerada um dos principais recursos para reuso de código e uma das grandes justificativas para a própria orientação a objetos. Mas, com o tempo, percebemos que a ideia de composição/agregação entre objetos é superior em vários aspectos à ideia de herança. Vários programadores passam a preferir a ideia de composição/agregação entre objetos. A maioria dos Designer Partners dão preferência a ‘cooperação’ entre objetos e mecanismos para ‘delegação de trabalho’ entre os mesmos do que uma relação ‘cristalizada’ em tempo de definição de classes que é dado pelo mecanismo herança.

Mas é interessante perceber que a ideia focal na maioria das linguagens orientadas a objetos é a herança e não a composição. Para isso basta perceber no esforço envolvido para o programador em implementar uma herança entre classes e uma composição entre elas. Imaginemos um caso hipotético onde queremos que uma classe B reuse as funcionalidades da classe A. Na grande maioria das linguagens, quando tratamos de herança, significa colocar um simples complemento na definição de B como, por exemplo, ‘Class B extends A’. Pronto! B passará a ter acesso a todas as funcionalidades da Classe A.

Já, para implementar uma composição, salvo honrosas exceções como o Ruby, normalmente precisamos:
1- Dizer que B implementa a mesma interface que A;
2- Criar um atributo que aponte para um objeto da classe A;
3- Criar uma maneira, talvez no próprio construtor e/ou por uma função set, de informar para classe B qual é o objeto agregado; e
4- Para cada médodo de A teremos que recriá-lo em B, delegando o trabalho para o método respectivo de A de maneira semelhante à: “function metodo1(arg a, arg b){ super.metodo1(a,b);}”. Ou seja, se queremos redefinir apenas um único método, e temos vinte e um métodos em A, teremos que criar 20 construções como estas.

Dado as vantagens da composição sobre a herança, a implementação do primeiro deveria no mínimo ser tão fácil de implementar quanto o segundo.

Graphol deveria privilegiar a cooperação entre objetos e delegação de responsabilidade ao invés da implementação estrutural de relações de herança.

Ruby achou um caminho com o ‘Forwardable’. Creio realmente que este seja um caminho. Mas ainda podemos fazer ainda melhor.

Orientação a Aspectos

A orientação a objetos é ótima para definir comportamentos análogos verticalmente, isto é, comportamentos herdados via estrutura de herança. Mas, sozinha, não apresenta uma boa solução para tratamento de funcionalidades secundárias que devem se repetir ‘horizontalmente’ por esta estrutura. E, ao encontro desta questão, surgiu a orientação a aspectos.
Mas em geral a orientação a aspecto funciona através de uma extensão feita a uma linguagem hospedeira. Por exemplo temos o AspectJ para Java e o AspectC para a linguagem C.

Acredito que seria ótimo se Graphol, por estrutura, pudesse nativamente, suportar a orientação a aspecto, sem necessitar destas extensões a linguagem raiz. Algumas linguagens, com bons recursos de metaprogramação, são capazes disso. Mas estou falando de algo ainda mais natural para a linguagem.

Programação Concorrente em Geral

Acho que não há dúvidas que uma nova linguagem deve se preocupar com concorrência. Ela deve facilitar ao máximo a vida do programador neste aspecto. Podemos pensar em forks, threads, corrotinas, semáforos, memória compartilhada. Programar de forma concorrente não é fácil. Não costuma ser natural ao programador. Mas, por outro lado nunca foi tão necessário. A forma usual de aumentar a capacidade computacional tem sido multiplicar núcleos, processadores, nós de uma nuvem etc. Graphol precisa ajudar o programador a tirar proveito disso.

E, finalmente, o que é Graphol?

Introdução
Um grafo pode ser perfeitamente usado para modelar vários aspectos da realidade. Nodos modelam objetos/entidades/coisas e as arestas modelam as relações entre elas. Graphol é uma linguagem que permitirá abstrair problemas como grafos, e nos ajudará a tirar vantagens disso. Neste conceito, nodos são pedaços de código. E as arestas ligam estes pedaços de código trazendo certas propriedades a esta relação.

Inicialmente podemos entender os nós como os velhos objetos OO. Não criamos classes, criamos diretamente estes nodos. O function em Javascript é uma boa aproximação do que é um nodo. Uma característica que acho importante é que um nodo possa receber tags. Tags tem várias utilidades. Ajudarão em buscas globais a estes objetos [Para todos os nós com a tag 'documento' faça], assim como fazer as vezes de uma interface: O objeto x tem a tag ‘pessoa’?

Arestas relacionam estes nodos. Alguns também carregarão uma semântica especial, conforme veremos. Arestas também poderiam ter tipos e/ou nomes. Então, poderíamos fazer facilmente a construção:
[Para cada nó 'documento' ligado por uma aresta 'editadoPor' a este nó 'pessoa' em questão faça]

Composição Vs Herança
Determinados tipos de arestas podem unir nós com a semântica semelhante ao ‘Forwardable’ do Rubi. Ou seja, uma aresta do tipo ‘Forward’ significaria que, não encontrando uma definição interna, deveria procurá-la pelo grafo indicado pelas arestas ‘Forward’. Então poderíamos não ter herança. Poderíamos simplesmente apontar para os nós para qual um dado nó deveria redirecionar dadas requisições. Filtros sobre determinada aresta poderia prover um controle mais refinado sobre um redirecionamento em particular. Penso em várias outras coisas sobre estas relações. Mas aqui não é o melhor veículo para esgotá-las.

Orientação a Aspectos
Arestas do tipo ‘doBefore’ por exemplo poderia ligar um nó a outro que deveria ser acionado primeiro sempre um nó fosse acionado. Então poderia ser válido algo como:
[Para todo nó com a tag 'acesso'
ligue com doBefore ao nó valide_usuario]

Programação Concorrente em Geral
Que tal uma aresta startToStart para indicar que um nó será executado em paralelo sempre que um outro iniciar a execução? Imagine um gráfico de Gant. Poderiamos indicar um lag de tempo para as arestas como, por exemplo ‘comece 2 segundos depois’. Um nó poderia estar amarrado para começar uma execução em paralelo após 2 outros terminarem a execução e um terceiro já ter iniciado. startToStart, startToFinish, FinishToStart, FinishToFinish posso imaginar utilidades para todas com a idéia de procesamento paralelo.

Padrão Observer (Coração do MVC Clássico)
Nós também guardam informação. Acho que uma aresta com a semântica ‘doOnUpdate’ poderia ser muito útil.

Metaprogramação
A estrutura de um programa pode ser expressa em termos de árvore que, por sua vez, é um tipo particular de grafo. Bem, estamos criando uma linguagem cujo objetivo é criar/editar grafos. Não parece que fica trivial pensarmos em mecanismos para que um programa Graphol possa fazer referência e/ou alterar sua própria programação naturalmente, isto é, utilizando os mesmos comandos que tratam de nós e arestas que é exatamente o coração da linguagem? Me parece que a programação reflexiva em Graphol poderá ser encarada de forma ‘mais natural’ do que ocorre na maioria das linguagens. Os mecanismos para um programa alterar sua própria estrutura serão exatamente os mesmos pelos quais o programa fará qualquer outra coisa.

Conclusão

Meu objetivo não é esgotar o assunto aqui, até porque Graphol é uma linguagem que ainda será inventada! Este post é para abrir possibilidades e gerar discussão. Entendam o post como quase um início de bainstorming.
Mas para tentar dar uma melhor ideia de como eu imagino Graphol, sabe conceitualmente o que é uma rede neural? Vários nós recebendo estímulos, ponderando estes estímulos e emitindo o seu próprio estimulo para a camada seguinte? Bem, isso deveria ser trivialmente implementável com Graphol.
Sabe uma planilha eletrônica onde cada célula se atualiza dado o estímulo de algumas outras? Bem, isso também.

Abraços e, por favor, já que você leu tudo e chegou até aqui: opine!
Conheça o Manifesto Graphol!

Este post foi postado domingo, 24 de julho de 2011 às 2:05 e está em Programação. Você pode verificar qualquer resposta a este post através do feed RSS 2.0. Você pode deixar uma resposta, ou fazer um trackback de seu próprio site.