Faculdades e compiladores

113 respostas
T

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.

113 Respostas

M

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.

Na faculdade onde me formei tive essa matéria. Meu professor era um cara altamente qualificado, mas a matéria em sim é bem difícil e não me agregou muita coisa.

D

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.


Bem Thiago, depende do curso que você faz. Em Ciência da Computação normalmente existe uma disciplina de compiladores. Uma teória e uma de laboratório. Entretando, em Sistemas de Informação isso normalmente não acontece, pois como um compilador funciona, teoricamente, não é problema de um analista de sistemas.
Outra coisa, não se iluda que você vai aprender como um closure funciona. Uma disciplina de compiladores vai tratar de aspectos mais formais e ser um pouco mais alto nível. No laboratório vc faz algo que funciona e que gera código, mas não vai aprender como funciona tudo.

Eu sinceramente não concordo quando vc diz que entender como funciona uma closure é melhor que saber o que é uma closure (ou qualquer outra funcionalidade da linguagem). Um desenvolvedor não tem que se preocupar necessariamente como as coisas funcionam dentro da plataforma que usa. Tem que se preocupar que funcionam e pronto e como usar. É claro, se vc precisa de algo com um comportamento muito diferente, vc vai precisar ir mais a fundo, mas de modo geral isso é perda de tempo.

[]´s

M

Essa talvez seja a principal diferença da Ciência da Computação para o Sistema de Informação.

Ciência estuda a teoria e “como as coisas funcionam”.
Sistemas estuda como se usa.

Me corrijam se estiver errado.

M

A diferença teoricamente é por aí mesmo.

Mas lembre que os nomes de cursos não necessariamente são condizentes com o conteúdo que eles ensinam, já que não tem uma regulamentação clara do que cada curso deveria ensinar.

F

Eu fiz ciencia da computação e tive a matéria de compiladores. Muito interessante diga-se de passagem.

M

++

No caso da minha faculdade a matéria não foi muito a fundo, mas mais por falta de interesse da grande maioria dos alunos (e de conhecimento também) do que por outra coisa. Mas é um dos assuntos que eu mais gosto, tanto que acabei comprando dois livros referentes ao assunto depois do término da cadeira.

No mais, concordo com o David Buzatto.

R

Eu acho que não.

T

Se as pessoas soubessem como algo funciona não existiriam discussões de qual linguagem é a melhor por exemplo, pois elas entenderiam o que uma feature acarreta e saberiam que existem n outras linguagens que implementam aquela feature.

D

OK Thiago. Se eu falar A vc vai falar B mesmo. Imagine um carro. Se ele tem ar condicionado, vc precisa saber com ele funciona? Vc precisa saber que tem o ar e como usá-lo. Enfim, não vou discutir.
Espero que esse tópico não vire um flamewar (como alguns outros dos seus tópicos).

[]´s

T

Desenvolvedores não são motoristas e precisam saber como as coisas funcionam. Uma linguagem de programação é muito mais importante do que um simples acessório, afinal de contas não é necessário ar-condicionado para um carro funcionar.

Interessante é que alguns fazem piada dos desenvolvedores de VB, como se eles só arrastassem e soltassem botões, mas e vocês? Vocês realmente sabem algo além dos javadocs? Não seria isso uma forma de VBizar o desenvolvimento de software?

Quem não conhece compiladores não é melhor do que um desenvolvedor VB.

L

davidbuzatto:
OK Thiago. Se eu falar A vc vai falar B mesmo. Imagine um carro. Se ele tem ar condicionado, vc precisa saber com ele funciona? Vc precisa saber que tem o ar e como usá-lo. Enfim, não vou discutir.
Espero que esse tópico não vire um flamewar (como alguns outros dos seus tópicos).

[]´s

Tb não quero criar um flamewar, mas não gosto de exemplos deste tipo q vc deu!

Ser programador nada tem a ver com ter carros ou qlq coisa do tipo!

É por achar que basta um conhecimento superficial das coisas que cada dia mais nossa profissão entra em descrédito e querem pagar cada vez menos.

É claro que não precisa chegar ao extremo de escovar bits e conhecer Assembly por exemplo, mas quanto mais profundo for o conhecimento de um programador melhor, e teoria de compiladores é o mínimo que um bom programador precisa saber.

Do jeito que a coisa tá indo daqui a pouco vão falar: “Programador não precisa conhecer Estrutura de Dados não”, se é que já não falaram.

Olhem os livros que o pcalcado lê por exemplo e veja se são livros de quem se contenta em saber apenas usar alguma coisa: http://www.flickr.com/photos/pcalcado/[telefone removido]

M

São dois mercados distintos, e os dois precisam de gente. Se alguem quiser alguma coisa simples, ou pouco mais que um CRUD não é necessário que o cara conheça Estrutura de Dados e é saudável que tenha ferramentas like VB, Delphi ou até Access pra esse público. São pessoas que podem cobrar até 200 reais pra fazer um ‘sisteminha’, isso não afeta o mercado de desenvolvedores.

Defender que até pra coisas simples seja necessário um profissional capacitado é o que faz os desenvolvedores Java terem essa fama de querer fazer tudo na mão e não gostar de nada prático.

O outro mercado é o de aplicações Enterprise, que a pessoa precisa ter realmente conhecimento técnico e área em que a grande maioria daqui trabalha, por isso nem precisa explicar.

R

Lembrem-se que programar não se resume a compilação.

Se seguirmos essa teoria, toda vez que quiséssemos persistir nossos dados em uma base de dados, deveríamos ter que estudar mais a fundo o SGBD, como ele se encarrega de arrumar seus índices, seu dicionário de dados, qual a forma mais eficiente de se criar uma procedure e uma trigger…

