Discussion :

[Invité]

Et ce que tu vas potentiellement économiser en coût d'infrastructure (mois de ressource pour même résultat) tu vas le perdre presque x2 en coût homme.
Tu payes pas un expert C++ comme un expert PHP et aujourd’hui recruter des jeunes sur du C++ c'est difficile , parce que ça ne fait pas rêver grand monde et que, soyons honnete, c'est plus dur de faire du C++ ,

Oui enfin le C++ a beaucoup évolué également et aujourd'hui il permet de coder plus rapidement et plus efficacement. Et les frameworks web C++ aussi ont beaucoup évolué (il y en a même un qui fonctionne un peu comme PHP : http://www.tntnet.org). Et il n'y a pas que C++, Rust est peut-être une alternative intéressante.

En interprété t'es qd même censé testé ton code et ne pas avoir d'erreur d'exécution en prod . Ca arrive quand meme c'est vrai, tout comme une fuite mémoire en C++ , sauf que l'erreur d’exécution est bien plus facile à corriger qu'un fuite un peu pernicieuse.

Justement, la compilation fait certaines vérifications automatiquement ce qui évite certains tests. Et en C++ moderne, les fuites mémoire sont quand même beaucoup plus rares. Rust apporte également beaucoup sur ces points.

Rajoute à ca que mon équipe PHP peut travailler sous n'importe quel OS et que ma base de code peut fonctionner sous n'importe quelle OS sans devoir recompiler des lib ou parsemer mon code de #ifdef

Oui mais alors non. Déjà en backend, le code tournera sur un serveur, donc les problèmes de portabilité n'ont rien à voir avec ceux d'une appli desktop. Et compiler un projet C++ moderne, ça se résume généralement à un "apt install" ou "git clone --recursive" suivi d'un make. En PHP, il faut quand même installer un serveur web + son module PHP voire une interface fastcgi...

[rawsrc]

@archqt

Oh le gros troll en béquilles que voilà
Ce n'est pas parce que la technologie est interprétée qu'on doit se passer de la possibilité de typer ses variables.
Il y a quand même une gigantesque différence entre l'interprété et le compilé.

Facebook avait essayé d'avoir une partie de son site en version compilée et après moult essais a dû faire machine arrière, les contraintes étaient trop fortes pour du web (HipHop).
Ils se sont rabattus sur une autre approche HHVM qui est un compilateur JIT qui offre des possibilités d'optimisations que le compilé ne peut pas faire. Et du coup les perfs se sont drastiquement améliorées.

Le compilé n'est pas forcément le plus véloce dans tous les cas de figures.

[Invité]

un compilateur JIT qui offre des possibilités d'optimisations que le compilé ne peut pas faire
...
Le compilé n'est pas forcément le plus véloce dans tous les cas de figures.

Tu as des exemples ou explications qui montrent ça ?
Perso, j'utilise régulièrement les deux (compilation classique et JIT). Le JIT est généralement très satisfaisant mais je n'ai jamais observé de situation où il était signicativement plus véloce que le compilé.

[rawsrc]

Tu vas trouver quelques slides sur le net assez techniques, il y en a un interne à FB qui te montre quand le JIT a surpassé le compilé : https://hhvm.com/blog/875/wow-hhvm-i...nt-run-my-code. Après il faut je pense prendre le tout dans le sens : chaîne de traitement. Le gros avantage du JIT c'est que tu évites le temps de la compilation pur et dur et surtout tu gardes la possibilité de modifier ton code simplement.
Après j'avais lu, il y a un certain temps que quand FB avait lancé le projet en interne du compilateur HPHPc pour PHP (je crois vers 2008), FB générait déjà à l'époque pas loin de 400 milliards de pages PHP par mois.

Bref, toute l'infrastructure de FB a basculé sur l'approche JIT en arrêtant la compilation donc c'est qu'il y forcément un gros avantage.

[Invité]

