Faculdades e compiladores

bom…claro que patterns são só um exemplo, de qualquer jeito mesmo que tenham sido criados para que muitos programadores parem de fazer merda, a linguagem não tem nada a ver com isso, fazer código ruim é possivel em qualquer linguagem… por mais que alguma linguagem tenha recursos para melhorar a reusabilidade, criação de definição de classes… assim mesmo em qualquer linguagem é possivel fazer merda (com isso ou sem isso, e os patterns por exemplo vão exatamente contra essas más praticas) agora, falar que alguma pratica seja ruim, não por que a a pratica em si o seja mais sim por serem ruins as más praticas que fizeram ser criados os patterns… você simplesmente está distorcendo os fatos… patterns foram criados para dizer não faça do jeito a por que a é ruim pelos motivos x, y e z, faça do jeito b por que evita estes problemas e melhora em c, d e f… se você pode criar definições de classes para facilitar a criação do seu dao repetitivo por exemplo, você ainda está usando o padrão, só que na sua “linguagem superior” (confesso que nunca tinha lido nada a respeito desse tipo de recurso,achei interessante, mais isso não muda nada quanto aos patterns).

por isso e por ja ter lido muita coisa que você ja escreveu antes e conhecer seus argumentos que começo aqui a seguir o pedido da figura do davidbuzatto…

Acho que essa uma das maiores bobagens que já foram pronunciadas na história da informática. Definitivamente, argumento de alguém que queria vender uma linguagem, e o que mais me impressiona, ver gente da área técnica repetindo a ladainha.

O que vai acontecer é que uma determinada linguagem poderá realmente tornar desnecessário certos patterns, ou simplificar seu uso, mas em pouco tempo, ter a necessidade de novos patterns.

Há uma discussão sobre isso em: http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures

Padrões são uma tendência natural, não só em programação, mas em qualquer atividade humana.

Mesmo que a linguagem seja extensível, você vai ter um conjunto de extensões, que você terá adotado em cada programa. Nesse caso, são os padrões. A linguagem só te dará a vantagem de ser menos verborrágico na hora de repeti-los.

Mais um tópico que li de cabo-a-rabo. Por isso, vou tentar responder pelas três páginas.

Eu tive aula de compiladores no meu terceiro ano de faculdade. Gostei da matéria porque tive um ótimo professor e porque este me fez, pela primeira vez, escrever um programa que ultrapassasse as 5000 linhas. A necessidade de se manter um sistema complexo foi um grande aprendizado. Pra vocês terem uma idéia, pasmem, eu escrevi todo o código Java no Notepad, sem compilar! Óbvio, me dei mal, o javac gerou mais de mil erros.

Ainda assim, mesmo estudando compiladores, nunca soube (na época) o que era closure, ainda sofri efeitos da lavagem cerebral do “Java Anywhere” e, olhando pra tras, me formei ainda sendo um profissional bem imaturo em relação ao que era hoje.

Porque as universidades não formam bons profissionais? Não acho que a resposta seja tão simples quanto: “faltou matéria de Compiladores”. Me formei numa universidade pública que, dizem, está entre as melhores do país. Anda assim, precisei de uns três anos de estudo por conta própria pra me considerar um profissional ótimo. (E não acho que numa particular seria diferente.)

Acredito que as universidades não formam bons profissionais por não se criar uma cultura de qualidade na escrita de código. Durante os anos de estudo, nunca fomos apresentados ao Subversion, não sabíamos o que era testes automatizados, tivemos pouco acesso ao Unix, não trabalhávamos em equipe, e aprendíamos e fazíamos software simulando um waterfall. Ou seja, tudo ao contrário do que se espera de um bom profissional. E no mundo das consultorias, este aluno simplesmente repetirá as péssimas práticas adquiridas na universidade. Óbvio, em algum momento, o rapaz (ou a moça) se dará conta de que suas ações são prejudiciais, porém, fica-se numa “sinuca de bico”, porque apesar dele saber o que é ruim, não tem a mínima idéia do que é bom.

