[quote=fredferrao][quote=mochuara][quote=fredferrao]
Mas sua resposta foi exatamente o esperado, quase nenhum argumento tecnico e muita tatica troll em tentar desacreditar o adversario(sim adversario porque no mundo troll isso aqui é um campo de batalha).
Que tal voce parar de atacar os outros e postar argumento do porque voce pensa o contrario, mas argumentos concretos, tecnicos com exemplos e fatos.[/quote]
Vou ver se acho alguma referencia “Lisp para dummies” pra te passar. Mas vc pode comprovar a superioridade de Lisp sem precisar ir muito longe, faça um teste alternando entre Java e C# que são praticamente cópia uma da outra e veja se os patterns que vc criou para uma lhe servira, no minimo como inspiração, ou vai precisar rescrever tudo.[/quote]
Mesma atitude e nada de novo a acrescentar.
Nunca disse em momento algum que seriam os mesmos patterns.[/quote]
Eu já repeti isso diversas vezes também, inclusive com referência bibliográficas (ver o site do Norvig).
A diferença está no entendimento deles sobre patterns. Provavelmente a literatura das linguagens dinâmicas (e elas fazem isso o tempo todo), venderam para eles que pattern = repetição.
Mas o pattern não é repetição. Dizer isso é confundir o efeito com a causa.
Pattern é identificar as melhores situações, para determinados problemas. As linguagens normalmente te fornecem mais de uma maneira de se fazer as coisas, e uma delas será preferível em relação a outras. Ou seja, em tentar identificar estruturas que representam boas escolhas. Isso não só existe em Java e em LISP, como existe também na construção civil, na culinária ou em qualquer atividade humana.
A repetição só é uma consequência, pelo fato de uma solução boa geralmente ser reutilizável. Não duvido que muitos programadores LISP façam o que você falou. Assim que iniciam um novo programa vão na sua “biblioteca de macros legais” e já a reutilizem algumas dependendo da situação que encontrem. Isso é aplicar um pattern, mesmo que ele apareça uma única vez, no código fonte do projeto inteiro.
A diferença fundamental, é que o pattern representa uma maturidade da comunidade. Como quando programadores se juntam em uma convenção, mostram as diversas formas que usam para resolver seus problemas, identificam as mais comuns, ou as que trazem mais vantagem, e formalizam isso num documento. Era exatamente sobre isso que a pesquisa do GoF se tratava.
Não consigo acreditar que em LISP não haja esse tipo de maturidade por parte da comunidade, e que não existam escolhas que em LISP uma seja preferível em relação à outra. Como eu falei, a única possibilidade que vejo para não existirem padrões é se a linguagem apresentar uma única forma de fazer as coisas.
O que consigo acreditar é que realmente a implementação final do pattern fique muito elegante, de modo a não existir, para um mesmo projeto, repetições de código.