DrDobbs2007 - 25/07 Almoço
Após a palestra xarope sobre pseudo-Domain Models foi a hora do almoço com direito à keynote de Ivar Jacobson. Se você acompanha a Dr. Dobbs sabe que o cara -um dos pais da UML e do RUP- está cansado de processos e foi sobre isso sua palestra. Eu estava esperando para comentar sobre a série de artigos aqui em algum momento, pelo visto vai ser agora.
Imagine uma empresa que constrói sistemas. Agora imagina que ela só domina Struts e Hibernate como ferramentas. Todos os projetos, se exceção, são feitos nestas duas plataformas, e pior: os desenvolvedores só usam o que leram em tutoriais na Internet, ninguém sabe de fato utilizar as próprias ferramentas. Além de usar a dupla para implementar aplicações tão pequenas quanto um “fale conosco” (quem nunca viu uma aplicação que nem SGBD acessava e tinha os JARs do Hibernate no classpath?) a empresa usa mal e porcamente as ferramentas quando precisa de fato, simplesmente porque usar ou implantar não significa usar corretamente.
É assim que Jacobson vê a implantação de projetos nas empresas, e disso que ele está cansado. “Ninguém lê livros sobre processos”, ele exclama e isso embasa toda a minha série de posts sobre “pare de se enganar: você NÃO usa RUP”.
O que Ivar propõe é o foco no uso de práticas que fazem sentido. Vê-lo falar (e sacanear o Scott Ambler, na primeira fila, ocasionalmente) fazia transparecer a sabedoria que décadas tentando enfiar conhecimento na cabeça dos outros traz e as consequências que se chega. Recomendo os artigos, vamos focar no tema em outra ocasião.
Logo depois parti para um talk de Juha-Pekka Tolvanen com título “Creating a Domain-Specific Modeling Language: Hands-On”. propaganda da MetaCase apenas, que eu considero um bom case de DSL mas não gosto da ferramenta. Acho que as pessoas precisam aprender que RAD não deu certo para sistemas de verdade e não dará para definição de DSLs, que são programas em si. Que saudades da sabedoria do Jacobson! Bom, fiquei na sessão para recarregar a bateria do meu notebook de qualquer forma…
July 26th, 2007 at 2:18 am
O velhinho tem mais de 90… desenvolve software desde o tempo que a gente nem tava no saco dos nossos pais…
Recomendo este:
http://www.jaczone.com/papers/agility.pdf
July 26th, 2007 at 8:59 pm
“Acho que as pessoas precisam aprender que RAD não deu certo para sistemas de verdade e não dará para definição de DSLs”. M. Fowler escreceu sobre “Language Workbenches”, inspirado, se não me falha a memória, em alguns estudos que fez com a Intentional Software e com a JetBrains. AMbas as empresas estão desenvolvendo produtos nessa área, com o objetivo de resolver a impedância programador -> analista de negócio, elevando o nível de abstração com a criação de tools para que o analista possa escrever o seu conhecimento em linguagens que ele entenda(tabelas,diagramas,hierarquias). A idéias dessas duas empresas não é facilitar a criação de DSLs “textuais” apenas, mas de permitir que outros tipos de representação de conhecimento computáveis. Acho que tem algo surgindo nisso aí. Afinal, você não acha estranho representar algo que o analista diz em poucas palavras, o qual vc entende a lógica e fecha o conceito, em páginas e páginas e páginas de palavras em linguagens de programação?
July 26th, 2007 at 11:22 pm
Eu não falei em DSLs textuais, Bairos (na verdade minhas apresentações sobre DSLs focam justamente no Excel), falei na forma como se produz DSLs, e note que RAD não significa drag’n'drop nem drag’n'drop significa RAD, eu posso ter RAD com texto (Rails é uma prova viva). Dê uma olhada nos demos do metacase e veja o que é RAD neste contexto.
Resumindo: O problema não é a DSL gerada ser RAD o problema é o engenho que cria DSLs (o workbench) ser RAD
July 27th, 2007 at 4:48 pm
Vou dar uma olhada sim, pra garantir que eu esteja falando da mesma coisa :) Acho que entendi o que vc quis dizer: Assim como a geração de código do Rails gera um rhtml não muito adequado para uma app real, um gerador de DSLs sofreria do mesmo problema. De qualquer forma, um bom suporte de ferramenta para a criação de DSLs e suas tools(editores com code-completion, ou editores visuais,etc) são um bom caminho. É nessa linha que a JetBrains parece estar seguindo. Vou ver os demos.