"HipHop for PHP (HPHPc) is a discontinued PHP transpiler created by Facebook. By using HPHPc as a source-to-source compiler, PHP code is translated into C++, compiled into a binary and run as an executable." (https://en.wikipedia.org/wiki/HipHop_for_PHP).

Ah oui d'accord. Je pense qu'on ne parle pas du tout de la même chose alors. Pour moi, la compilation classique c'est de compiler un binaire une fois pour toute. Pas de transpiler PHP vers C++ puis compiler puis exécuter, le tout à chaque requête ou défaut de cache... Effectivement, je veux bien croire que le JIT soit plus performant dans ce cas.

[bouchery]

Désolé pour mon commentaire précédent, j'ai manqué de clarté dans ce que je voulais exprimer.

[Jonathan muswil]

Mais personne ne dit le contraire.
C'est juste que le typage strict permet d'être moins verbeux et de ne pas passer trop de temps à rajouter du code pour contrôler le type de données. Il y a aussi une forte notion de sécurité... et de pragmatisme.

[CoderInTheDark]

J'ai presque envi de refaire du PHP.
J'en ai plus fait depuis la version 5.5 et synfony 2

[Madmac]

Just'une question pour les fanatiques du typage fort? Cela vous arrive combien de fois, par année, d'envoyer le mauvais type à une fonction, pour de vrai ?

Je conçois que lorsque l'on apprend un langage, le type peut-être une béquille importante. Mais par la suite, ce typage devient plus un poids qu'une commodité.

[Sodium]

Ta question revient un peu à dire "vous vous crashez combien de fois par an en bagnole pour que ça justifie des limitations de vitesse ?"

Je vais d'ailleurs la retourner : si tu codes correctement, en quoi est-ce que le typage fort est un poids ?

Ca me rappelle l'époque où l'on débattait de s'il fallait conformer son code HTML aux règles W3C ou pas. Eh bien personnellement je ne me posais pas la question, je le rédigeais correctement instinctivement, donc par défaut il les respectait.

[Invité]

Just'une question pour les fanatiques du typage fort? Cela vous arrive combien de fois, par année, d'envoyer le mauvais type à une fonction, pour de vrai ?

Sur du code en cours de développement, plusieurs fois par jour. En fait, à peu près autant que des tests unitaires qui échouent. Mais tu vas peut-être nous dire que ça aussi c'est inutile...

[Pyramidev]

Just'une question pour les fanatiques du typage fort? Cela vous arrive combien de fois, par année, d'envoyer le mauvais type à une fonction, pour de vrai ?

Je conçois que lorsque l'on apprend un langage, le type peut-être une béquille importante. Mais par la suite, ce typage devient plus un poids qu'une commodité.

L'un des plus gros avantages du typage statique est que c'est une sorte de documentation pour laquelle on a la garantie qu'elle est à jour. Par exemple, quand on s'apprête à modifier le code d'une fonction existante, on a souvent envie de savoir quelles sont les opérations disponibles pour ce qui est passé en paramètre. Pour le savoir, c'est beaucoup plus rapide quand on a un contrôle sur le type que quand on doit chercher récursivement dans le code appelant pour savoir quels sont les types concrets possibles.

Le typage statique sert dès la lecture du code, pas seulement quand on fait une étourderie en modifiant le code qui aurait été probablement détectée indirectement plus tard en lançant les tests unitaires.

Remarque importante : en début de vie d'un logiciel, celui qui a écrit le code from scratch ne sera pas forcément très gêné par une absence de typage, car il connaît déjà bien le code appelant, puisque c'est lui qui l'a écrit. Mais, des années plus tard, quand le code aura bien grossi, les malheureux qui reprendront ce code n'auront pas le luxe d'étudier ce code tout entier avant de commencer à le modifier. À ce moment, sans typage, le code sera chiant à maintenir.

[psykokarl]

Just'une question pour les fanatiques du typage fort? Cela vous arrive combien de fois, par année, d'envoyer le mauvais type à une fonction, pour de vrai ?

Je conçois que lorsque l'on apprend un langage, le type peut-être une béquille importante. Mais par la suite, ce typage devient plus un poids qu'une commodité.

En PHP, envoyer le mauvais type a une fonction ? Tout le temps !
La conversion implicite de type fait que l'on ne s'en rend pas compte. Ca peut poser des problèmes aux profils juniors peu au fait des subtilités du langage lorsque le type reçu n'est pas celui attendu.

Le typage fort n'est pas forcément un poids. On pourrait imaginer, dans un contexte d'avantage "PHP", qu'un typage plus fort soit l'occasion de transtyper implicitement ce qui est passe en parametre permettant du même coup de se moquer de la provenance de la donné. Ou le cast est possible et il se fait automatiquement ou il ne l'est pas et il y a génération d'exception. Si on n'y ajoute la possibilité de se créer des types complexes respectant des expressions regulières ou des limites de valeurs on allège significativement les tests de sorte qu'il n'y a plus qu'a se concentrer sur le fonctionnel.

[Invité]

Le typage fort n'est pas forcément un poids.

D'ailleurs dans certains langages, typés fortement et statiquement, le compilateur calcule les types presque automatiquement, sans que le développeur ait besoin de les écrire.

Ou le cast est possible et il se fait automatiquement ou il ne l'est pas et il y a génération d'exception.

Perso, je trouve que le cast automatique n'est pas du tout une bonne idée car c'est une source d'erreurs ou de perte de performances.

Si on n'y ajoute la possibilité de se créer des types complexes respectant des expressions regulières ou des limites de valeurs on allège significativement les tests de sorte qu'il n'y a plus qu'a se concentrer sur le fonctionnel.

Oui, ce serait une fonctionnalité intéressante. Ada le fait, je crois, mais c'est assez rare sinon. Par contre, ça doit changer pas mal de chose niveau compilateur/interpréteur et dans la façon de coder...

[psykokarl]

Perso, je trouve que le cast automatique n'est pas du tout une bonne idée car c'est une source d'erreurs ou de perte de performances.

Pour le coup je pensais à un cast implicite déterminé par un le typage d'un parametre de fonction par exemple. Une chaine de caractere passé en parametre d'une fonction qui attend un entier sera automatiquement convertie en entier si cela est possible. Ca equivaut de fait a un cast explicite. Enfin, je disais surtout cela pour montrer que mettre un typage plus fort n'est pas forcément un poids selon la façon dont c'est mis en place. Sinon je suis d'accord que le cast automatique est source de pas mal d'erreurs.

Pour ce qui est des pertes de performances, je repondrais que PHP doit rester d'être un langage simple a utiliser. C'est ce qui a fait sa force. Je pense que le nerf de la guerre est d'avantage de rendre le langage plus cohérent, ce qui le rendrais plus facile a apprendre et permettrait de convevoir un meilleur interpreteur/compilateur derrière plus à même d'optimiser derrière. Il y a des langages plus cohérent mais plus complexe de PHP. Si PHP gagne en complexité sans gagner en cohérence, il serait logique qu'il se voit détrôner ...

[Aizen64]

Mon avis est qu’il faudrait repartir de zéro pour avoir un langage propre.

Mettre un dollar devant chaque variable c’est juste relou en fait, la comparaison de type est «*funky*», 0 == null ou 0 == «chaîne*» aussi, l’iterateur d’un foreach accessible après une boucle et vaut la dernière valeur intérée, le nommage bordélique des fonctions standards, pas qui renvoient false au lieu de renvoyer une exception (putain diagnostiquer des erreurs dans la création de fichiers est barbant (marche dans tmp mais pas var/tmp avec des permissions en 777...), json_encode qui stocke tout en même et donc peut causer facilement des dépassements de mémoire et pas d’exception générée.

Les perfs de PHP avec un framework sans activer le cache PHP c’est juste une horreur, même Ruby on Rails va plus vite car il stocke des choses en mémoire.

A côté de ça PHP peut aussi être très pratique, des modifs de vue ne redemande pas de recharger l’appli, c’est à la volée, mettre à jour du code backend est aussi simple qu’un git pull qui dure 3 secondes au pire et inutile de redémarrer le serveur. PDO qui renvoie false au lieu d’une erreur est aussi pratique et au pire la donnée ne s’affiche pas mais l’appli ne casse pas.

Donc ça reste un langage laid, verbeux mais assez résilient et souple à condition de connaître les faiblesses de l’éléphant.

A titre d’exemple, le projet pro que je maintient et dont le suis le créateur est bourré de défauts avec un micro ORM fait à la main qui utilise PDO, un mauvais découpage de code (trop couplé à la BDD, des services qui correspondent à la logique métier qui n’est pas bien découpé) et pourtant, ça tourne avec une disponibilité >99% en lecture depuis quasiment 2 ans car connecté direct à une BDD puis des Webservices synchrones (et lents) pour l’écriture.

Résultat : pas de problématique de sync, pas d’architecture complexe et ça tourne avec 0 intervention humaine.