O grupo no qual você está postando é um grupo da Usenet. As mensagens postadas neste grupo farão com que o seu e-mail fique visível para qualquer pessoa na internet.
Se você somente pudesse escolher UMA das duas opções, qual escolheria?
A) Fazer um software que implementasse todas as liberdades do manifesto do Sneer em múltiplas linguagens, com um protocolo comum e definido.
B) Fazer um framework que acabasse com a "palhaçada" na programação, com reusabilidade, bricks e signals, e todo um conceito inovador de padrões de programação.
Depois de responder esta pergunta, será que o sneer não poderia se transformar em dois projetos? Dois problemas precisam ser resolvidos ao mesmo tempo?
Finalmente alguém deu uma definição cool e sucinta pro meu trabalho do
dia-a-dia. Thanks mate!
E só pra não ficar dúvidas, trabalho no time B :-)
Será que temos que fazer essa divisão agora? Ou talvez até passou da
hora? Acho que o fator deterninante dessa discussao toda (que se
alastra desde o summit) não é nem um pouco tecnológica: onde arrumar
recursos "to keep the dream alive"?
On 6 nov, 02:13, Ricardo Andere de Mello <quilombodigi...@gmail.com>
wrote:
> Se você somente pudesse escolher UMA das duas opções, qual escolheria?
> A) Fazer um software que implementasse todas as liberdades do
> manifesto do Sneer em múltiplas linguagens, com um protocolo comum e
> definido.
> B) Fazer um framework que acabasse com a "palhaçada" na programação,
> com reusabilidade, bricks e signals, e todo um conceito inovador de
> padrões de programação.
> Depois de responder esta pergunta, será que o sneer não poderia se
> transformar em dois projetos? Dois problemas precisam ser resolvidos
> ao mesmo tempo?
> A) Fazer um software que implementasse todas as liberdades do > manifesto do Sneer em múltiplas linguagens,
Multiplas linguagens como? Mágica?
> com um protocolo comum e definido.
O protocolo comum vai emergir. Só não emergiu AINDA. Não vou investir tempo em desenhar e padronizar um protocolo q ninguem usa.
O problema de qq protocolo é que chega o ponto da semântica e aí é preciso uma representação em alguma linguagem.
E todos os serviços do Sneer vão ser replicados em todas as linguagens?
> B) Fazer um framework que acabasse com a "palhaçada" na programação, > com reusabilidade, bricks e signals, e todo um conceito inovador de > padrões de programação.
Acabar com a "palhaçada" na programação não é um alvo em si. É algo que não consigo evitar. Qual é a alternativa a signals, por exemplo? Ficar fazendo polling? addBagacaListener/removeBagacaListener pra toda e qualquer bagaca que precise de listeners (padrão JavaBeans)?
Que ninguem continue discutindo, por favor, sem me dar uma resposta específica pra isso.
Outra pergunta: se não forem bricks, a não ser q nós mesmos desenvolvamos todas as aplicações soberanas do mundo, como um usuário vai poder baixar de terceiros aplicações soberana (liberdade 7) de forma segura, q interoperem com as demais aplicações e serviçoes soberanos?
>> A) Fazer um software que implementasse todas as liberdades do >> manifesto do Sneer em múltiplas linguagens,
> Multiplas linguagens como? Mágica?
Entendi que a ideia seria implementar o que é o Sneer usando linguagens diferentes se comunicando e compondo um "programa" só.
>> com um protocolo comum e definido.
> O protocolo comum vai emergir. Só não emergiu AINDA. Não vou investir > tempo em desenhar e padronizar um protocolo q ninguem usa.
Sei que existem N desvantagens, mas se fosse para simplificar, eu usaria REST sobre HTTP até o ponto em que ficasse inviável (por questões de desempenho, por exemplo).
> E todos os serviços do Sneer vão ser replicados em todas as linguagens?
Talvez um dia alguns serviços serão replicados em algumas linguagens, não? Afinal, teremos a liberdade de ouvir música usando Python ou Java ou...
>> B) Fazer um framework que acabasse com a "palhaçada" na programação, >> com reusabilidade, bricks e signals, e todo um conceito inovador de >> padrões de programação.
Acho que não tem muito como fugir disso porque resolver o problema A implica em resolver alguns problemas que ainda não têm "a melhor solução possível", principalmente em se tratando de linguagens de programação. Nesses casos, uma boa implementação praticamente exige a construção de um framework ou coisa parecida para gerenciar a complexidade.
> "A" e "B" são dois lados do mesmo vinil.
Se eu quisesse uma implementação correta e elegante, ao estilo MIT, eu escolheria B para depois pensar em A. A desvantagem é que a implementação só apareceria daqui a alguns anos. Pelo menos seria uma implementação de alta qualidade.
Se eu quisesse uma implementação rápida, talvez como uma prova de conceito, ao estilo Worse Is Better, eu iria direto ao A para, com o tempo, substituir os componentes usando os resultados de B. A desvantagem é que a implementação poderia empacar devido às limitações das linguagens e frameworks atuais. Pelo menos o protótipo ficaria pronto rapidamente.
Dado o histórico do The Art of Computer Programming, GNU/Hurd e projetos igualmente homéricos, minha tendência no momento é escolher A.
> Depois de responder esta pergunta, será que o sneer não poderia se > transformar em dois projetos? Dois problemas precisam ser resolvidos > ao mesmo tempo?
Talvez, mas pelo que eu entendi isso poderia exigir a adaptação do que já está implementado no Sneer e isso pode não valer a pena.
> > A) Fazer um software que implementasse todas as liberdades do > > manifesto do Sneer em múltiplas linguagens,
> Multiplas linguagens como? Mágica?
Para mim o OMetaBoo bastaria...
> com um protocolo comum e definido.
O protocolo comum vai emergir. Só não emergiu AINDA. Não vou investir
> tempo em desenhar e padronizar um protocolo q ninguem usa.
> O problema de qq protocolo é que chega o ponto da semântica e aí é > preciso uma representação em alguma linguagem.
Concordo com o Klaus, e acrescento: acho que ainda não temos maturidade suficiente para especulativamente definir um protocolo para algo que nunca existiu antes. Digo isso depois de mais de um ano implementando sneer todos os dias. Realmente o melhor é esperar o protocolo emergir.
> > B) Fazer um framework que acabasse com a "palhaçada" na programação, > > com reusabilidade, bricks e signals, e todo um conceito inovador de > > padrões de programação.
> Acabar com a "palhaçada" na programação não é um alvo em si. É algo > que não consigo evitar. Qual é a alternativa a signals, por exemplo? > Ficar fazendo polling? addBagacaListener/removeBagacaListener pra toda > e qualquer bagaca que precise de listeners (padrão JavaBeans)?
> Que ninguem continue discutindo, por favor, sem me dar uma resposta > específica pra isso.
Quero algo melhor do que a estrutura em signals em java que bolamos, imagino que o boo novamente pode ser a saída. A programação de bricks num modelo reativo é interessante, mas é muito complexa. Com boo poderiamos simplificar e facilitar a vida do programador.
Opa, demorei para ler as respostas, mas concordei com as coisas que o Diogo falou.
só queria comentar a de baixo.
> Concordo com o Klaus, e acrescento: acho que ainda não temos maturidade > suficiente para especulativamente definir um protocolo para algo que nunca > existiu antes. Digo isso depois de mais de um ano implementando sneer todos > os dias. Realmente o melhor é esperar o protocolo emergir.
O XProtocol (X11), longe de ser perfeito, é um protocolo com mais de 20 anos de idade, e ele sobreviveu a centenas de avanços tecnológicos no Desktop durante este período (inclusive o 3D). O motivo? ele permite evolução. Solução simples e eficiente. Protocolos são conceitos básicos de normas de endereçamento, roteamento e empacotamento de dados. Não são escritos em pedra, são o "mínimo" para definir comunicação, e podem mudar a qualquer momento. A minha experiência diz exatamente o contrário do que vocês falaram. O protocolo vem primeiro. Foi assim com o email, foi assim com a web, com o gnutella (que fez surgir o p2p), com o json (formato de dados, mas ainda assim uma estruturação), e tantos outros. Eu quero fazer um serviço para o sneer que rode em um celular sem java e sem instrumentação, eu quero colocar no nokia n800, que roda python, quero colocar no playstation 3... :)
[]s, gandhi
ps.: Momento do comentário que dói: acho que o motivo maior para a divisão não ser feita é que recursos que poderiam estar evoluindo os bricks seriam utilizados em outras linguagens. por mim tudo bem, realmente seria como o histórico do Hurd, projeto lindo, mas sem recursos para executá-lo.
|
