Davi Silva (davi_carvalho@yahoo.com) avisa: Esta veio do Slashdot. Apresentação (html) muito interessante que mostra, em detalhes, como foi a escolha que o Yahoo! fez pelo PHP. Respostas interessantes à perguntas do tipo: "por que estão adotando, com maior ênfase, softwares open source ?", "por que não ASP, C/C++, PERL, Cold Fusion, J2EE...". Leitura interessante, mesmo se você não é um entusiasta do PHP.
Postado por brain em 30 de outubro de 2002, 01:10 PM
Não entendi direito os motivos de pq não usar Java... entendi apenas o que diz que os threads java em BSD tem desempenho ruim.
Postado por: Arch em outubro 30, 2002 04:04 PMEu não entendi também alguns contras que foram alegados, como Cold Fusion 'ugly sintax', ou Perl, pois tem mais de uma maneira de fazer as coisas entre outros. Bem, de qualquer forma, mais uma vitória do SL.
Postado por: guara em outubro 30, 2002 04:47 PMPô, os motivos do Cold Fusion e do Perl pra mim pareceram bem justificados e até certo ponto óbvios. O código tem que ser bem compreendido por seres humanos, e a sintaxe maleável do perl (em que se pode fazer a mesma coisa de inúmeros jeitos diferentes) dificulta isso, além do que gera falta de uniformização de código de programação, e o Cold Fusion é também meio "criptográfico" com sua sintaxe.
Já o motivo para não usar J2EE é hilário, para não dizer trágico. É verdade: a doença do THREADISMO é sintomática em Java. Quase todo mundo gosta de usar threads nessa linguagem. Assim, as APIs, programas, bibliotecas e tudo o mais que se encontra pra Java são infestados de threads.
Por que o threadismo é uma doença? Basicamente porque desperdiça recursos demais e tem o desempenho muito dependente de plataforma. Algumas plataformas rodam threads bem, outras (como o FreeBSD, que o Yahoo usa) não.
Quanto aos recursos, pense bem: imagine que você tem um servidor de qualquer coisa que aceita 1000 conexões simultâneas (digamos, um servidor de IRC - bate-papo). O que é mais leve: você utilizar uma chamada select() em loop infinito para multiplexar entre as várias conexões simultâneas, ou usar 1000 threads diferentes, um para cada conexão? O pessoal que programa em Java costuma achar a segunda solução melhor... =) E se esquece que em máquinas com um processador a fatia de tempo (time-slice) do escalonador não pode ser nem muito grande nem muito pequena, ficando em cerca de 10 ms (valor típico). Com 1000 threads concorrentes, cada um deles seria chamado a cada (1000*0.01s) 10 segundos! O que é um tempo grande demais.
Postado por: Patola (Cláudio Sampaio) em outubro 30, 2002 05:01 PMTem mais Patola, os servelets e com consequentemente as JSPs (Java Server Pages), são tratadas como threads pela JVM, ou seja, para não se ultilizar threads com java no lado do servidor teria que se ignorar todo o J2EE e reinventar a roda. Nesse ponto acho a não escolha do java muito coerente.
Postado por: gbitten em outubro 31, 2002 09:06 AMAliás, programadores java de todo o Brasil, aqui está uma solução muito boa ao "threadismo" no java, enviado a mim por um cara em uma lista de discussão:
http://www.onjava.com/pub/a/onjava/2002/10/02/javanio.html?page=last
Postado por: Patola (Cláudio Sampaio) em outubro 31, 2002 02:53 PMTudo bem que o CF é pago... mas dizer que ele é difícil de entender, aí é outra coisa... pra quem gosta de C, tudo bem, ele é diferente... mas é uma linguagem mto fácil de se usar... mas tem que pagar...
Postado por: Arch em novembro 1, 2002 03:31 PMEu como programador Perl, só posso dizer que PHP até pode ser melhor para o projeto deles, principalmente quando se fala de mão-de-obra. Acredito que é bem mais fácil encontrar um programador PHP do que um programador em Perl...
Mas achar que somente isso vai resolver os problemas de entendimento do código fonte do software deles é ilusão...
Aliás, na minha opinião, a flexibilidade do Perl é uma das maiores vantagens dele. Existem dezenas de maneiras de se implementar uma mesma coisa, com o Perl, mas eu não considero isso uma desvantagem. Pelo contrário. Graças a isso, o Perl pode se "moldar" ao cliente e não o cliente se moldar a linguagem de programação...
Uma documentação "como-implementar-o-código", bem estruturada, resolveria o problema deles, independente da linguagem escolhida.
Por último, para concluir, só posso dizer que eles sentiram o benefício real da escolha, quando precisarem, por exemplo, migrar a base do banco de dados para um outro (por exemplo, do mysql para o postgresql)... Eh, eh, eh...
(se bem que agora o PHP está evoluíndo para um modelo similar ao CPAN do Perl, que pode resolver futuramente este problema)...
Parabéns ao Y! pela escolha, sem dúvida é a mais viável atualmente. O páreo foi duro, principalmente com concorrentes como o Perl e JSP, mas não houve surpresa. Com relação à migração para outras bases de dados, não há grandes problemas se eles utilizarem a PEAR e uma boa documentação.
Postado por: Vanderson Telmo em novembro 5, 2002 03:38 PMYahoo! Esta 100% Certo php é a linguagem openSource, uma das melhores, com o melhor desempenho! Roda mais rápido no servidor do que ASP!
Postado por: Fernando em fevereiro 21, 2003 01:55 PM
O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação) notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter histórico, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.