Prosseguindo com a série de posts sobre artigos clássicos da computação, avançamos duas décadas a partir do End-to-end Arguments, para chegar à OOPSLA 98. Se o leitor considera um paper publicado em 98 recente demais para ser considerado um verdadeiro clássico, fique tranquilo que o autor é Guy Steele. Co-autor da especificação da linguagem Java, chairman do comitê de padronização do Common Lisp, co-criador do Emacs e autor da linguagem Scheme, ele é um dos pesquisadores mais importantes na área.
O clássico desta vez é Growing a Language, texto de uma palestra apresentando uma abordagem evolucionária para o projeto de linguagens de programação. Steele defende a tese de que novas linguagens devem ser conceptualizadas como um pequeno núcleo de primitivas a ser extendido transparentemente pelos usuários. Com o tempo a linguagem cresce através das adições da comunidade, em um modelo muito similar ao dos projetos de software de código aberto. Sua argumentação é feita ressaltando especialmente os aspectos sociais da adoção de linguagens de programação, sugerindo vários pontos em comum com a literatura de metodologias ágeis de programação (design incremental) e patterns (descrições contextualizadas de abstrações). Uma menção importante é feita ao artigo Worse Is Better, do Richard Gabriel, que está na minha fila de clássicos. O artigo não aborda diretamente a motivação estética para linguagens inerentemente extensíveis, provavelmente com bons motivos.
"Growing a Language" também lembra um assunto que está, tipo assim, super na moda: as Domain Specific Languages (DSLs). A idéia básica é tratar parte do projeto de software como projeto de uma linguagem versando sobre o domínio da aplicação. A partir daí existem várias interpretações: tem quem defenda que usuários finais, especialistas no negócio, sejam responsáveis por editar as DSLs para acompanhar mudanças no ambiente; outros pensam que , de alguma maneira, todo desenvolvimento de software é a criação de DSLs; outros ainda acreditam que as DSLs são melhor expressadas como linguagens gráficas de modelagem. E os programadores de Lisp dizem, como sempre, que já fazem esse tipo de coisa há décadas de maneira muito mais elegante e não entendem todo o fuss atual. O texto do Steele o situa entre aqueles que enxergam todo projeto de sofware como projeto de DSL, e ele defende que a linguagem de programação básica seja criada tendo isto em mente.
Tudo isso é muito importante, mas o texto do paper também é imperdível por seu genial desenvolvimento metacircular. Não entendeu? RTFA.
Monday, February 27, 2006
Friday, February 17, 2006
Clássicos
Minha mais nova tentativa de tentar transformar esta porta de banheiro binária em algo minimamente útil será uma série de comentários breves sobre artigos clássicos na área da computação. O gerador de clichês dentro do meu cérebro, condicionado por milhares de horas de hipnóticas aulas de redação, não me deixa continuar este post sem explicar o que entendo por "artigos clássicos", então vamos tentar uma definição por oposição: não são selecionados de acordo com qualquer métrica acadêmica; não são os 'melhores' textos, apenas os mais importantes dentre os pouquíssimos que lí; não busco cobrir nenhum escopo prévio, especialmente não tenho ilusões sobre cobrir o todo da ciência da computação; e nem todo clássico é velho (pelo menos aqui...).
Para facilitar, vou listar aqui os links para os posts nesta série:
Numa primeira leitura, o artigo parece tratar de uma consideração arquitetural relevante, mas não mais importante que as tantas outras restrições que tiram o sono de desenvolvedores há decadas. O que torna o argumento dos professores especialmente importante é que entre suas implicações econômicas encontramos (suspense...) a Internet. Antes que alguém dispare o seu cliente de email na direção de um inocente, aviso que, sim, eu sei que a internet e o TCP/IP já existiam há um bom tempinho quando os nobres professores escreveram o paper, mas seu objetivo é descrever um fenômeno observado, não apresentar nenhuma nova e mirabolante idéia. Aliás, a maioria dos artigos nesta série não versam sobre novidades e invenções. Do que eu estava falando mesmo?
Pop(), pop(). Ok, a Internet. Pergunte a qualquer engenheiro de comunicações o que ele acha sobre a estrutura da internet e ele contentemente respoderá que é um negócio que até funciona mas poderia ser muito melhor. Ela não contempla, por exemplo, segurança (ip-sec?) e garantia de qualidade de transmissão (QoS? RSVP? ATM?). É, em outras palavras, uma rede bastante burra. Entretanto, é inegável que modificou violentamente a economia e a sociedade na última década (para o bem e para o mal). Imagine um cenário alternativo onde QoS fosse implementado de ponta a ponta na internet, permitindo que se reservem faixas de banda para determinadas aplicações. Finalmente video-on-demand seria uma realidade! O preço a pagar é que a rede deixaria de ser um campo neutro onde empresas florescem a todo tempo (que meigo) para se tornar um mercado imobiliário onde quem pode pagar mais por naco de banda excluí a priori qualquer competidor potencial. Mais sobre esse assunto dos próprios autores do clássico ou, mais eloquentemente, do senhor Lessig.
Esse último texto foi apresentado ao congresso americano pedindo legislação que impeça o comprometimento da isonomia entre aplicações, contrariando os planos das grandes empresas telefônicas. Donas dos backbones da Internet, elas ameaçam cobrar para dar preferência a determinados serviços em detrimento de outros nas "suas" redes. Confirmando sua vocação para clássico, vemos que as observações do "End-to-end arguments in system design" continuam, mais que atuais, prementes.
Para facilitar, vou listar aqui os links para os posts nesta série:
- End-to-end Arguments in System Design, por Reed, Saltzer e Clark,
- Growing a Language, por Guy Steele,
- No Silver Bullet, por Fred Brooks.
Numa primeira leitura, o artigo parece tratar de uma consideração arquitetural relevante, mas não mais importante que as tantas outras restrições que tiram o sono de desenvolvedores há decadas. O que torna o argumento dos professores especialmente importante é que entre suas implicações econômicas encontramos (suspense...) a Internet. Antes que alguém dispare o seu cliente de email na direção de um inocente, aviso que, sim, eu sei que a internet e o TCP/IP já existiam há um bom tempinho quando os nobres professores escreveram o paper, mas seu objetivo é descrever um fenômeno observado, não apresentar nenhuma nova e mirabolante idéia. Aliás, a maioria dos artigos nesta série não versam sobre novidades e invenções. Do que eu estava falando mesmo?
Pop(), pop(). Ok, a Internet. Pergunte a qualquer engenheiro de comunicações o que ele acha sobre a estrutura da internet e ele contentemente respoderá que é um negócio que até funciona mas poderia ser muito melhor. Ela não contempla, por exemplo, segurança (ip-sec?) e garantia de qualidade de transmissão (QoS? RSVP? ATM?). É, em outras palavras, uma rede bastante burra. Entretanto, é inegável que modificou violentamente a economia e a sociedade na última década (para o bem e para o mal). Imagine um cenário alternativo onde QoS fosse implementado de ponta a ponta na internet, permitindo que se reservem faixas de banda para determinadas aplicações. Finalmente video-on-demand seria uma realidade! O preço a pagar é que a rede deixaria de ser um campo neutro onde empresas florescem a todo tempo (que meigo) para se tornar um mercado imobiliário onde quem pode pagar mais por naco de banda excluí a priori qualquer competidor potencial. Mais sobre esse assunto dos próprios autores do clássico ou, mais eloquentemente, do senhor Lessig.
Esse último texto foi apresentado ao congresso americano pedindo legislação que impeça o comprometimento da isonomia entre aplicações, contrariando os planos das grandes empresas telefônicas. Donas dos backbones da Internet, elas ameaçam cobrar para dar preferência a determinados serviços em detrimento de outros nas "suas" redes. Confirmando sua vocação para clássico, vemos que as observações do "End-to-end arguments in system design" continuam, mais que atuais, prementes.
Subscribe to:
Posts (Atom)