Faculdades e compiladores

A definição de padrões não envolve sequer implementação:
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design.

Você terá problemas recorrentes em qualquer linguagem. E uma solução que naquela linguagem será melhor para aquele problema. Por isso eu digo. Se sua linguagem apresentar uma única solução, não haverá padrões. Se sua linguagem apresentar várias, uma delas será a melhor, e você a repetirá com frequência, logo, você tem um padrão.

Duvido muito que você prove para mim que você não tem "soluções melhores" para determinadas situações em lisp. Nem que seja um conjunto de macros que você já separou, pq sabe que elas quebram muitos galhos.

lina wrote:Exatamente. Geralmente o pessoal que entra na faculdade (voltada para o curso de computação), pensa que é tudo uma maravilha! Me lembro do primeiro dia de aula: O professor pergunta a classe: "Pq vocês estão fazendo este curso?"

A grande maioria: Pq eu gosto de joguinho... Pq eu sei desenhar no mspaint..

Vamos pensar.. o problema está na faculdade ou nas pessoas que escolhem o curso?!

Opinião: Em nenhuma das duas... o erro está no Sistema como um todo.

Estudamos a vida inteira (primeira serie até o terceiro ano) para fazer uma prova (com 17 anos), no qual definira o que deverei ser para o resto da vida.

Acho esse um bom ponto*. A maioria das pessoas que entram numa faculdade de computação (não só de computação, mas de qualquer outra coisa) geralmente não sabem o que estão fazendo ou o que estão querendo. O mesmo aconteceu no meu curso.

Estou lendo um livro chamado Inteligência Emocional (muito bom, por sinal) e, dentre os vários pontos que os autores abordam, existe a citação a um modelo diferente de ensino que esteve (não sei se está ainda) em fase experimental nos Estados Unidos, onde a escola foca muito mais nas aptidões sociais das pessoas, desde crianças, ao invés de usar o modelo ultra-tradicional de "testes-scripts" padrão para todo mundo (vestibular é um exemplo), o que força as pessoas a se esforçarem somente para conseguirem passar por alguns desses testes durante a vida, mas esquecem (ou ignoram) completamente as questões de convivência social, que vão ser muito mais importantes no restante da vida de qualquer um.

É um assunto muito interessante e talvez fosse uma boa forma de fazer com que somente pessoas com real aptidão, que realmente quisessem, seguissem a área de computação (ou, novamente, qualquer outra área). Assim pelo menos diminuiria a quantidade de pessoas frustradas por aí, entre outras coisas que poderiam melhorar.

* Embora estejamos destoando um pouco do assunto principal do tópico e talvez fosse melhor discutí-lo em outro post.

De resto, acho que esse post já entrou em algo tipo discussão do sexo dos anjos. Acho desnecessário prosseguir com isso.

GUJ Master Membro desde: 27/04/2006 21:01:27 Mensagens: 1134 Offline

ViniGodoy wrote:A definição de padrões não envolve sequer implementação:
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design.

E uma "solução" é o quê?

ViniGodoy wrote:
Você terá problemas recorrentes em qualquer linguagem. E uma solução que naquela linguagem será melhor para aquele problema. Por isso eu digo. Se sua linguagem apresentar uma única solução, não haverá padrões. Se sua linguagem apresentar várias, uma delas será a melhor, e você a repetirá com frequência, logo, você tem um padrão.

Padrões de projeto tem a ver com repetição de código para que funcione de determinada forma e não com quantidade de opções. Em Java mesmo pode-se usar DAO ou alguma API de mapeamento relacional/OO.

Por mais repetições que possam haver, uma linguagem decente lhe oferece a possibilidade de abstraí-las elegantemente. É quando não há tal possibilidade é que ela se torna um "padrão de projeto".

O exemplo de banco de dados é o mais fácil para qualquer um aqui porque é o mais comum. Todo acesso ao banco de dados para atividades CRUD deveria ser automatizado assim como é em frameworks como Rails. Algumas linguagens como Java não permitem, e é por isso que usasse padrões de projeto.

GUJ Expert Membro desde: 20/02/2008 12:32:59 Mensagens: 3372 Offline

Thiagosc wrote:
O código Lisp é uma árvore. O que mais são árvores? Documentos XML? Árvore de componentes de uma Janela ou algum objeto 3D? Preciso desenhar para você entender ou meia palavra basta?

