Meowcate (./52) :
Mais en définitive, le langage PHP est-il pleinement fonctionnel (et complexe dans sa diversité) ou simplement mauvais ? en somme, l'usage d'un framework (j'ai fait un peu de PRADO, maintenant sous CakePHP) qui ne fait qu'exploiter PHP pour en rendre les tâches de développement avec ce langage plus simple est-il une bonne solution ou faut-il vraiment oublier PHP (et par ricochet, ses frameworks) et partir plutôt sur un langage comme Python ou Rails ?

rails n'étant pas un langage, pour autant que je sache, mais un framework Ruby

Pour faire du PHP quelque chose comme 40h par semaine depuis plusieurs années, et réussir à en faire ce que je veux / ce dont j'ai / mes collègues / clients ont besoin, PHP est "suffisament fonctionnel".
Après, "pleinement fonctionnel", c'est vague : au final, quelque soit le langage, ce n'est pas le rôle du langage que de répondre à 100% de tes besoins ; le rôle du langage est de fournir les briques permettant de construire ce dont tu as besoin -- quitte à utiliser des bibliothèques / frameworks existant, qui ne sont que d'autres briques d'un niveau plus élevé, t'évitant de réinventer la roue (en risquant de la faisant carrée).

Meowcate (./57) :
Je comprends néanmoins les prises de tête quand un collègue dit à un autre d'utiliser strpos pour vérifier si un mot existe dans une phrase, et qu'à vérifier la fonction sur la doc il y a une fonction "strripos" pour exactement la même tâche, mais en version case-insensitive. Réécrire strpos avec un paramètre optionnel pour la gestion du case n'aurait pas été préférable ?

Deux choses, là dessus :
- il y a un brin d'historique : en C, majuscules et minuscules ne sont pas la même lettre.
- deux chaines qui n'ont pas la même casse ne sont pas "égales", en informatique ; strpos et stripos faisant deux choses distinctes, plutôt que de rajouter un paramètre (puis un autre, puis encore un autre, et encore encore un autre au fur et à mesure des cas venant se rajouter), autant avoir deux fonctions distinctes.

Et une troisième pour la route et pour raler :
- quid de l'unicode (en fait, strpos travaille sur des octets, et pas des caractères... un des vrais gros défauts de PHP)
- tu peux aussi ajouter ce qui est collation / locale : un "é" est-il la même chose qu'un "e" ? Et dans une autre langue que le français ? Voire même des cas tordus où un caractère peut être assimilé à plusieurs autres caractères (je pense au "B" de l'allemand, qui, si ma mémoire est bonne, peut revenir au même que "ss" dans certains cas ? ) ? Voire des cas encore plus tordus où un caractère représente un mot ? une idée ?
- un autre "problème" de PHP c'est que tu as stripos pour chercher la position d'une sous-chaine dans une chaine en case-insentive ; alors que tu as strcasecmp pour comparer deux chaines en case-insensitive \o/

vince (./58) :
C'est ce qu'on (ici) appelle le dév golgotha : on empile des petites merdes patch par patch pour au final obtenir un truc monstrueux mais qui se tient à peu près...

Au niveau du langage, tu n'y peux malheureusement pas grand chose
Au niveau de ton code à toi / du code des applis que tu maintient, à toi de reworker le code pourri pour l'améliorer -- ce qui ne correspond pas forcément à un esprit SSII, mais est tout plus facilement envisageable dans d'autres contextes.

vince (./62) :
pour forcer le changement d'habitudes (genre le coup sur ereg il me semble), ils préfèrent "dupliquer" pour à terme rendre "obsolète" l'ancienne version...

Au niveau des ereg vs preg, la fonctionnalité n'est pas la même, la syntaxe des expressions rationnelles n'est pas la même non plus.
Les preg étant plus abouties, déprécier les ereg est la chose à faire, pour que les développeurs cessent peu à peu de les utiliser (utiliser des preg pour les nouveaux développements est la chose à faire, en l'occurence).
Ce mécanisme de "on déprécie dans la version N, et on supprimera dans la version N+1" est plutôt une bonne approche : ça laisse aux développeurs le temps de migrer doucement -- tout en ayant des avertissements sur ce qui est à revoir.