- Objetos são o centro da orientação a objetos. Objetos são mais importantes que classes. Objetos precisam existir, classes não. E uma maneira óbvia de simplificar uma linguagem é abolindo este conceito. Entre classe e interface preferimos o último.
- Uma linguagem deveria privilegiar as ideias de cooperação entre objetos e delegação de responsabilidade ao invés da implementação estrutural de relações de herança. 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 quanto o segundo. Na verdade, o segundo não precisa necessariamente existir.
- O relacionamento entre os objetos deveria ser tão importante quanto os próprios objetos. A orientação a objetos tradicionalmente condena a relação entre objetos à um mero atributo/referência em um dos objetos da relação. Mas assim como Nodos e Arestas se ajudam a compor um grafo, uma linguagem deveria dar destaque aos relacionamentos entre objetos, fazendo deles entidades com vida própria, com seus próprios nomes, semânticas e propriedades.
- A programação reflexiva deve ser trivial em qualquer linguagem moderna. Um programa escrito nesta linguagem deveria ser capazes de modificar a sua própria estrutura integralmente, utilizando os mesmos comandos básicos da linguagem.
- Programação concorrente e distribuída são o futuro. Na verdade, já é o presente. E várias regras que definem uma cooperação concorrente entre os objetos, remotos ou não, podem e devem ser expressas em seus relacionamentos.
Acreditamos que vários tipos de problemas computáveis não só podem ser abstraídos e modelados como grafos assim como tirariam proveito desta modelagem. Nesta abordagem, relacionamentos e cooperação entre objetos ganham uma força equiparável ao próprio objeto. Mais do que queremos, nós precisamos de uma linguagem que torne trivial este tipo de modelagem. Nós precisamos que Graphol exista! Apoie esta ideia!
Graphol: Por uma nova linguagem.
Signatários
Renato Louro(@rslouro)
Chavão (@Chavao)
Lucas Souza Conceição (@LucasZeta)
Pingback: Graphol: Por uma nova linguagem | Blog do Renato, o Louro
Precisamos mesmo? Bom, talvez seja pura inexperiência minha, mas em todos os tópicos me pareceu que falávamos de Javascript.
Alguns tópicos sim, afinal Javascript é uma ótima linguagem. Porém o tópico 3 e 5 não se assemelham, principalmente para o 5º que aborda sobre programação concorrente.
Olá Rael.
Javascript é sim uma grande linguagem e é uma das grandes inspirações para Graphol. Porém existem diferenças significativas.
Se tivesse que comparar o Nodo com alguma coisa, seria com o function/objeto de javascript. é o que mais se aproxima. A grande diferença entre Graphol e Javascript talvez esteja no relacionamento entre os objetos e no suporte ao paralelismo, mas não que não existam outras também significativas. Mas vamos falar sobre estas primeiras.
Como é que você promove a delegação – ou até simulação de herança – entre objetos Javascript?
Uma maneira é utilizar a forma padrão:
1- Um objeto guardar a referência para o objeto alvo;
2- Para cada método do objeto alvo recriamos uma função que chama objAlvo.metodo(x), delegando a responsabilidade pela ação do médodo.
Javascript também tem uma maneira curiosa de simular herança que é criando uma função que copie todos os métodos e atributos do objeto alvo.
Veja alguns exemplos em:
http://javascript.crockford.com/inheritance.html
Agora, convenhamos: É uma certa – para não dizer muita – ‘gambiarra’.
Em Graphol as relações – arestas – entre nodos terão relevância comparável aos próprios nodos. Assim uma aresta marcada como ‘Forward’ unindo dois nós fará com que as definições não encontradas no primeiro sejam procuradas no segundo. É uma composição entre objetos da OO clássica porém feita de uma maneira muito mais simples. Ainda não temos sintaxe definida mas pense:
objOrigem|Forward>objAlvo
pronto, o que não for encontrado em origem, será buscado no alvo.
Ok, vamos falar de programação concorrente?
Javascript simplesmente não tem. Ele não implementa threads e não tem nenhum recurso para isso como um mero sleep. Não deixe que um setTimeOut te engane. Ele não rodará nada em outra linha de execução. Então caso sua função principal esteja engasgada num while, seu setTimeOut não levantará sua outra função. Seu programa estará travado.
Em Graphol então, a primeira providência é prover este suporte. Este é o mínimo. Mas acredito que possamos fazer mais. Também com ajuda das arestas.
Vamos supor que você queira sempre que uma função for acionada, uma outra rotina que coopere com esta, seja levantada em paralelo. Que tal algo como:
objPrincipal|startToStart>objAuxiliar;
Vamos supor que este objeto auxiliar deva executar um loop com algum processamento durante toda a vida do objeto principal. Mas que ao fim do primeiro o segundo tb deva ser derrubado. Então no corpo de objAuxiliar poderemos ter um while(true) e faríamos:
objPrincipal|finishToFinish>objAuxiliar;
Pronto! Ao fim do objPrincipal, o objAuxiliar tb será derrubado. Mesmo com o while true.
São muitas as opções. Estamos iniciando um rascunho. Mas deu para ver que temos pretensões diferentes ao Javascript?
Isto ficará mais claro nos próximos posts onde começaremos a discutir várias funcionalidades. Mas por hora, recomendo este post:
http://blog.renatolouro.com.br/2011/07/graphol-por-uma-nova-linguagem/
Lá eu abordo várias funcionalidades desejadas.
Abraços
Parabéns pela iniciativa, se não estivesse com tantos projetos para fazer e no início do meu mestrado iria adorar participar do desenvolvimento. Talvez caso me aceitem, posso tentar ajudar somente nos problemas teóricos da linguagem.
Meu mestrado inclusive é sobre algoritmos em grafos utilizando programação paralela.
Tenho algumas considerações a fazer em ordem de importância e gostaria da opinião de vocês:
1 – A documentação deve ser sempre excelente, caso desejem torná-la mundial. Muitas boas linguagens não são conhecidas e utilizadas devido a isto.
2 – A linguagem deve ser portável a qualquer ambiente.
3 – A linguagem deve ter uma leve inclinação para soluções científicas e softwares embutidos/firmware pois creio que serão utilizados mais nestes ambientes do que para soluções de softwares tradicionais.
4 – Para resolver o segundo item e torná-la muito interessante no quesito de utilidade acho legal a compilação gerar um código java, C e binário, para cada um dos ambientes descritos no item 3, e ser compilado pelos compiladores das respectivas plataformas.
5 – Para solucionar a definição dos métodos aceitos em cada nodo, sugiro a utilização da teoria das categorias, Haskell é uma linguagem interessante que implementa esta teoria. Conhecem Haskell?
6 – Permitir extensões para deixar as outras linguagens fazerem aquilo que fazem de melhor. Podemos ver hoje uma grande mistura de tecnologias e linguagem para a criação de uma solução.
Não se preocupe Vitor. Creio que o projeto Graphol irá durar -em termos de tempo- para além do seu mestrado. Então acredito que terá muitas oportunidades para participar do desenvolvimento.
Mas é claro que aceitamos sua contribuição para os problemas teóricos da linguagem. Até mesmo, comentários como este seu, já são uma grande ajuda. Pode se sentir já participando do projeto.
Vamos lá:
1 – Concordo. Nenhuma dúvida quanto a isso. Vamos nos esforçar nesta direção.
2 – Concordo. Temos várias alternativas: compilação para Bytecode compatível com a JVM, interpretador,compilação para C ansi,
3 – Também concordo. Sempre pensei que deveria ter um nicho na qual ela fosse uma das melhores soluções. Acho que a modelagem de grafos, e troca de mensagens entre nós via arestas já garante a linguagem uma certa inclinação para soluções científicas. Por exemplo, a criação de uma rede neural com graphol – com as mensagens sendo transmitidas e modificadas pelas arestas e ponderação pelos nós – deveria ser trivial. Nunca pensei quanto a softwares embutidos e ou firmware.
4 – Nunca pensei em compilado para código java, exatamente. Mas já pensei em compilação para JVM e C. Poderia tb funiconar como uma linguagem de extensão para C tal qual LUA.
5 – Haskell conheço de ler sobre, mas muito pouco. Desconheço a teoria das categorias. Vou ver sobre!
6 – Sim isso. Como falei, num primeiro momento pensei em C e plataforma Java com o bytecode. Podemos pensar tb em CLI do .NET.
Seu post já é, por definição uma ótima contribuição. Mas de qualquer modo, se puder dar uma olhada eventual pelo fórum onde estamos rascunhando a linguagem e dando alguns pitacos, já será fantástico!
Abraços