[Cascavel-pm] Res: off topic DotNet

[João André Simioni]

Eder,

assim como Perl tem XS, outras linguagens têm suas próprias maneiras de
acessar bibliotecas em C para otimizar desempenho.

E com relação à Flickr / Facebook o que eu quis dizer é que geralmente o
gargalo não é o CGI, mas usualmente o processamento do client ou banco de
dados. Você só deu mais dois exemplos complementando a minha afirmação.

A discussão levantada é que, na minha opinião, Perl é melhor utilizado como
uma clue language e para rotinas administrativas - sejam elas de redes, de
banco de dados ou de sistema, do que como linguagem para desenvolvimento de
sistemas complexos e sistemas que possuam GUI sem ser Web. Para Web Perl é
Ok, só comentei que considero que há opções melhores.

[]'s

2010/6/26 Eden Cardim <edencardim em gmail.com>

> >>>>> "João" == João André Simioni <jasimioni em gmail.com> writes:
>
>    João> O melhor e mais rápido fica por conta do desenvolvedor.
>
> Não, não fica. Por exemplo, sem XS, é impossível implementar um
> algoritmo com o máximo de eficiência em perl, já que você não tem acesso
> a aritmética low-level como por exemplo, adição de constantes
> caracter. Perl sempre converte números para sua própria representação
> nativa, que roda dentro do interpretador do perl, por isso, é sempre mais
> lento que C, onde não acontece a conversão e a operação acontece
> diretamente nos registradores do processador.
>
>    João> Uma aplicação Web tem a maior parte do seu desempenho dependente
>    João> do Banco de Dados e do navegador, ou da aplicação em ajax ou
>    João> flex.
>
> Você está presumindo que toda aplicação web utiliza um banco de dados,
> requisições assíncronas ou flex. Aplicações para facebook, por exemplo,
> tem o gargalo de tempo nas requisições à API do facebook.  Serviços de
> hosting de imagens, como o flickr, tem o gargalo na transferência e
> processamento das imagens.
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/cascavel-pm/attachments/20100627/355ae3f0/attachment.html>