Lembrando também que há a fase de modelagem. Portanto, deveríamos estudar a fundo o desenvolvimento da UML, bem como os Diagrama de Sequencia, Diagrama de Classe, Diagrama de Casos de Uso, Diagrama de Estado, Diagrama de Comunicação etc…

Além disso, devemos testar nosso software. Portanto, devemos estudar a fundo como criar criar massas de testes automatizadas com eficiência.

Ah, e se quiséssemos que nossa aplicação acessasse a rede, deveríamos estudar a fundo os procolos utilizados, bem como a topologia da rede.
Sem falar que a comunicação entre computadores se baseia em conceitos matemáticos como a lei da refração (fibras óticas) e Serie de Fourrier.

Com isso, a faculdade de informática não só demoraria mais tempo, como criaria um profissional utópico, que saberia tudo de tudo e não direcionado a uma área específica da informática, como o mercado exige.

L

renamed:
Lembrem-se que programar não se resume a compilação.

Se seguirmos essa teoria, toda vez que quiséssemos persistir nossos dados em uma base de dados, deveríamos ter que estudar mais a fundo o SGBD, como ele se encarrega de arrumar seus índices, seu dicionário de dados, qual a forma mais eficiente de se criar uma procedure e uma trigger…

Lembrando também que há a fase de modelagem. Portanto, deveríamos estudar a fundo o desenvolvimento da UML, bem como os Diagrama de Sequencia, Diagrama de Classe, Diagrama de Casos de Uso, Diagrama de Estado, Diagrama de Comunicação etc…

Além disso, devemos testar nosso software. Portanto, devemos estudar a fundo como criar criar massas de testes automatizadas com eficiência.

Ah, e se quiséssemos que nossa aplicação acessasse a rede, deveríamos estudar a fundo os procolos utilizados, bem como a topologia da rede.
Sem falar que a comunicação entre computadores se baseia em conceitos matemáticos como a lei da refração (fibras óticas) e Serie de Fourrier.

Com isso, a faculdade de informática não só demoraria mais tempo, como criaria um profissional utópico, que saberia tudo de tudo e não direcionado a uma área específica da informática, como o mercado exige.

Ok cara, não vale a pena discutir uma coisa dessas. Cada profissional sabe o que é melhor para si próprio e estuda o que achar que tem que estudar.

Abraços.

F

Na boa, para aplicações normais tambem acho desnecessario, nós temos que saber usar e da melhor maneira, e pra isso não necessita saber sobre compiladores, talvez pra games, app’s realtime, ou que necessitem de muita performance, como pesquisa cientifica, calculos de iterações entre moleculas e afins.

Agora dizer que estudar compiladores vai mudar a vida de quem faz CRUD’s e regras de negocios, é um pouco exagerado.

D

Quem falou que eu estou comparando carros com programação realmente não entendeu a analogia.
Pena…

C

sou formado em ciencia da computação e tive praticamente 2 anos dessa materia…começa com 1 ano de teoria da computação (pior materia que existe) onde se aprende analisar complexdade de algoritmos, fazer analise lexica, grafos, etc…depois tive mais 1 ano de compiladores e interpretadores…

sou da opinião que para ser programador no Brasil não precisa disso em nada, eu não uso nada nada disso no trampo. Foi uma grande dor de cabeça e perda de tempo estudar tanto tempo isso.

M

Nossa, poderia citar aqui várias matérias (e temas) que estavam entre as minhas favoritas: Linguagens Formais e Autômatos, Teoria de Grafos, Arquitetura de Computadores, Compiladores, Sistemas Operacionais… entre outras que agora não lembro, mas que seguem o mesmo estilo. Até hoje me arrependo de não ter ido mais a fundo nessas matérias.

Claro que cada um tem uma opinião e respeito a sua, mas particularmente fico um pouco triste quando vejo alguém pensando dessa forma. Acho que no seu caso teria sido mais recomendado ter feito uma outra faculdade mais “alto nível” do que Ciência da Computação, como Sistemas de Informação (ou Tecnologia da Informação, como era na minha faculdade).

Em tempo #1: realmente não uso no meu trabalho praticamente nenhum desses conhecimentos adquiridos na faculdade, mas de forma alguma encaro isso como tendo sido uma perda de tempo. Pelo contrário, é o tipo de assunto que eu gosto e acho que abre meu leque de conhecimentos.

Em tempo #2: a grande maioria dos meus colegas de faculdade também tinham essa opinião de que essas matérias eram pura perda de tempo. Por acaso (ou não) praticamente todos eles são mais daquele perfil de não se importarem em evoluir, de assumir a evolução técnica e a busca pelo conhecimento de coisas novas como um desafio, se contentam em arrumar um emprego onde possam ficar anos e anos na mesma função, ganhando um salário não mais do que mediano (ou seja, estagnação) e por acaso também (ou não) a maioria ainda está nesse esquema e vivem chorando miséria.

Enfim, é uma questão pessoal isso. Cada um com seu cada um.

L

davidbuzatto:
Quem falou que eu estou comparando carros com programação realmente não entendeu a analogia.
Pena…

É verdade. O que mostra que você não foi muito preciso no que escreveu…
Pena…

V

Aqui em Curitiba, praticamente todos os cursos de informática superiores tem a disciplina de compiladores.

M

davidbuzatto:
Quem falou que eu estou comparando carros com programação realmente não entendeu a analogia.
Pena…