Qualquer profissional precisa saber como as coisas funcionam por trás. Simplesmente porque elas são necessárias quando acontece algum problema inesperado e fora do comum. Eu, sinceramente, estou cansado de ver programador “travar” quando, por exemplo, o Hibernate traz um resultado diferente do planejado, e ele fica simplemente alterando os métodos de Critéria até dar certo (o que não ocorre, óbvio). Conhecimento aprofundado de SQL é fundamental, mesmo que você não faça uso.

Considero o Thiago, apesar de barraqueiro, bastante esperto. Defender Lisp em terra de Javeiro não é pra qualquer um. Acredito que a cultura da monolinguagem ou da monoplataforma é fruto de criações vindas de grandes empresas, como é o Java e como é o Windows. Pras “vendors”, não interessa um programador que, de repente, mude de linguagem “porque é mais adequado”, aquilo que a empresa vende deve ser apropriado pra tudo e pra sempre, senão é um cliente a menos.

O único jeito de sair dessa mordaça é abraçar o Open Source, onde a cultura do “gold hammer” não é tão forte assim.

SE Patterns são um produto de linguagens de programação deficientes, qual linguagem é eficiente?
:wink:

Só para citar as respostas de Ralph Johnsonn e Erich Gamma, sobre a inexistência de patterns em linguagens funcionais:

Larry: GoF came out relatively early in the ascent of OOP as the mainstream paradigm and, for better or worse, “patterns” seem to be associated with OO approaches. You even hear functional and dynamic advocates boasting that their languages “don’t need” patterns. How do you respond to that?

Ralph: Some of those languages don’t need some of the patterns in Design Patterns because their languages provide alternative ways of solving the problems. Our patterns are for languages between C++ and Smalltalk, which includes just about everything called “object-oriented,” but they certainly are not for every programming language. I don’t think anybody actually says that programmers in other languages don’t need patterns; they just have a different set of patterns.

Erich: Design patterns eventually emerge for any language. Design déjà-vu is language neutral. While these experiences are not always captured as patterns, they do exist. The design principles for Erlang come to mind.

Fonte: http://www.informit.com/articles/article.aspx?p=1404056&ns=16259

[quote=peczenyj]SE Patterns são um produto de linguagens de programação deficientes, qual linguagem é eficiente?
:wink:
[/quote]

Me parece que ficou claro que ele diz ser lisp.

Essa descrição de patterns não tem fim porque existem vários tipos de pattern. Alguns realmente são indicados para resolver problemas que existem em algumas linguagens. Outros são de design e não tem nada a ver com a linguagem.

Sou fã de linguagens funcionais e a arquitetura delas é reconhecida por quem desenvolve compiladores como um design superior pelos motivos já citados. O grande problema que vejo nelas é que para algumas situações elas não são tão eficientes.

Agora, particularmente, não gosto da sintaxe do lisp cheia de parênteses desnecessários, prefiro Haskell e Clean. Mas é questão de gosto.

Voltando ao assunto do tópico.

Não acho que seja possível formar alunos que saiam bons programadores, de uma faculdade. Para ser um bom programador, você precisa de experiência. Vai sair bom programador da faculdade, quem programa desde cedo.

É claro, as faculdades poderiam formar programadores melhores. Também concordo que deveriam reforçar boas práticas de programação, como exigir dos alunos que dividam seus códigos em métodos pequenos (no mínimo), ou que dêem nomes claros para as variáveis.

Mas um problema que existe nos softwares feitos para faculdade, é o conceito de que eles tem que rodar “até o momento da apresentação”. Ninguém se preocupa em manter aquele código posteriormente.

