Faculdades e compiladores

This message was edited 1 time. Last update was at 09/01/2010 13:46:47

Então saiba Lisp e seja feliz.

Thiagosc wrote:

renamed wrote:
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

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

fredferrao wrote:

Thiagosc wrote:

renamed wrote:
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++.

Thiagosc wrote:

fredferrao wrote:

Thiagosc wrote:

renamed wrote:
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.

GUJ Expert Membro desde: 13/11/2008 12:10:18 Mensagens: 3927 Offline

fredferrao wrote:

Thiagosc wrote:

fredferrao wrote:

Thiagosc wrote:

renamed wrote:
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.

Thiagosc wrote:

fredferrao wrote:

Thiagosc wrote:

renamed wrote:
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.

Thiagosc wrote:

renamed wrote: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ê).

This message was edited 4 times. Last update was at 11/01/2010 08:58:41

fredferrao wrote:

mochuara wrote:

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

GUJ Expert Membro desde: 13/11/2008 12:10:18 Mensagens: 3927 Offline

ViniGodoy wrote:

Thiagosc wrote:

renamed wrote: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....

This message was edited 1 time. Last update was at 11/01/2010 10:05:52

juliocbq wrote: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....

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.

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