Faculdades e compiladores

[quote=lina]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.[/quote]
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.

[quote=ViniGodoy]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. [/quote]

E uma “solução” é o quê?

[quote=ViniGodoy]
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.[/quote]

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.

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?

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.

[quote=marcosalex]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.
[/quote]

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?

Também acho.

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.

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

[quote=ViniGodoy]
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. [/quote]

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

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.

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.

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á.

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?

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

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

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.

É melhor você ler a apresentação direito, porque não é isso que ela fala não.

Ele considera os recursos da linguagem, explica os diferentes patterns levando em consideração recursos como multi-métodos e macros, e explica que patterns sofrem modificações ou ficam invisíveis e fala de patterns exclusivos dessas linguagens.

Se você não conhece, o Norvig é um dos maiores especialistas na área. A IA também é uma das disciplinas que mais usa linguagens funcionais.

É melhor você ler a apresentação direito, porque não é isso que ela fala não.

Ele considera os recursos da linguagem, explica os diferentes patterns levando em consideração recursos como multi-métodos e macros, e explica que patterns sofrem modificações ou ficam invisíveis e fala de patterns exclusivos dessas linguagens.

Se você não conhece, o Norvig é um dos maiores especialistas na área. A IA também é uma das disciplinas que mais usa linguagens funcionais.[/quote]

Ele não fala palavra por palavra, mas é isso que apresenta. Inclusive no final há uma bibliografia de livros sobre design patterns. Ele inclusive cita a “simplificação” de patterns quando transportadas para o Lisp por essa linguagem oferecer muitos mais recursos. E ainda tenta criar algumas novas patterns.

Programar patterns em Lisp é possível, assim como você pode programar C em Java colocando todos os métodos como static em uma única classe. Mas não é a forma correta de se trabalhar. Lisp promove uma forma iterativa de desenvolvimento, o que em si elimina a existência de “patterns”.

[quote=ViniGodoy]
Ele considera os recursos da linguagem, explica os diferentes patterns levando em consideração recursos como multi-métodos e macros, e explica que patterns sofrem modificações ou ficam invisíveis e fala de patterns exclusivos dessas linguagens.

Se você não conhece, o Norvig é um dos maiores especialistas na área. A IA também é uma das disciplinas que mais usa linguagens funcionais.[/quote]

Ué, não é isso que esta sendo dito sobre Lisp desde o inicio deste topico? Que os patterns são eliminados pela linguagem?

[quote=Thiagosc]Vocês acham que a qualidade dos profissionais aumentaria dramaticamente se as faculdades tivessem uma disciplina somente para compiladores? Geralmente isso é visto em pós-graduação, mas acredito que isso é essencial para qualquer um. Talvez assim existisse menos idéias erradas com linguagens, pois as pessoas entenderiam como aquele texto é transformado em bytes.

Existe uma diferença entre entender o que é uma closure e como funciona uma closure. Quando você sabe como funciona é possível ter uma idéia muito melhor a respeito do valor de determinadas features e entender seus custos, seja em termos de tempo de CPU ou de desenvolvedor.

[/quote]

cara não sei a sua faculdade… mas a minha que é de Ciencia da Computação tivemos praticamente 2 anos de compiladores…
1 ano de compiladores e 1 ano de Automatos e GLC que é praticamente a base de um compilador… o livro do dragãozinho (quem ja estudou compiladores conhece este livro o qual não me lembro o nome) tive que praticamente devorar ele… e em 1 ano tivemos que re-fazer o compilador do pascal…

na minha opinião ésta é uma das matérias que mais valeu apena no meu curso…

[quote=luistiagos][quote=Thiagosc]Vocês acham que a qualidade dos profissionais aumentaria dramaticamente se as faculdades tivessem uma disciplina somente para compiladores? Geralmente isso é visto em pós-graduação, mas acredito que isso é essencial para qualquer um. Talvez assim existisse menos idéias erradas com linguagens, pois as pessoas entenderiam como aquele texto é transformado em bytes.

Existe uma diferença entre entender o que é uma closure e como funciona uma closure. Quando você sabe como funciona é possível ter uma idéia muito melhor a respeito do valor de determinadas features e entender seus custos, seja em termos de tempo de CPU ou de desenvolvedor.

[/quote]

cara não sei a sua faculdade… mas a minha que é de Ciencia da Computação tivemos praticamente 2 anos de compiladores…
1 ano de compiladores e 1 ano de Automatos e GLC que é praticamente a base de um compilador… o livro do dragãozinho (quem ja estudou compiladores conhece este livro o qual não me lembro o nome) tive que praticamente devorar ele… e em 1 ano tivemos que re-fazer o compilador do pascal…

na minha opinião ésta é uma das matérias que mais valeu apena no meu curso…[/quote]

Verdade, todo curso de ciencia de computacao tem materia de compiladores.

Eu tive essa matéria com um Professor tão ruim, que na primeira aula ele disse que HTML era linguagem de programação interpretada, depois disso acabou o semestre :twisted: