IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage PHP Discussion :

Un développeur de PHP propose un langage fortement typé, le P++, avec des fonctionnalités plus avancées


Sujet :

Langage PHP

  1. #41
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    1 210
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 1 210
    Points : 5 149
    Points
    5 149
    Par défaut
    Citation Envoyé par Madmac Voir le message
    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.

  2. #42
    Membre confirmé
    Profil pro
    Inscrit en
    mars 2011
    Messages
    229
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2011
    Messages : 229
    Points : 602
    Points
    602
    Par défaut
    Citation Envoyé par Madmac Voir le message
    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.

  3. #43
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par psykokarl Voir le message
    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.

    Citation Envoyé par psykokarl Voir le message
    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.

    Citation Envoyé par psykokarl Voir le message
    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...

  4. #44
    Membre confirmé
    Profil pro
    Inscrit en
    mars 2011
    Messages
    229
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2011
    Messages : 229
    Points : 602
    Points
    602
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    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 ...

  5. #45
    Membre confirmé Avatar de Aizen64
    Profil pro
    Inscrit en
    mai 2007
    Messages
    556
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2007
    Messages : 556
    Points : 453
    Points
    453
    Par défaut
    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.
    Exprimer une différence d'opinion vaut mieux que :

Discussions similaires

  1. Les outils vraiment utiles pour les développeurs PHP
    Par RideKick dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 5
    Dernier message: 14/06/2017, 18h10
  2. Les classes et librairies vraiment utiles pour les développeurs PHP
    Par RideKick dans le forum Bibliothèques et frameworks
    Réponses: 4
    Dernier message: 05/10/2010, 10h51
  3. Les développeurs PHP préfèrent les bureaux Windows aux bureaux Linux
    Par RideKick dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 42
    Dernier message: 25/02/2010, 02h15
  4. Réponses: 0
    Dernier message: 19/02/2010, 08h21
  5. Intel annonce l'arrivée d'un Atom App Store pour les développeurs
    Par Katleen Erna dans le forum Actualités
    Réponses: 0
    Dernier message: 08/12/2009, 05h07

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo