Talvez o caminho seja mesmo deixar de tentar adaptar o que é feito no desktop para a internet e criar algo baseado na arquitetura da mesma.

Inicialmente poderiam ser DSLs e, depois, uma linguagem completa focada nisso (ou seja, uma grande DSL para Web ). Não estou por dentro desses assuntos, você sabe se já existem linguagens 100% focadas na web?

—

Samir, sim, por isso que eu disse que Rails e Django são necessários hoje. A questão para mim é que ambos fragmentam tanto o problema por causa de idiossincrasias em cada um dos dois que acabam resolvendo um lado e atrapalhando outro.

—

Lucas, realmente é um assunto meio nebuloso.

No momento eu estou pensando em como o uso de DSL focadas em uma representação Web de um problema poderia ajudar na questão. Ainda não consegui chegar a nenhuma conclusão específica e daí o texto para tentar fomentar um debate em cima do tema.

Eu comecei a pensar em especificações executáveis depois que passei a usar o Story Runner do RSpec. O interessante do uso do Story Runner é que você tem uma mímica do que precisa resolver em seu problema em um nível mais alto. Se isso fosse traduzido em algo capturável–talvez por meio de eventos ou coisa assim–talvez fosse possível pensar na especificação como o problema.

Bem, eu posso e deve estar viajando. Mas é um assunto ao qual pretendo me dedicar um pouco esse ano e tentar experimentar com alguma coisa.

O “problema” é que sabemos que tem que melhorar, conseguimos dissertar sobre isso mas, quando chega a hora da implementação, ainda fica tudo um pouco nebuloso demais.

Acredito que isso é normal pois, como ciência, a informática ainda é *muito* nova em comparação à praticamente todas as outras.

Você tem alguma idéia de como seria uma implementação menos focada nas interfaces e mais centrada no domínio? Como você mesmo citou, talvez as especificações executáveis sejam um caminho interessante, tendo ainda muito à evoluir.

Eu entendo, é claro, que nesse sentido ainda estamos perseguindo uma solução um pouco melhor do que usamos hoje mas o tipo de metodologia empregada por Rails, Django e outros vai contra uma combinação de bottom-up e top-down que eu particulamente acho mais interessante.

No caso do Rails, por exemplo, a ênfase na transformação de modelos em classes que atendem a um protocolo REST é um erro. É claro que em qualquer sistema, o nível de troca de informação entre objetos tende a crescer exponencialmente e o que o Rails está fazendo é fragmentar isso para tornar o processo mais gerenciável. Mas eu não sei até que ponto isso deveria ser o alvo. A solução me parece curto termo demais para valer a pena.

O Seaside segue uma linha mais afinada com o próprio ambiente Smalltalk, focando bastante no problema mas ainda não é o ideal. Se você comparar exemplos de Seaside com exemplos em Rails, fica gritante o fato de que os primeiros estão mostrando o desenvolvimento de uma posição sistematicamente mais alta enquanto no caso dos outros, a ênfase é sempre em como o Rails reduz linhas de código, como tudo é muito simples e por aí vai. São muito raras as análises do Rails do ponto de vista de desenho de sistema. O pessoal do Rails Way estava fazendo isso mas sumiram.

É claro que o Rails não é o culpado. Django e todos outros clones usam mais ou menos a mesma linha. É um sinal dos tempos, na verdade, e necessário. Mas eu acho que precisamos pensar um pouco mais sobre o assunto.

Espero ter explicado um pouco mais da minha motivação.

Só não entendi muito bem o intuito da afirmação abaixo:

“… 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.”

Acredito que essa “fragmentação” no Rails, por exemplo, cria mais soluções do que problemas. Infelizmente ainda estamos bem presos a controllers e views (e, em muitas plataformas, ainda é pior do que isso), o que tira o foco do domínio do problema.

Mas acho que não compreendi bem o intuito, então creio que seria interessante se você desenvolvesse mais esse argumento.