Pegando um gancho, não é bem assim. Eu não preciso saber como o ar condicionado funciona, mas deveria saber que se uso o ar, o carro consome mais combustivel e em alguns casos perde potencia. Isso eu deveria saber, e os programadores tem que saber isso tbm. É por essas e outras que vejo código tosco, mal escrito por ai. Não preciso saber como foi implementado o HashSet ou o ArrayList do Java, mas tenho que saber como funcionam para poder escolher qual o melhor para resolver meu problema.

M

a sim, e pra não desviar o curso (mais ainda), eu fiz sistemas e tive teoria da computação. Boa matéria, achop que acrescenta muito mais conteudo que compiladores (que não tive, logo não posso falar nada além do que pesquisei a respeito)

M

mario.fts:
davidbuzatto:
Quem falou que eu estou comparando carros com programação realmente não entendeu a analogia.
Pena…

Pegando um gancho, não é bem assim. Eu não preciso saber como o ar condicionado funciona, mas deveria saber que se uso o ar, o carro consome mais combustivel e em alguns casos perde potencia. Isso eu deveria saber, e os programadores tem que saber isso tbm. É por essas e outras que vejo código tosco, mal escrito por ai. Não preciso saber como foi implementado o HashSet ou o ArrayList do Java, mas tenho que saber como funcionam para poder escolher qual o melhor para resolver meu problema.

concordo em genero numero e grau… e o exemplo (aproveitando o do davidbuzatto) foi bem feito sim… claro que programar não é como dirigir (obvio aliais, isso foi uma metafora), mais em ambos os casos não é necessário conhecer como a ferramenta é produzida, mais é altamente indicado possuir o conhecimento de como utiliza-lo da melhor forma.

A questão não é ter-se a disciplina de compiladores, ela é mais uma disciplina complicada, nada mais do que isso, não é isso que vai agregar o suficiente pro cara ser um bom programador, mais tempo dedicado a disciplinas de lógicas seria mais util por exemplo que mais compiladores, ou mais IA (se a intenção é criar programadores que fazem menos código ruim), uma disciplina referente a “boas praticas” abordando design patterns, anti-patterns e até identação do código seria mais util…

A disciplina de compiladores não acho que seja tão essencial assim (2 anos de compiladores por exemplo é muita coisa), mas que é necessário conhecer um pouco sobre a ferramenta, isso sim é importante… concordo que a matéria deve existir (eu tive essa materia mesmo o curso que fiz tendo sido sistemas de informação).

ps, sou contra esses excessos referentes a compiladores, de considerar que a materia vai fazer alguém programar melhor a tal ponto, ou se te-la tanto assim como o cs.santos disse, mas isso não é devido a não gostar do assunto, meu proprio TCC foi referente a isso, mas sim por considerar estas coisas como exageros…

C

não não…eu estava no lugar certo mesmo…não me adaptaria em sistemas de informação…acho meio que tediosa as coisas que se estudam la…eu gostei do curso…é que teoria da computação realmente eu detesto cara, é uma das unicas que eu não curti nda nda…e em conjunto com compiladores, sou tb da opinião que deve-se ter uma noção, mas apenas por conhecimento msm, pois será muito raro de aplicar no mercado de trabalho.

vou assumir que isso não foi uma intenção de “flame” sobre a minha opinião, porem eu realmente acho q foi extrema perda de tempo assisitir akelas aulas, e nem por isso eu não penso em evoluir e buscar conhecimento.

M

Não, não foi flame. Só que infelizmente vc há de concordar que a maioria das pessoas com esse pensamento têm esse perfil. Pelo menos é o que eu vejo, ainda mais pq eu trabalhei em inúmeros ambientes altamente burocráticos. Enfim… se pareceu que foi uma afronta a você, me desculpe.

C

Não, não foi flame. Só que infelizmente vc há de concordar que a maioria das pessoas com esse pensamento têm esse perfil. Pelo menos é o que eu vejo, ainda mais pq eu trabalhei em inúmeros ambientes altamente burocráticos. Enfim… se pareceu que foi uma afronta a você, me desculpe.

sem problemas…é que pareceu com certo duplo sentido…mas entendi seu ponto de vista. Realmente acontece isso sim que vc flw, na minha sala tinham muitos, mas esses ai não se interessam por materia nenhuma…rsrsrsrs

abraços

V

Eu sinto falta nos cursos é de mais aulas de fundamentos básicos. Seja de hardware ou de software mesmo.

Dá para notar, aqui no GUJ, que “converter coisas para bytes” é um processo místico para muitas pessoas. Aliás, o mundo dos “bytes” parece ser de algo desconhecido, mítico, que existe na entranha dos sistemas.

Poucos sabem o que é encoding, ou mesmo quais os mais comumente usados. A maioria não tem noção de como uma data é representada na maior parte das linguagens, e não sabe fazer calculos simples de conversão de tempo.

É difícil abordar assuntos como elegância de código e padrões de projetos em faculdade. Os alunos tem muitas dúvidas, em coisas mais fundamentais. Geralmente, buscamos elegância só depois de sanar essas dúvidas, até porque, para compreender a beleza de um código elegante, é necessário entender as suas implicações e, muitas vezes, ter degladiado um pouco para alterar um código amarrado.

Outra coisa, é que eu acho que as faculdades deveriam ser bastante rigorosas nas disciplinas de programação. E não deveriam passar alunos com dúvidas, principalmente as fundamentais.

M

Nossa, nem me fala nisso. Na minha faculdade era o contrário. A maioria dos alunos queriam professores frouxos que dessem trabalhinhos bunda pra poder pegar o 10 e ir pra casa felizes. Achava isso péssimo.