Como organizar uma faculdade, de modo a fazer com que um aluno se preocupe com um mesmo software durente toda a extensão do curso? Ou para que ele se veja forçado a reescrever o software, pq não foi capaz de adpta-lo? Acho que transmitir essa preocupação, que existe no meio profissional, no ambiente acadêmico, seria um enorme desafio.

[quote=marcosalex]Sou fã de linguagens funcionais e a arquitetura delas é reconhecida por quem desenvolve compiladores como um design superior pelos motivos já citados. O grande problema que vejo nelas é que para algumas situações elas não são tão eficientes.

Agora, particularmente, não gosto da sintaxe do lisp cheia de parênteses desnecessários, prefiro Haskell e Clean. Mas é questão de gosto.[/quote]

É uma pena porque a propriedade que o Thiago se refere como sendo responsável pela eliminação dos patterns não tem nada a ver com o fato de lisp ser funcional, mas com o fato de lisp ser lisp. Portanto se vc não conhece lisp porque não gostou de parênteses ou sei lá porque não pode entender como isso acontece.

Só se existisse no programa do curso o desenvolvimento de um sistema, que ia sendo aprimorado com o conteudo de cada matéria, sendo utilizado como trabalhos da mesma, e que deveria ser apresentado no final do curso. no ultimo semestre existiria uma matéria só para a finalização desses sistema, com orientaçõea ao aluno para aparar as arestas.

Não é muito dificil imaginar um esquema assim, só é dificil colocar isso na cabeça dos academicos, que não conhecem a realidade do mundo.

[quote=ViniGodoy]Só para citar as respostas de Ralph Johnsonn e Erich Gamma, sobre a inexistência de patterns em linguagens funcionais:

Larry: GoF came out relatively early in the ascent of OOP as the mainstream paradigm and, for better or worse, “patterns” seem to be associated with OO approaches. You even hear functional and dynamic advocates boasting that their languages “don’t need” patterns. How do you respond to that?

Ralph: Some of those languages don’t need some of the patterns in Design Patterns because their languages provide alternative ways of solving the problems. Our patterns are for languages between C++ and Smalltalk, which includes just about everything called “object-oriented,” but they certainly are not for every programming language. I don’t think anybody actually says that programmers in other languages don’t need patterns; they just have a different set of patterns.

Erich: Design patterns eventually emerge for any language. Design déjà-vu is language neutral. While these experiences are not always captured as patterns, they do exist. The design principles for Erlang come to mind.

Fonte: http://www.informit.com/articles/article.aspx?p=1404056&ns=16259[/quote]

Linguagens funcionais resolvem problemas de uma forma diferente que linguagens imperativas tornando muitos padrões encontrado no livro obsoletos. Mas acho que o Thiago estava se referindo a uma capacidade de Lisp e não necessariamente de linguagens funcionais.

Eu particularmente acho que o papel da faculdade não é cuspir programadores mega experientes no mercado. Aliás, esse não é o papel de nenhuma faculdade de qualquer área.

Mas um problema sério que vejo é professor querendo ensinar Java como se estivesse ensinando C…

“Crie um programa Agenda para guardar contatos”…

Aí o cara cria uma classe só, enfia tudo nessa classe… o programa funciona e o cara recebe 10…
Concordo que o objetivo nesses casos é apenas ensinar a sintaxe do Java, mas concordo ainda mais com o que meu pai me disse uma vez quando perguntei se ele queria aprender a mexer no Excel… “burro velho não aprende a comer milho!”…

Oi,

Sou formada em Automação Industrial (UFSC Floripa) e Ciências da Computação (Unisul - SC).
Existe uma matéria no curso de Ciências da Computação chamada Linguagens Formais e Autômatos no qual mostra o conteúdo de compiladores.

Opinião: Acho fundamental o estudo de compiladores para quem quer se tornar um programador.

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.

Acorda!!! Com 17 anos não sabemos quem é “o Presidente da Republica” muito menos saberemos o que deveremos fazer no Vestibular.

Tchauzin!