Não sei em que ponto da frase você e o mochuara entenderam que eu não sei Lisp. Eu disso que não GOSTO de Lisp, conhecer, conheço muito bem porque já trabalhei comercialmente com ela por 2 anos.

E, como eu também postei, é uma opinião particular, não disse que era ruim.

Sobre ser uma árvore, não vejo nada revolucionário disso, como você mesmo citou. Só que considero que existem formas bem mais simples e produtivas de trabalhar dessa forma do que a que o Lisp se propôs.

Vamos parar com o mimimi e voltar ao assunto do tópico?

This message was edited 1 time. Last update was at 30/12/2009 08:28:06

Thiagosc wrote:Padrões de projeto tem a ver com repetição de código para que funcione de determinada forma e não com quantidade de opções. Em Java mesmo pode-se usar DAO ou alguma API de mapeamento relacional/OO.

Ok, Thiago. Se você tem uma definição pessoal de padrões de projeto, e é nela que você vai se basear, realmente, não vale a pena levar a discussão à diante.

marcosalex wrote:Não sei em que ponto da frase você e o mochuara entenderam que eu não sei Lisp. Eu disso que não GOSTO de Lisp, conhecer, conheço muito bem porque já trabalhei comercialmente com ela por 2 anos.

E, como eu também postei, é uma opinião particular, não disse que era ruim.

Não liga não, marcos. O thiago gosta de ofender com afirmações desse tipo.
Você não viu que ele falou diretamente para mim a mesma coisa?

Vamos parar com o mimimi e voltar ao assunto do tópico?

Também acho.

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

A faculdades já tem uma disciplina somente de compiladores, mas a ponto de implementar closures até o final do semestre, não. Não dá tempo. Talvez isso seja visto com em alguma matéria de tópicos especiais em compiladores. Mesmo assim acho que não dê tempo, a curva de aprendizado é bem inclinada, a maioria se mata só de fazer os parsers, produção e análise de ASTs, e até chegar em análise de contextos, e entender closures, isso fica mais para tema de mestrado.

De qualquer forma, na faculdade eu mais me beneficiei das matérias mais básicas, como Algoritmos e Estrutura de Dados, e avançadas, de Teoria de Linguagens Formais, Autômatos e Computabilidade, e Sistemas Operacionais que de compiladores propriamente.

GUJ Master Membro desde: 27/04/2006 21:01:27 Mensagens: 1134 Offline

ViniGodoy wrote:Ok, Thiago. Se você tem uma definição pessoal de padrões de projeto, e é nela que você vai se basear, realmente, não vale a pena levar a discussão à diante.

Essa não é a minha definição, foi aquela que você colou aqui:

ViniGodoy wrote:
A definição de padrões não envolve sequer implementação:
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design.

Uma solução é uma implementação.

GUJ Master Membro desde: 27/04/2006 21:01:27 Mensagens: 1134 Offline

marcosalex wrote:Não sei em que ponto da frase você e o mochuara entenderam que eu não sei Lisp. Eu disso que não GOSTO de Lisp, conhecer, conheço muito bem porque já trabalhei comercialmente com ela por 2 anos.

Você não sabe bulhufas de Lisp, e é fácil de dizê-lo pela quantidade de besteiras que você colocou aqui. Duvido que você tenha realmente trabalhado e se de fato fez alguma coisa, ou foi algo simples que não explorava a capacidade da linguagem ou então foi manutenção de código pronto onde você raramente precisa mexer no código.

marcosalex wrote:
Sobre ser uma árvore, não vejo nada revolucionário disso, como você mesmo citou. Só que considero que existem formas bem mais simples e produtivas de trabalhar dessa forma do que a que o Lisp se propôs.

Você não vê porque é cego. Então azar o seu.

Trabalhar com uma estrutura de árvore diretamente e mais macros possibilita simplesmente extender a linguagem com novas construções sintáticas que são processadas em tempo de compilação, ou seja, zero impacto em termos de performance e muito provavelmente ganhos em termos de otimização de código. Otimização essa que é impossível de ser feita em Java ou em C++.

Um leque de oportunidades se abre com isso. Existiria Hibernate se o Java tivesse essa capacidade? E Spring? É fácil ver como todos os frameworks de Java existem somente porque a linguagem é limitada. O mesmo se aplica a C#, C++, etc.

Thiagosc wrote:Otimização essa que é impossível de ser feita em Java ou em C++.

Na verdade, tem muita coisa que é possível em templates com C++.
E código que será processado também em tempo de compilação.