Aí quando a gente finalmente teve Java, entrou um professor que obrigou todo mundo a pensar. Eu adorava. Na primeira prova todo mundo ficou aterrorizado, porque não era a baba que queriam. Muita gente acabou se dando mal, e até tentaram argumentar com o coordenador de CC pra tirar o professor, mas não teve jeito.

T

marcosalex:
São dois mercados distintos, e os dois precisam de gente. Se alguem quiser alguma coisa simples, ou pouco mais que um CRUD não é necessário que o cara conheça Estrutura de Dados e é saudável que tenha ferramentas like VB, Delphi ou até Access pra esse público.

Todo desenvolvedor precisa saber o que é uma lista ligada ou hashtable. Que história é essa?

T

Patterns são um produto de linguagens de programação deficientes. Conhecimentos de compiladores ajudaria sim a alguém a entender que a linguagem que está usando não é suficientemente boa e por isso precisa dessas muletas chamadas “patterns”.

Alguém que não conhece desenvolvimento de linguagens e compiladores acha normal a existência de patterns.

R

Patterns são um produto de linguagens de programação deficientes. Conhecimentos de compiladores ajudaria sim a alguém a entender que a linguagem que está usando não é suficientemente boa e por isso precisa dessas muletas chamadas “patterns”.

Alguém que não conhece desenvolvimento de linguagens e compiladores acha normal a existência de patterns.

Por favor, poderia explicar em que vc se baseia para dizer isso?

T

renamed:
Thiagosc:
Patterns são um produto de linguagens de programação deficientes. Conhecimentos de compiladores ajudaria sim a alguém a entender que a linguagem que está usando não é suficientemente boa e por isso precisa dessas muletas chamadas “patterns”.

Alguém que não conhece desenvolvimento de linguagens e compiladores acha normal a existência de patterns.

Por favor, poderia explicar em que vc se baseia para dizer isso?

Porque em qualquer linguagem de programação adequada haveria a possibilidade de abstrair qualquer tipo de repetição de modo que não há a necessidade de se recorrer a “padrões de projeto”.

Se não é possível abstrair repetições, e logo é necessário estabelecer “padrões” comuns que nada mais são do que convenções adotadas por desenvolvedores, então é sinal de que a linguagem em questão não fornece as ferramentas necessárias.

M

Thiagosc:
renamed:
Thiagosc:
Patterns são um produto de linguagens de programação deficientes. Conhecimentos de compiladores ajudaria sim a alguém a entender que a linguagem que está usando não é suficientemente boa e por isso precisa dessas muletas chamadas “patterns”.

Alguém que não conhece desenvolvimento de linguagens e compiladores acha normal a existência de patterns.

Por favor, poderia explicar em que vc se baseia para dizer isso?

Porque em qualquer linguagem de programação adequada haveria a possibilidade de abstrair qualquer tipo de repetição de modo que não há a necessidade de se recorrer a “padrões de projeto”.

Se não é possível abstrair repetições, e logo é necessário estabelecer “padrões” comuns que nada mais são do que convenções adotadas por desenvolvedores, então é sinal de que a linguagem em questão não fornece as ferramentas necessárias.

poderia citar um exemplo de linguagem? não conheço nenhum caso onde não exista nenhuma necessidade de patterns, seja eles quais forem.

T

mario.fts:

poderia citar um exemplo de linguagem? não conheço nenhum caso onde não exista nenhuma necessidade de patterns, seja eles quais forem.

Lisp é um exemplo onde todas as repetições podem ser abstraídas. Desde a criação de getters e setters até a criação de seqüências de instruções.

A vantagem é que por exemplo o desenvolvedor não precisa se preocupar em saber que quando fizer X precisa também gerar métodos Y e Z com a seguinte nomenclatura. Mas tudo é feito automaticamente e sem emporcalhar o código assim como é em Java, onde o Eclipse gera código para você mas fica tudo lá no arquivo, ocupando espaço e atrapalhando a leitura.

M

Thiagosc:
mario.fts:

poderia citar um exemplo de linguagem? não conheço nenhum caso onde não exista nenhuma necessidade de patterns, seja eles quais forem.

Lisp é um exemplo onde todas as repetições podem ser abstraídas. Desde a criação de getters e setters até a criação de seqüências de instruções.

A vantagem é que por exemplo o desenvolvedor não precisa se preocupar em saber que quando fizer X precisa também gerar métodos Y e Z com a seguinte nomenclatura. Mas tudo é feito automaticamente e sem emporcalhar o código assim como é em Java, onde o Eclipse gera código para você mas fica tudo lá no arquivo, ocupando espaço e atrapalhando a leitura.

Me corrije se eu entendi errado sua colocação: nesse caso você não poderia simplesmente colocar o método public? Se é só pra ler e gravar a propriedade e você não quer gerar código, qual a diferença?

Sobre Teoria da Computação: talvez você não tenha tido um bom professor. Eu adorei a matéria, assim como Compiladores e fiz meu mestrado nessa área. Teoria da Computação você entende porque tem problemas que nunca poderão ser resolvidos por um programa e aprende a analisar a complexidade de algoritmos. Facilita entender por exemplo, porque em algumas situações um algoritmo exponencial tem mais performance que um logaritmico e outros problemas que parecem simples, mas se você fizer muitas iterações ele vai ‘lá em baixo’ a performance, da mesma forma que é possível entender porque tem compiladores mais rápidos e porque RISC consegue otimizar a performance sem se preocupar com novo processador.

M

Thiagosc:

Lisp é um exemplo onde todas as repetições podem ser abstraídas. Desde a criação de getters e setters até a criação de seqüências de instruções.

