Postado por ShiningRay em 3 de abril de 2006
Edwin Martin < [email protected] >
Traduzido por: ShiningRay @ Nirvana Studio
Tenho desenvolvido aplicativos PHP nos últimos quatro anos. PHP é realmente fácil de escrever. Mas o PHP também tem algumas falhas muito sérias.
Abaixo darei minhas razões pelas quais o PHP não é adequado para sites maiores do que pequenos sites amadores.
1. Fraco suporte para recursão A recursão é um mecanismo para as funções chamarem a si mesmas. Este é um recurso poderoso que pode transformar algo complexo em algo muito simples. Um exemplo de uso de recursão é o quicksort. Infelizmente, o PHP não é muito bom em recursão. Zeev, um desenvolvedor de PHP, disse: "O PHP 4.0 (Zend) usa uma abordagem de pilha para dados densos em vez de uma abordagem de heap. Isso significa que o número de funções recursivas que ele pode tolerar é significativamente menos limitado do que outras linguagens." . Esta é uma desculpa muito ruim. Toda linguagem de programação deve fornecer um bom suporte à recursão.
2. Muitos módulos PHP não são thread-safe Há alguns anos, o Apache lançou a versão 2.0 do servidor web. Esta versão suporta o modo multithreading, no qual uma parte do software pode executar várias partes ao mesmo tempo. O inventor do PHP diz que o núcleo do PHP é seguro para threads, mas os módulos não essenciais podem não ser. Mas nove em cada dez vezes, você deseja usar este módulo em um script PHP, mas isso torna seu script incompatível com o modo multithread do Apache. É por isso que a equipe do PHP não recomenda executar o PHP no modo multithread do Apache 2. O fraco suporte ao modo multithread do PHP é frequentemente citado como uma das razões pelas quais o Apache 2 permanece impopular.
Por favor, leia esta discussão: Slashdot: Sites rejeitando o Apache 2?.
3. O PHP está quebrado por motivos comerciais Ao usar o cache, o desempenho do PHP pode ser aumentado em 500% [ver benchmark]. Então, por que o cache não está embutido no PHP? Como a Zend, fabricante do PHP, vende seu próprio Zend Accelerator, então é claro que eles não querem abandonar seu produto comercial.
Mas há outra alternativa: APC (a Zend mais tarde lançou o Zend Optimizer, um acelerador - tradutor gratuito)
4. Sem namespace Imagine que alguém criou um módulo PHP para ler arquivos. Uma função no módulo é chamada de leitura. Então, o módulo de outra pessoa pode ler a página da web, que também contém uma função de leitura. Então não podemos usar esses dois módulos ao mesmo tempo, porque o PHP não sabe qual função você deseja usar.
Mas existe uma solução muito simples: os namespaces. Certa vez, alguém sugeriu adicionar esse recurso ao PHP5, mas infelizmente ele não o fez. Agora, sem namespaces, cada função deve ser prefixada com o nome do módulo para evitar conflitos de nome. Isso resulta em nomes de funções terrivelmente longos, como xsl_xsltprocessor_transform_to_xml, o que torna o código difícil de escrever e entender.
5. Caracteres de formato de data não padrão Muitos programadores estão familiarizados com caracteres de formato de data, que vêm das linguagens UNIX e C. Várias outras linguagens de programação adotaram esse padrão, mas por incrível que pareça, o PHP tem seu próprio conjunto de caracteres de formato de data completamente incompatíveis. Em C, “%j” representa o dia do ano, e em PHP representa o dia do mês. No entanto, para tornar as coisas ainda mais confusas: a função strftime e a função date_format do Smarty (um mecanismo de modelo PHP popular) usam caracteres de formatação C/UNIX.
6. Licença confusa Você pode pensar que o PHP é gratuito, assim como todos os módulos PHP mencionados no manual. Errado! Por exemplo, se você deseja gerar arquivos PDF em PHP, você encontrará dois módulos no manual: PDF e ClibPDF. Mas ambos são licenciados comercialmente. Portanto, para cada módulo usado, você deve concordar com sua licença.
7. Regras de nomenclatura de funções inconsistentes. Alguns nomes de funções são compostos de múltiplas palavras. Geralmente existem três hábitos de combinações de palavras:
emenda direta: getnumberoffiles
Separe com sublinhados: get_number_of_files
Lei do Camelo: getNumberOfFiles
Para a maioria dos idiomas, escolha um destes. Mas PHP é usado.
Por exemplo, se você deseja converter alguns caracteres especiais em entidades HTML, você usaria a função htmlentities (unir palavras diretamente). Se quiser usar a funcionalidade oposta, você precisa usar seu irmão mais novo, html_entity_decode. Por alguma razão especial, o nome desta função possui palavras separadas por sublinhados. Como isso poderia ser? Você sabe que existe uma função chamada strpad. Ou ele é str_pad? Toda vez você tem que verificar qual é o símbolo ou apenas esperar por um erro. As funções não diferenciam maiúsculas de minúsculas, portanto, para PHP não há diferença entre rawurldecode e RawUrlDecode. Isso também é ruim porque ambos são usados e parecem diferentes, confundindo o leitor.
8. O inferno das citações mágicas As citações mágicas podem proteger scripts PHP de ataques de injeção de SQL. Isso é bom. Mas por alguns motivos, você pode desligar esta configuração no php.ini. Portanto, se você quiser escrever um script flexível, sempre precisará verificar se as referências mágicas estão ativadas ou desativadas. Supõe-se que esse "recurso" facilite a programação, mas na verdade a torna mais complicada.
9. Falta de uma estrutura padrão Um site em crescimento sem uma estrutura global acabará por se tornar um pesadelo de manutenção. Uma estrutura pode facilitar muitas tarefas. O modelo de framework mais popular atualmente é o modelo MVC, no qual a camada de apresentação, a lógica de negócios e o acesso ao banco de dados são separados.
Muitos sites PHP não usam o modelo MVC. Eles nem têm moldura. Mesmo agora existem alguns frameworks PHP e você mesmo pode escrever um. Os artigos e manuais sobre PHP não melhoram nem uma palavra o framework. Embora os desenvolvedores JSP usem estruturas como Struts e os desenvolvedores ASP usem .Net, parece que esses conceitos são amplamente compreendidos pelos desenvolvedores PHP. Isso mostra o quão profissional o PHP realmente é.
Resumir
Qual é o problema?
Para projetos muito pequenos, pode ser uma linguagem de programação muito satisfatória. Mas para projetos maiores e mais complexos, o PHP mostra sua fraqueza. À medida que continuar explorando, você encontrará soluções para alguns dos problemas que mencionei. Então, uma vez conhecida a solução, por que não corrigi-la? Além disso, por que essas correções não são mencionadas no manual?
É bom que uma linguagem de código aberto seja muito popular. Mas, infelizmente, não é uma ótima linguagem. Espero que todos os problemas sejam resolvidos um dia (talvez no PHP6?), e então teremos uma linguagem de código aberto que seja de código aberto e fácil de usar.
Agora, quando você quiser iniciar um projeto com mais de 5 páginas de script, é melhor considerar C#/ASP.Net ou Java/JSP ou talvez Python também seja uma escolha melhor.
Fonte deste artigo: http://workgroup.cn/CS/blogs/php/archive/2006/06/29/1354.aspx