Talvez não seja tão poderoso quando Lisp mas, de qualquer forma, é um recurso que está lá.

thiagosc wrote:Padrões de projeto tem a ver com repetição de código para que funcione de determinada forma e não com quantidade de opções.

Padrões de projeto só tem a ver com repetições de código, porque são soluções boas. E, portanto, você vai preferi-las muitas vezes, a outras possíveis soluções.

Pegue por exemplo persistência. Podemos faze-la de diversas formas:
a) Poderíamos criar métodos como salvar() e carregar na própria classe;
b) Poderíamos deixar a responsabilidad de salvar e carregar para uma classe externa;
c) Poderíamos criar uma classe cheia de métodos estáticos para fazer esse trabalho.

Qual das três opções é a melhor? Que vantagens e desvantagens tenho em cada uma?
E na hora de implementar, existe algum cuidado que eu deva tomar?

Geralmente, em software, somos confrontados com problemas recorrentes (como persistir dados), e para eles temos que apresentar uma solução. Entretanto, a experiência geralmente nos leva a uma solução ótima, pelo menos para um dado tipo de problema.

Essa solução ótima, que acabaremos repetindo (seja diversas vezes no código, como no Java, ou uma vez só por programa, como vc diz ser no Lisp), será o padrão. Não existe imposição de que um padrão deva ser escrito várias vezes no mesmo código. Aliás, os padrões nem sequer envolvem o código diretamente.

Não estou falando que uma linguagem não possa apresentar recursos que extinguam, para aquela linguagem, um ou outro padrão. Mas inexistência de padrões, só vai ocorrer a partir do momento que você não tiver opções. Se a linguagem te der uma, e uma única, forma de fazer as coisas. Caso contrário, você terá sim, optado por uma, pesado suas vantagens e desvantagens, e criado um padrão.

Seja honesto. Você está me dizendo que no lisp, não existe absolutamente nenhuma construção que, para um problema, você saiba que é boa e use no seu programa, nem que seja declarando uma única vez? Mas que, num novo programa, lá estará você de novo, refazendo aquela construção que te quebra um galhão?

GUJ Master Membro desde: 27/04/2006 21:01:27 Mensagens: 1134 Offline

ViniGodoy wrote:Não estou falando que uma linguagem não possa apresentar recursos que extinguam, para aquela linguagem, um ou outro padrão. Mas inexistência de padrões, só vai ocorrer a partir do momento que você não tiver opções. Se a linguagem te der uma, e uma única, forma de fazer as coisas. Caso contrário, você terá sim, optado por uma, pesado suas vantagens e desvantagens, e criado um padrão.

Se a linguagem oferece recursos para adicionar novos significados sintáticos para serem compilados então eliminaram-se todos esses problemas.

ViniGodoy wrote:Seja honesto. Você está me dizendo que no lisp, não existe absolutamente nenhuma construção que, para um problema, você saiba que é boa e use no seu programa, nem que seja declarando uma única vez? Mas que, num novo programa, lá estará você de novo, refazendo aquela construção que te quebra um galhão?

Sim, não há nenhuma estrutura. Tudo pode ser programado através das features da linguagem.

Voltando ao tema do tópico, vale muito a pena ver esse artigo, escrito pelo Bjarne Stroustrup, sobre o gap entre o aprendizado da ciência da computação e a necessidade da indústria: http://cacm.acm.org/magazines/2010/1/55760-what-should-we-teach-new-software-developers-why/fulltext

This message was edited 1 time. Last update was at 04/01/2010 14:45:47

Também vale a pena ver a apresentação do Peter Norvig, um dos mais importantes pesquisadores na área de IA, sobre design patterns em linguagens dinâmicas, com exemplos em LISP e Dylan: http://norvig.com/design-patterns/index.htm

GUJ Master Membro desde: 27/04/2006 21:01:27 Mensagens: 1134 Offline

ViniGodoy wrote:Também vale a pena ver a apresentação do Peter Norvig, um dos mais importantes pesquisadores na área de IA, sobre design patterns em linguagens dinâmicas, com exemplos em LISP e Dylan: http://norvig.com/design-patterns/index.htm

Essa apresentação apenas fala sobre implementações de design patterns de C++ em Lisp e Dylan. Assim como você pode escrever Java em Ruby se quiser, mas isso seria desperdiçar os recursos da linguagem, nada impede que você recrie design patterns de outras linguagens em Lisp.

Notícias, artigos e o maior fórum brasileiro sobre Java