%w(Akita On Rails) * 2.0 - Design Patterns representam defeitos nas Linguagens Comments

Comment on 'Design Patterns representam defeitos nas Linguagens' by Rafael Ferreira

2007-07-13T17:21:00Z

Oi Fabio.

Escrevi uma resposta (meio longa) para os artigos do Dominus no meu blog, neste post: http://rfframblings.blogspot.com/2007/02/design-patterns-are-not-recipes.html

Comment on 'Design Patterns representam defeitos nas Linguagens' by AkitaOnRails

2007-07-13T17:21:00Z

Primeiro, “você” que dizer Mark Dominus. Claro, se estou colocando aqui é porque endorso uma boa parte disso.

Segundo, sou o primeiro a apontar Fred Brooks e dizer que “silver bullets” não existem. Assim como bug-free software não existe também.

Está claro no artigo: “Ruby on Rails” é um passo na direção na certa, mas não é “A” solução e qualquer um que apontar “A” solução, não sabe do que está falando.

Para o resto: RTFA

Comment on 'Design Patterns representam defeitos nas Linguagens' by Darth Vader

2007-07-13T17:21:00Z

Na minha opiniao, vc está equivocado em vários pontos e está assumindo que Ruby é uma “bala de prata”.

Sem padroes, como vc espera criar um software em camadas? Ou vc acha que pode misturar lógica de domínio com persistencia?? Tudo isso é feito pelo desenvolvedor e os padroes sao um guia para fazer isso de maneira correta. Nem tudo pode vim pronto, embutido numa linguagem. Varios e varios padroes exigem que o programador tome decisoes.

Padroes de projeto transcendem a tecnologia.

Comment on 'Design Patterns representam defeitos nas Linguagens' by Rangel

2007-07-13T17:21:00Z

Acho que o comentario do Luca diz td. Mas é otimo que novas linguagens pensem em “implantar” os design patterns para q se tornem mais eficientes. E com certeza eh verdade q cada sistema tem sua especificacao, criar a linguagem é “facil” dificil é conseguir q ela seja usada em diversos meios

Comment on 'Design Patterns representam defeitos nas Linguagens' by AkitaOnRails

2007-07-13T17:21:00Z

Olá Luca, pessoal. No mesmo post de Mark ele deixou um link para outra apresentação que fez sobre o assunto no passado e que gerou muita polêmica. Sua constatação foi que a maioria das pessoas enviava e-mails e criticava somente sobre os exemplos (“iterators” é um pattern simples demais para se comparar com MVC). Ou seja, davam mais atenção aos slides de exemplos de código do que nos slides onde a idéia em si era discutida. Parece que isso é comum em todo artigo do gênero. Luca, claro que entendi que seu objetivo não foi o de fazer um flame war. De qualquer forma cabe dizer que eu apenas não quis ser muito pedante nos detalhes.

É claro que as linguagens não se originaram de um único ponto comum, não existe uma herança genética formal entre linguagens. Fortran, Cobol, C seguem a escola de Alan Turing. Lisp, Scheme, Haskell, segue a escola de Alonzo Church. A partir daí cada inventor se inspira nos pontos que julga mais relevantes no seu tempo.

Aliás, para esclarecer essa genealogia eu sempre divulgo este link com a genealogia das principais (não de todas) linguagens e aproximadamente quais foram suas inspirações. Uma otima oportunidade de refletir o papel da linguagens nas história da computação. Só para se ter uma idéia, esse link ilustra apenas 50 das principais linguagens, mas o autor já encontrou uma listagem com cerca de 2500 já criadas. Reflitam bem, vejam quais foram as inspirações de suas linguagens favoritas e quais estão presentes como principais hoje, em 2006.

Comment on 'Design Patterns representam defeitos nas Linguagens' by Phillip Calçado "Shoes"

2007-07-13T17:21:00Z

http://guj.com.br/posts/reply/0/44869.java

Comment on 'Design Patterns representam defeitos nas Linguagens' by Luca Bastos

2007-07-13T17:21:00Z

Repito a mensagem porque usei formatação inadequada. Fábio, por favor apague o comentário anterior.

Algumas observações:

1. O exemplo citado usando a tal “classe orientada a objeto” em C, não atende ao mínimo que se pode desejar de algo orientado a objetos. Este é um dos motivos porque o Bjarne Stroustrup nunca usou C para qualquer coisa orientada à objetos. Veja The Design and Evolution of C++ do Bjarne Stroustrup, Addison-Wesley, 1994.

2. O desenvolvimento do LISP e do Cobol nos anos 60 não pode ser considerado como uma evolução do Fortran. E também o LISP não pode ser considerado como antepassado do C ou do C++. Quem herdou conceitos do LISP foi o Smalltalk.

3. A frase “cada nova linguagem melhora deficiências das anteriores” ignora que a maioria das linguagens foi criada para atender necessidades de determinados segmentos. Então a frase só teria sentido se fosse assim “cada nova linguagem melhora deficiências das anteriores no domínio dos problemas adequados a esta linguagem”. Ninguém usaria Java no lugar de Fortran ou Ruby no lugar de Cobol, a menos nos casos em que Fortran ou Cobol foi usado inadequadamente. Infelizmente nos tempos recentes muitos sistemas de baixa plataforma foram desenvolvidos usando tecnologia ou arquitetura inadequada e possivelemente deixarão um legado terrível. Alguns destes sistemas podem ser forte candidatos a serem reescritos em Java, C#, Ruby, Erlang ou o que ainda pode estar por vir.

Comment on 'Design Patterns representam defeitos nas Linguagens' by Rodrigo Alberto

2007-07-13T17:21:00Z

Muito bom esse artigo! É interessante pensar da maneira como o Rails resolve muitos Design Patterns, onde se perde muito tempo no desenvolvimento JEE.