Concordo que programadores tem que saber o funcionamento de compiladores. E vou alem: cada programador deve criar sua própria linguagem pra provar que conhece ainda na faculdade, de preferencia usando open source. Nem que pra isso leve 10 anos.

Deixa esse negocio de criar empresas que valem milhões para os práticos, aqueles bobos.

De forma alguma. Um padrão, como a própria definição da palavra diz, significa uma modelo com determinadas propriedades para ser aplicado em diversos lugares. Se a linguagem permite abstrair tudo então jamais essas propriedades existirão para poderem ser chamadas de “padrão” para começo de conversa.

[quote=ViniGodoy]Acho que essa uma das maiores bobagens que já foram pronunciadas na história da informática. Definitivamente, argumento de alguém que queria vender uma linguagem, e o que mais me impressiona, ver gente da área técnica repetindo a ladainha.

O que vai acontecer é que uma determinada linguagem poderá realmente tornar desnecessário certos patterns, ou simplificar seu uso, mas em pouco tempo, ter a necessidade de novos patterns.[/quote]

Acho que você deveria estudar linguagens de programação antes de falar bobagens. Sim, em linguagens derivadas de Algol as limitações sempre existirão porque elas usam uma gramática fixa e você está limitado àquelas features que o criador da linguagem pensou serem úteis. Se algo novo surge ou se você simplesmente deseja fazer algo um pouco diferente está lascado.

O maior problema é que nem tudo funciona como deveria, e sempre há a necessidade de workarounds para diversas limitações. Logo surgem os “padrões de código”. Eles nada mais são do que workarounds para limitações das linguagens.

Por exemplo, DAO é um workaround nojento para criar uma camada de acesso ao banco de dados. Isso deveria fazer parte da própria linguagem. Como você não pode mudar a linguagem de programação precisa se preocupar com DAOs ou então usar alguma API de mapeamento tosco, que mais complica do que ajuda.

Em algumas linguagens como C# eles decidiram adicionar essas features de uma forma mais generalizada, assim como o LINQ, mas mesmo assim não oferece a flexibilidade necessária.

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 estou falando que as linguagens não podem ser mais flexíveis. Mas mesmo uma linguagem ultra-flexível, irá ter padrões. Podem não ser os mesmos, e nem ser chamados assim, mas serão padrões da mesma forma.

A única forma não ter padrões seria se ela te desse uma, e somente uma, maneira de fazer as coisas. Mas das duas uma. Seria uma linguagem péssima, super engessada, e que só faz uma única coisa. Ou seria uma linguagem utópica.

A partir do momento que você tem duas formas de fazer a mesma coisa, uma delas terá vantagens sobre a outra e, portanto, haverá um padrão a ser seguido para o problema em que cada forma é mais vantajoso.

Essa frase vem da tentativa de quem vende uma tecnologia de repudiar outras.

Não estou falando que as linguagens não podem ser mais flexíveis. Mas mesmo uma linguagem ultra-flexível, irá ter padrões. Podem não ser os mesmos, e nem ser chamados assim, mas serão padrões da mesma forma.

A única forma não ter padrões seria se ela te desse uma, e somente uma, maneira de fazer as coisas. Mas das duas uma. Seria uma linguagem péssima, super engessada, e que só faz uma única coisa. Ou seria uma linguagem utópica.

A partir do momento que você tem duas formas de fazer a mesma coisa, uma delas terá vantagens sobre a outra e, portanto, haverá um padrão a ser seguido para o problema em que cada forma é mais vantajoso.[/quote]

De onde você tirou isso? Não importa se você tem uma ou mil formas de se fazer algo. Padrões de código surgem da incapacidade de abstraí-los afim de gerar alguma seqüência de instruções.

DAOs são um exemplo perfeito. Não há a possibilidade de se automatizar o acesso ao banco de dados para os seus objetos através da linguagem, e por isso usasse esse padrão.

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.