[Cascavel-pm] Res: off topic DotNet

[João André Simioni]

> Valeu pela dica, não entendi o porque do comentário, já que
> ninguém
> afirmou o contrário, acho que todo mundo aqui já sabe disso.

Eu afirmei que desempenho depende do desenvolvedor. Você justificou que isso
não é verdade e deu XS de exemplo. Eu reafirmo que depende. Saber que
existem tais recursos e como usar é mérito do desenvolvedor. Todas as
linguagens têm recursos para usufruir de código otimizado.

> Não, não complementei nada da sua afirmação, eu dei dois
> contra-exemplos. Me parece que você não leu direito (o erro > na grafia do
> meu nome é um indicador disso).

Acredito que você não tenha entendido meus exemplos então, pois os seus
contra exemplos não contradizem a minha opinião.

Peço desculpas pelo erro da grafia do seu nome, isso realmente não deveria
ter acontecido.

> Você não respondeu nenhuma das perguntas, provavelmente > porque não as
> leu direito. Vou repetir algumas com um pouco mais de clareza:

Por algum motivo, seu email veio quebrado em 3 emails... o gmail agrupou e
eu so vi o último.

> "opções melhores" segundo qual critério? Mais rápidas em
> termos de
> execução?  Mais rápidas em termos de velocidade de
> desenvolvimento? Mais
> baratas? Mais fáceis de implantar?

2 critérios básicos - quantidade de sistemas desenvolvidos na plataforma e
disponibilidade mão de obra.

Em ambas, PHP e Java batem Perl muito facilmente. Pelo menos no Brasil (acho
que você não mora aqui).

Em termos de fazer o que tem que ser feito, todas elas fazem o que tem que
ser feito.

> Qual o limiar de complexidade que separa "sistema complexos" > de
> "sistemas não complexos"?

> Qual é exatamente a limitação de perl que impede de desenvolver > GUIs
> non-web?

Segundo minha opinião:

- Sistemas complexos são aqueles que envolvem:

* Uma interface administrativa (GUI)
* Uma interface de usuário (GUI)
* Um core com N funções

Em relação a GUIs em Perl:

* TK tem uma série de limitações - tanto que wxWidgets é considerada a
melhor API para GUIs em Perl.
* wxWidgets ainda não tem versão 1.0 e vários itens disponíveis em outros
APIs (incluindo Flex) ainda não estão disponíveis.

[]'s





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

> >>>>> "João" == João André Simioni <jasimioni em gmail.com> writes:
>
>     João> Eder,assim como Perl tem XS, outras linguagens têm suas
>    João> próprias maneiras de acessar bibliotecas em C para otimizar
>    João> desempenho.
>
> Valeu pela dica, não entendi o porque do comentário, já que ninguém
> afirmou o contrário, acho que todo mundo aqui já sabe disso.
>
>    João> E com relação à Flickr / Facebook o que eu quis dizer é que
>    João> geralmente o gargalo não é o CGI, mas usualmente o
>    João> processamento do client ou banco de dados. Você só deu mais
>    João> dois exemplos complementando a minha afirmação.
>
> Não, não complementei nada da sua afirmação, eu dei dois
> contra-exemplos. Me parece que você não leu direito (o erro na grafia do
> meu nome é um indicador disso).
>
>    João> A discussão levantada é que, na minha opinião, Perl é melhor
>    João> utilizado como uma clue language e para rotinas
>    João> administrativas - sejam elas de redes, de banco de dados ou de
>    João> sistema, do que como linguagem para desenvolvimento de
>    João> sistemas complexos e sistemas que possuam GUI sem ser
>    João> Web. Para Web Perl é Ok, só comentei que considero que há
>    João> opções melhores.
>
> Você não respondeu nenhuma das perguntas, provavelmente porque não as
> leu direito. Vou repetir algumas com um pouco mais de clareza:
>
> "opções melhores" segundo qual critério? Mais rápidas em termos de
> execução?  Mais rápidas em termos de velocidade de desenvolvimento? Mais
> baratas? Mais fáceis de implantar?
>
> Qual o limiar de complexidade que separa "sistema complexos" de
> "sistemas não complexos"?
>
> Qual é exatamente a limitação de perl que impede de desenvolver GUIs
> non-web?
> _______________________________________________
> 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/20100628/55269790/attachment.html>