não, eu estava me referindo a patters de design, como strategy, chain of responsability, factory, dao, activerecord e etc. getters e setters eu nem considero um padrão. se for assim, ruby tbm gera eles automaticamente, não precisaria partir pra lisp

T

marcosalex:
Me corrije se eu entendi errado sua colocação: nesse caso você não poderia simplesmente colocar o método public? Se é só pra ler e gravar a propriedade e você não quer gerar código, qual a diferença?

Sobre Teoria da Computação: talvez você não tenha tido um bom professor. Eu adorei a matéria, assim como Compiladores e fiz meu mestrado nessa área. Teoria da Computação você entende porque tem problemas que nunca poderão ser resolvidos por um programa e aprende a analisar a complexidade de algoritmos. Facilita entender por exemplo, porque em algumas situações um algoritmo exponencial tem mais performance que um logaritmico e outros problemas que parecem simples, mas se você fizer muitas iterações ele vai ‘lá em baixo’ a performance, da mesma forma que é possível entender porque tem compiladores mais rápidos e porque RISC consegue otimizar a performance sem se preocupar com novo processador.

Não sei o que Teoria da Computação tem a ver com o meu comentário. Explique, o que isso tem a ver?

E, corrigindo-o, esse foi apenas um exemplo. Pode-se criar qualquer coisa, desde implementação de métodos de forma diferente ou até classes dessa forma automática, o que é impossível em Java (e também é em C++ ou C# ou Ruby, etc).

T

mario.fts:
Thiagosc:

Lisp é um exemplo onde todas as repetições podem ser abstraídas. Desde a criação de getters e setters até a criação de seqüências de instruções.

não, eu estava me referindo a patters de design, como strategy, chain of responsability, factory, dao, activerecord e etc. getters e setters eu nem considero um padrão. se for assim, ruby tbm gera eles automaticamente, não precisaria partir pra lisp

Sim, todo e qualquer pattern, como strategy, factory, dao, etc, podem ser gerados automaticamente. É possível criar definições de classes, implementar métodos ou funções, etc, em tempo de compilação. Qualquer pattern pode ser abstraído em Lisp, o que não é possível em linguagens inferiores.

O problema é que quando nesse tipo de liberdade o termo “patterns” perde o sentido. “Patterns” só existem porque as linguagens que usamos são deficientes. Um modo interessante de se programar que é usado em Lisp é o desenvolvimento de forma iterativa, onde a aplicação é desenvolvida gradualmente após várias iterações onde adiciona-se funcionalidade e refatora-se o código. Nesse caso as repetições seriam removidas antes mesmo que viessem a configurar um “padrão de projeto”. É outro mundo.

D

Thiagosc e sua diarréia mental.
Fico impressionado como uma coisinha de nada vira um rebuliço desses.
Então patterns existem pq as linguagens são deficientes… Aff…

Ok, parei, não falo mais nada.

M

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…

V

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.

L

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.

P

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

V

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

M

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

Me parece que ficou claro que ele diz ser lisp.

M

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.

V

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.

M

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.

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

M

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.

M

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

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.

R

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!”…

L

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!

M

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.

T

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.

T

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.

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.

T

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?

V

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.

T

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.

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.

V

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.

M

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.


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.

T

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.

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

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.

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.

M

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?

V

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.

V

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.

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.

B

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.

T

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

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.

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

T

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.

V

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

V

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?

T

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.

V

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

V

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

T

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.

V

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

T

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

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

M

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.

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

L

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.

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…

M

luistiagos:
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.

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…

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

J

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:

J

Caramba, voltei das férias e o papo de c++ e lisp ainda está em alta!

Respondendo ao tópico. Essas matérias são de profunda importância para engenheiros e cientistas da computação, ou seja, para quem desenvolve e cria tecnologia.

Analistas de sistemas não precisam delas, realmente.

V

mochuara:
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.

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

Não, está sendo dito que os patterns são completamente eliminados pela linguagem, e não existirão mais patterns, em momento algum.

Patterns simplificados não são patterns eliminados. O Norvig ainda ressalta mudanças ocorrem em apenas 16 dos patterns. E também fala de patterns que são exclusivos de linguagens funcionais.

Ou seja, o que estou repetindo sem parar é que patterns sempre vão existir. Talvez não os patterns do GoF, pq muitos deles são para linguagens OO, mas outros patterns. Por que problemas comuns sempre existem e, uma vez que temos escolhas, uma delas será geralmente mais adequada e, portanto, constituirá um padrão adota-la.

Ou seja, bastava você ler o que você não negritou.

M

Os patterns são eliminados completamente em linguagens como Lisp. O programador identifica aquilo que precisa e implementa na própria linguagem. Não ha necessidade da linguagem implementar todos os patterns existentes e que virão a existir no futuro. Lisp é uma linguagem de programação programável. É um idéia bem diferente de Java e c++. e A hora que vc for além de powerpoints para estular lisp de verdade ira entender.

R

E o que isso tem haver com o tema do tópico: Faculdades e Compiladores?

J

Com certeza melhor que o meu de arquitetura de computadores que deveria trabalhar numa financiadora, porque toda aula ele falava dos benefícios de financiar um carro ao invés de comprar.

D

Na minha faculdade não tem matéria de compiladores e o nível da maioria dos alunos é muito fraco.
Entender compiladores é essencial, e o básico nem é tão difícil. Pode ter sido dificil há anos atrás, hoje não é não.

Mas será que estudar compiladores da forma como é ensinada hoje vai mesmo resolver o problema? O problema é abordado do mesmo jeito que era há anos atrás. Focam na compilacao de linguagens estáticas, geralmente um subset de pascal ou c, usando lex e yacc. Ninguém vai aprender lisp ou conceitos de linguagens estudando compiladores desse jeito não. Peguem os livros de compiladores escritos por autores brasileiros, se tiver um que não se encaixa nessa descri’cão que eu dei, me fala que eu vou correndo comprar.

L

Com certeza melhor que o meu de arquitetura de computadores que deveria trabalhar numa financiadora, porque toda aula ele falava dos benefícios de financiar um carro ao invés de comprar.

E eu, uma vez tive um que tava tentando fazer um esquema assim: Uma página era montada por um servlet e era tipo um placar de um jogo e esse placar tinha que ser atualizado automaticamente.

Qual foi a idéia genial? Criar uma thread no servlet que ficasse dando println e aí a página (supostamente) iria ficar se atualizando

M

E o que isso tem haver com o tema do tópico: Faculdades e Compiladores?

Que vc precisa saber sobre compiladores e macros Lisp para entender como a linguagem torna inutil aqueles patterns que programadores OO adoram vomitar nas entrevistas de emprego.

Bom, a faculdade é onde supostamente vc deveria sair sabendo sobre o que estou falando.

F

Implementa o pattern na propria linguagem seria isso?? E isso seriam as macros lisp??

Ok, então no Lisp tu programa e abstrai os patterns, implementando eles na linguagem.

E quando tu vai pra casa e vai fazer aquele projeto pessoal as macros criadas nos trabalho que “eliminam” os patters vem junto com voce?? Tipo um cachorrinho correndo??

Humm, legal então supondo que tu nao tem cachorro, onde quer que voce va, tu tem que levar teus macros ou sei la o que no bolso.

Humm isso ta me cheirando uma especie de “framework” de patterns, então se eu fizer um .jar que abstrai os patterns vai dar na mesma, com a diferença que tu abstraiu programando na linguagem e eu usando a linguagem!!!

E por incrivel que pareça nos dois casos, os patterns, ainda assim, estão lá, abstraidos mas estão, pois voce teve que implementa-los, sendo uma unica vez ou não.

Continuando na idéia, então se não vem de fábrica na linguagem, então sim, eu tenho que implementar patterns em Lisp tanto quanto em java, e se eu fizer isso em forma de macro ou de um .jar, terei que fazer apenas uma vez mas terei que carrega-los comigo onde for.

E finalizando então, Lisp é uma maravilha, nele tu tem que implementar patterns apenas uma vez, mas caso voce seja um bom arquiteto java, bom em OO e consigar fazer um .jar para abstrair os teus patterns, no final DA NA MESMA, basta carregar um pen drive no bolso, onde quer que voce vá com duas pastas de nomes “Patterns Lisp(Macros)”, “Patterns para Java(.jar)”

M

fredferrao:

Humm isso ta me cheirando uma especie de “framework” de patterns, então se eu fizer um .jar que abstrai os patterns vai dar na mesma, com a diferença que tu abstraiu programando na linguagem e eu usando a linguagem!!!

Isso é um framework de patterns pra vc, eu suponho, porque seu cerébro esta condicionado a pensar que patterns são a unica maneira de construir abstrações em software.

fredferrao:

E por incrivel que pareça nos dois casos, os patterns, ainda assim, estão lá, abstraidos mas estão, pois voce teve que implementa-los, sendo uma unica vez ou não.

Considerando que o projeto Java não tenha sido cancelado porque a equipe ficou a maior parte do tempo discutindo qual padrão usar e o projeto tenha estourado o prazo, sim. Estão lá como uma gilette e uma motoserra, mas vc só teve que arrumar um de cada.


E finalizando então, Lisp é uma maravilha, nele tu tem que implementar patterns apenas uma vez, mas caso voce seja um bom arquiteto java, bom em OO e consigar fazer um .jar para abstrair os teus patterns, no final DA NA MESMA, basta carregar um pen drive no bolso, onde quer que voce vá com duas pastas de nomes “Patterns Lisp(Macros)”, “Patterns para Java(.jar)”

Seu argumento de que tudo é a mesma coisa porque numa visão puramente estatica “o código é simplesmente uma sequencia de caracteres de texto representados num arquivo localizado em algum sistema de armazenamento” chega a ser patético.

Mas não, o final não da na mesma porque estamos falando de criar abstrações por meio de DSLs e Java não é bom pra isso. Mas uma coisa vc esta certo, para usuários a tecnologia que roda por detrás não importa. Se vc é apenas usuário então vai brincar com seu cachorrinho e deixa o tópico pra quem tem algo a acrescentar.

D

Tem cada cara mau aqui.

R

E o que isso tem haver com o tema do tópico: Faculdades e Compiladores?

Que vc precisa saber sobre compiladores e macros Lisp para entender como a linguagem torna inutil aqueles patterns que programadores OO adoram vomitar nas entrevistas de emprego.

Bom, a faculdade é onde supostamente vc deveria sair sabendo sobre o que estou falando.

Se vc acha que a melhor forma de fazer-se algo é algo inútil, então quem começa a vomitar é vc.
Andei vendo os exemplos de Lisp, uma linguagem antiga, histórica e acadêmica da década de 50 onde if nao tem else (o que torna um código grande de difícil compreensão:

(defun fatorial (n)
  (if (= n 0)
      1
      (* n (fatorial (- n 1)))))

é assim que se dividem dois números:

(/ (fatorial 10000) (fatorial 9998))

Agora, Lisp é inútil? Não, li tmb que ainda é usada para projetos matemáticos ou algo desse tipo.
Inútil é ficar vomitando besteira em um tópico só pra causar revolta geral.

F

mochuara:
fredferrao:

Humm isso ta me cheirando uma especie de “framework” de patterns, então se eu fizer um .jar que abstrai os patterns vai dar na mesma, com a diferença que tu abstraiu programando na linguagem e eu usando a linguagem!!!

Isso é um framework de patterns pra vc, eu suponho, porque seu cerébro esta condicionado a pensar que patterns são a unica maneira de construir abstrações em software.


Não se esta discutindo a maneira de se abstrair software, esta se discutindo a existencia e implementação dos patterns em Lisp/Java ou não, caso sejam necessarios.

mochuara:

O mesmo vale para o Lisp, e considerando o que eu disse isto será feito apenas uma vez, essa discussão deve ter ocorrido no primeiro sistema feito pela empresa, se futuramente precisarem de um pattern apenas adicionam o jar/macro, não precisam recodificar.

mochuara:

Eu nunca disse que seria a mesma implementação, eu disse que o resultado deu no mesmo, eu disse que voce teve que implementar alguns patterns no Lisp, seja uma unica vez ou não.

Em suma os patterns apenas se mudaram de local, sairam da repetição diaria dentro do código da app e foram parar numa macro lisp, ou em um framework java, e não é exatamente isto o que se propoe frameworks java consagrados? Mas mesmo assim ainda estão la camuflados em macros/jars ou não, e como não vieram nativos na linguagem, eu torno a repetir, voce TEVE QUE IMPLEMENTA-LOS quando precisou deles.

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.

C

Sério, de novo essa discussão sobre a falta(no bom sentido) de design patterns em Lisp?
Sorte a de vcs que o thiagosc não apareceu por aqui…

J

clone_zealot:
Sério, de novo essa discussão sobre a falta(no bom sentido) de design patterns em Lisp?
Sorte a de vcs que o thiagosc não apareceu por aqui…

Apareceu, você não viu?
Mas enquanto ninguém se matar é apenas uma discussão interessante.

M

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.

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.

M

fredferrao:

Em suma os patterns apenas se mudaram de local, sairam da repetição diaria dentro do código da app e foram parar numa macro lisp, ou em um framework java, e não é exatamente isto o que se propoe frameworks java consagrados? Mas mesmo assim ainda estão la camuflados em macros/jars ou não, e como não vieram nativos na linguagem, eu torno a repetir, voce TEVE QUE IMPLEMENTA-LOS quando precisou deles.

O que vc esta dizendo é, ignore como o sistema foi feito, como ele é implementado, se ele faz bem o serviço ou não, só o que importa é o resultado produzido por ele. Que tipo de profissional de software é vc?

Voce achou que Lisp ia fazer geração espontanea da aplicação pra vc?

F

mochuara:
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.

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.

Mesma atitude e nada de novo a acrescentar.

Nunca disse em momento algum que seriam os mesmos patterns.

M

fredferrao:
mochuara:
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.

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.

Mesma atitude e nada de novo a acrescentar.

Nunca disse em momento algum que seriam os mesmos patterns.

Claro que não haveriam de ser. O ponto não é se Lisp pode ter patterns ou não, mas sim que é possivel elimina-los. Algumas linguagens como Java isto não é possivel, e vc precisa aprender a aceitar que patterns são uma feature. Mas é justamente o contrário, sinal de limitação da linguagem.

F

mochuara:
fredferrao:
mochuara:
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.

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.

Mesma atitude e nada de novo a acrescentar.

Nunca disse em momento algum que seriam os mesmos patterns.

Claro que não haveriam de ser. O ponto não é se Lisp pode ter patterns ou não, mas sim que é possivel elimina-los. Algumas linguagens como Java isto não é possivel, e vc precisa aprender a aceitar que patterns são uma feature. Mas é justamente o contrário, sinal de limitação da linguagem.

Ta então vamos mudar.

Como afinal voce faz esta eliminação??? Com macros??

T

Quanta ignorância. Você a diferença entre tempo de execução e tempo de compilação? Macros não existem em código compilado pois o código já foi transformado no que precisa ser executado. Portanto você não está “colocando patterns em macros” assim como coloca-os em jar. Elas não existem mais. Aquele pattern é agora uma nova construção sintática da linguagem.

Não, não é a mesma coisa, pois você não precisa se preocupar com instâncias, estado de objetos, etc.

As APIs do Java são uma torre que um dia cai. Debugar 5 ou mais níveis de APIs chamando APIs é uma porcaria.

T

renamed:
Se vc acha que a melhor forma de fazer-se algo é algo inútil, então quem começa a vomitar é vc.
Andei vendo os exemplos de Lisp, uma linguagem antiga, histórica e acadêmica da década de 50 onde if nao tem else (o que torna um código grande de difícil compreensão:

Haha. Lisp é usado largamente em diversos tipos de sistemas, por exemplo:

http://www.lispworks.com/

ou

http://www.franz.com/

Se Lisp tem 50 anos é evidência que mesmo depois de todo esse tempo linguagens como Java não tem 1/10 do que uma linguagem de 50 anos atrás tinha. É um atestado de incompetência.

Foi até usada em jogos no PS2. Diga-nos quantos jogos já foram feitos em Java?

R

http://www.taikodom.com.br/

Já vi muito jogo 3d java nesse fórum:

http://www.javagaming.org/forums/index.php

http://www.vivaolinux.com.br/script/Jogo-do-Azar

Isso sem citar os Jogos para celular…

T

renamed:

Isso sem citar os Jogos para celular…

Joguinho de celular e jogos amadores não contam. Quero dizer uma grande produção, de verdade, para videogames e PC.

A

Então saiba Lisp e seja feliz.

F

Thiagosc:
renamed:

Isso sem citar os Jogos para celular…

Joguinho de celular e jogos amadores não contam. Quero dizer uma grande produção, de verdade, para videogames e PC.

TAIKODOM - MMORPG

T

fredferrao:
Thiagosc:
renamed:

Isso sem citar os Jogos para celular…

Joguinho de celular e jogos amadores não contam. Quero dizer uma grande produção, de verdade, para videogames e PC.

TAIKODOM - MMORPG

Que eu saiba o Taikodom foi feito em C++.

F

Thiagosc:
fredferrao:
Thiagosc:
renamed:

Isso sem citar os Jogos para celular…

Joguinho de celular e jogos amadores não contam. Quero dizer uma grande produção, de verdade, para videogames e PC.

TAIKODOM - MMORPG

Que eu saiba o Taikodom foi feito em C++.

Ja instalou?? O server tem C++ o cliente é java.

J

fredferrao:
Thiagosc:
fredferrao:
Thiagosc:
renamed:

Isso sem citar os Jogos para celular…

Joguinho de celular e jogos amadores não contam. Quero dizer uma grande produção, de verdade, para videogames e PC.

TAIKODOM - MMORPG

Que eu saiba o Taikodom foi feito em C++.

Ja instalou?? O server tem C++ o cliente é java.

O cliente é java, mas as libs são nativas( No caso opengl), então podemos dizer é que a lógica do jogo que é java.

V

Thiagosc:
fredferrao:
Thiagosc:
renamed:

Isso sem citar os Jogos para celular…

Joguinho de celular e jogos amadores não contam. Quero dizer uma grande produção, de verdade, para videogames e PC.

TAIKODOM - MMORPG

Que eu saiba o Taikodom foi feito em C++.

Eu conheço várias pessoas da Hoplon. Eles me informaram que o server é em Java. Substituiram a engine de física, que usava a Havoc, por uma em Java também. O jogo torna-se mais rápido, e mais java, a cada versão.

V

Thiagosc:
renamed:
Se vc acha que a melhor forma de fazer-se algo é algo inútil, então quem começa a vomitar é vc.
Andei vendo os exemplos de Lisp, uma linguagem antiga, histórica e acadêmica da década de 50 onde if nao tem else (o que torna um código grande de difícil compreensão:

Haha. Lisp é usado largamente em diversos tipos de sistemas, por exemplo:

http://www.lispworks.com/

ou

http://www.franz.com/

Se Lisp tem 50 anos é evidência que mesmo depois de todo esse tempo linguagens como Java não tem 1/10 do que uma linguagem de 50 anos atrás tinha. É um atestado de incompetência.

Foi até usada em jogos no PS2. Diga-nos quantos jogos já foram feitos em Java?

O mais engraçado, é que você criticou fortemente esses mesmos argumentos no C++.

O C++ também tem mais de 50 anos, também já foi usados em milhões de aplicações comerciais, também suporta metaprogramação como um feature do compilador.

Sinceramente. Nunca entrei numa empresa que usasse LISP. E os exemplos de “diversos softwares de lisp” que passam são sempre muito específicos e a maior parte não usa LISP como linguagem principal (aposto que isso vale até mesmo para os jogos, citados por você).

V

fredferrao:
mochuara:
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.

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.

Mesma atitude e nada de novo a acrescentar.

Nunca disse em momento algum que seriam os mesmos patterns.

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.

J

ViniGodoy:
Thiagosc:
renamed:
Se vc acha que a melhor forma de fazer-se algo é algo inútil, então quem começa a vomitar é vc.
Andei vendo os exemplos de Lisp, uma linguagem antiga, histórica e acadêmica da década de 50 onde if nao tem else (o que torna um código grande de difícil compreensão:

Haha. Lisp é usado largamente em diversos tipos de sistemas, por exemplo:

http://www.lispworks.com/

ou

http://www.franz.com/

Se Lisp tem 50 anos é evidência que mesmo depois de todo esse tempo linguagens como Java não tem 1/10 do que uma linguagem de 50 anos atrás tinha. É um atestado de incompetência.

Foi até usada em jogos no PS2. Diga-nos quantos jogos já foram feitos em Java?

O mais engraçado, é que você criticou fortemente esses mesmos argumentos no C++.

O C++ também tem mais de 50 anos, também já foi usados em milhões de aplicações comerciais, também suporta metaprogramação como um feature do compilador.

Sinceramente. Nunca entrei numa empresa que usasse LISP. E os exemplos de “diversos softwares de lisp” que passam são sempre muito específicos e a maior parte não usa LISP como linguagem principal (aposto que isso vale até mesmo para os jogos, citados por você).

Foi usada, e é usada ainda. A grande maioria das empresas de jogos, sistemas operacionais e aplicações para escritório usam c++, como é o caso da Microsoft, Sun…

V

Só um adendo sobre o que falei sobre a Hoplon usar Java no lugar do C++ e ficar mais rápido. Não ficou mais rápido por causa do Java, até pq, um código C++ enxuto é mais rápido do que um Java.

A questão está justamente no “enxuto”. A engine de física que usaram no lugar da Havoc, desenvolvida por eles, levava em consideração apenas a física no vácuo, para corpos rígidos, que é 90% da física do Taikodom.

Além disso, pequenas variações de performance num servidor MMO são pouco perceptíveis, já que os atrasos de rede costumam a ser um problema maior, e o cliente é feito para disfarça-lo. Como consequência, isso disfarça o desempenho no servidor também.

Criado 26 de dezembro de 2009
Ultima resposta 11 de jan. de 2010
Respostas 113
Participantes 26