Franchement, la plupart de ton journal n'est pas contre le code moderne, juste contre la façon de programmer majoritaire des utilisateur d'un seul langage, crade.
Je passerai outre les 90% de ton journal qui parlent de PHP et de quelques framework spécifiques.
Quand je lis ça:
au prix d'artifices plus ou moins alambiqués (genre certains design-patterns, les namespaces, les traits, etc.).
Alors... les design pattern, je vais devoir t'expliquer ce que c'est on dirait. Ce sont juste des noms et un peu d'explications mis sur des construction, que ce soit d'implémentation ou d'architecture, souvent utilisés. Entres autres pour éviter que quelqu'un ne les utilise à mauvais escient ou pour faciliter la communication (éviter de sortir un diagramme de classes pour parler d'une construction classique, ça fait gagner du temps dans les échanges)...
Personnellement, quand j'ai découvert leur existence, je me suis aperçu qu'il y en à 2-3 que j'utilisais déjà depuis longtemps, inconsciemment.
Les traits, j'ai lu dans un de tes messages que tu crois que c'est pour remplacer l'héritage multiple, ou les interfaces. Faux. C++ supporte depuis toujours l'héritage multiple. Sauf que l'héritage, ça à un coût au runtime (principalement à cause des méthodes virtuelles, il faut bien le dire), et quand tu le mêles à de la généricité, ça devient infernal de pas avoir de problèmes de compilation.
Bien sûr, je parle de langage natif, mais, tu as parlé de code moderne, ce n'est pas limité au seul web et encore moins au seul PHP.
Bref, les traits, ça permets, sans surcoût de performance (dans un langage compilé, hein) de pouvoir certifier à l'utilisateur (de la classe) que certaines conditions sont remplies. Ça simplifie potentiellement à la fois l'écriture du code, la documentation du code, et les messages d'erreur de la compilation (en tant que dev C++, je peux t'assurer que j'ai acquis un certain niveau en GNU-vaudou... ceci dit je préfère les incantations de clang, elles sont moins trash!).
Les namespace, c'est aussi très utile. Je suis en train de me bricoler une classe pour encapsuler les sockets BSD. Et tu sais quoi? Grâce à eux, je n'ai pas eu besoin de me casser la tête pour les noms de classe et de fonctions: j'ai utilisé socket et poll, en sachant que, grâce au namespace, je n'aurai pas de conflits de noms (évitable pour les fonction grâce au fait qu'en C++ le prototype inclue les types, mais pas pour les classes/structs).
Et c'est tellement plus lisible de pouvoir faire sdl::CreateSurface que de devoir se farcir des SDL_CreateSurface. Pourquoi? Parce que moyennant un import de l'espace de nom sdl, on peut juste appeler CreateSurface.
Bref, je suis en complet désaccord avec toi pour ce qui est du code moderne.
Maintenant... Comme toi, j'ai du mal avec les framework. Je leur préfère des collections de bibliothèques indépendantes, qui répondent très précisément à mon besoin. Et quand il faut mettre à jour ou changer (parce qu'il faut porter le projet à un autre système, par exemple) une bibliothèque, la part du code à mettre à jour est plus restreinte.
Évidemment, ça à les inconvénients de ses qualités: il faut prendre le temps de chercher les libs adaptées, et espérer ne pas se planter, parce que tu n'as pas l'éternité devant toi pour choisir ces libs: le but n'est pas de choisir des libs, mais de coder, pas vrai?
Donc, je comprend les utilisateurs de framework, même si je suis en désaccord avec eux.
Ensuite... ce n'est pas parce que certains framework sont mal branlés, buggués, mal architecturés, etc, que c'est le cas de tous, ou qu'aucune lib plus petite n'est pas affectée par ces problèmes.
Enfin... conclusion:
Change de langage. Non, mais sérieux... tu dis dans un post que tu gardes PHP pour faciliter la vie des débutants? Bah justement, arrêtes d'enrichir l'éco-système d'un langage si décrié, adoptes un langage plus propre (je suis sûr qu'il y en a. Peut-être python, ruby? J'en sais rien, honnêtement.) et arrêtes de basher le code moderne alors que tu parles en fait d'une fraction de ses utilisateurs, qui utilisent un langage qui n'à jamais eu pour vocation d'être un langage.
Je cite wikipedia: «Le langage PHP fut créé en 1994 par Rasmus Lerdorf pour son site web. C'était à l'origine une bibliothèque logicielle en C»...
Si tu savais ce que je pense du C... c'est l'anti-thèse de la modernité, un langage qui rend complexe l'écriture de code sécurisé et maintenable. Je ne le considère pertinent que pour de la maintenance d'applications historiques écrites en C (et encore) et l'embarqué où l'on doit avoir un contrôle total sur la taille du binaire et son empreinte mémoire (encore que, je pense qu'un subset de C++ permets d'améliorer les choses par rapport au C tout en ayant les mêmes tailles/empreintes).
Liste quasi-complète de ce que je lui reproche:
type safety très faible,
gestion de la mémoire complètement manuelle: ni RAII, ni GC, ni conteneurs standard (que ce soit pour les choses dynamiques ou statiques, hein),
obligation de copier/coller le code quand juste le type change cf abs(int), labs(long int), llabs(long long int),
macros qu'il ne faut jamais utiliser parce que quand ça pète, tu en as pour quelques heures pour trouver d'où ça peut bien venir.
On reproche souvent au C++ ses exceptions, sa RTTI, mais ces gens là oublient systématiquement de préciser, que l'on est jamais obligé d'utiliser la STL (je n'ai pas trouvé en moins de 2minutes de façon d'utiliser std::vector en mode nothrow. Je pense que ça existe ceci dit, ou que ça ne devrait pas être trop complexe de spécialiser vector pour utiliser nothrow) et que pour l'allocation de classes new/delete sont incomparablement supérieurs à malloc/calloc/free, parce qu'on peut choisir de l'utiliser avec ou sans exceptions.
Bref, vive le code moderne, à bas les langages pré-historiques, et laissez les gens choisir s'ils veulent ou non utiliser des framework.
Ah, et surtout: à bas les bâcleurs de code, même si je pardonne ceux qui n'ont pas le choix parce que leur chef le leur impose!
# C'est pas le code moderne que tu n'aimes pas, c'est le PHP moderne...
Posté par freem . En réponse au journal Je n'aime pas le code moderne. Évalué à 10.
Franchement, la plupart de ton journal n'est pas contre le code moderne, juste contre la façon de programmer majoritaire des utilisateur d'un seul langage, crade.
Je passerai outre les 90% de ton journal qui parlent de PHP et de quelques framework spécifiques.
Quand je lis ça:
Alors... les design pattern, je vais devoir t'expliquer ce que c'est on dirait. Ce sont juste des noms et un peu d'explications mis sur des construction, que ce soit d'implémentation ou d'architecture, souvent utilisés. Entres autres pour éviter que quelqu'un ne les utilise à mauvais escient ou pour faciliter la communication (éviter de sortir un diagramme de classes pour parler d'une construction classique, ça fait gagner du temps dans les échanges)...
Personnellement, quand j'ai découvert leur existence, je me suis aperçu qu'il y en à 2-3 que j'utilisais déjà depuis longtemps, inconsciemment.
Les traits, j'ai lu dans un de tes messages que tu crois que c'est pour remplacer l'héritage multiple, ou les interfaces. Faux. C++ supporte depuis toujours l'héritage multiple. Sauf que l'héritage, ça à un coût au runtime (principalement à cause des méthodes virtuelles, il faut bien le dire), et quand tu le mêles à de la généricité, ça devient infernal de pas avoir de problèmes de compilation.
Bien sûr, je parle de langage natif, mais, tu as parlé de code moderne, ce n'est pas limité au seul web et encore moins au seul PHP.
Bref, les traits, ça permets, sans surcoût de performance (dans un langage compilé, hein) de pouvoir certifier à l'utilisateur (de la classe) que certaines conditions sont remplies. Ça simplifie potentiellement à la fois l'écriture du code, la documentation du code, et les messages d'erreur de la compilation (en tant que dev C++, je peux t'assurer que j'ai acquis un certain niveau en GNU-vaudou... ceci dit je préfère les incantations de clang, elles sont moins trash!).
Les namespace, c'est aussi très utile. Je suis en train de me bricoler une classe pour encapsuler les sockets BSD. Et tu sais quoi? Grâce à eux, je n'ai pas eu besoin de me casser la tête pour les noms de classe et de fonctions: j'ai utilisé socket et poll, en sachant que, grâce au namespace, je n'aurai pas de conflits de noms (évitable pour les fonction grâce au fait qu'en C++ le prototype inclue les types, mais pas pour les classes/structs).
Et c'est tellement plus lisible de pouvoir faire sdl::CreateSurface que de devoir se farcir des SDL_CreateSurface. Pourquoi? Parce que moyennant un import de l'espace de nom sdl, on peut juste appeler CreateSurface.
Bref, je suis en complet désaccord avec toi pour ce qui est du code moderne.
Maintenant... Comme toi, j'ai du mal avec les framework. Je leur préfère des collections de bibliothèques indépendantes, qui répondent très précisément à mon besoin. Et quand il faut mettre à jour ou changer (parce qu'il faut porter le projet à un autre système, par exemple) une bibliothèque, la part du code à mettre à jour est plus restreinte.
Évidemment, ça à les inconvénients de ses qualités: il faut prendre le temps de chercher les libs adaptées, et espérer ne pas se planter, parce que tu n'as pas l'éternité devant toi pour choisir ces libs: le but n'est pas de choisir des libs, mais de coder, pas vrai?
Donc, je comprend les utilisateurs de framework, même si je suis en désaccord avec eux.
Ensuite... ce n'est pas parce que certains framework sont mal branlés, buggués, mal architecturés, etc, que c'est le cas de tous, ou qu'aucune lib plus petite n'est pas affectée par ces problèmes.
Enfin... conclusion:
Change de langage. Non, mais sérieux... tu dis dans un post que tu gardes PHP pour faciliter la vie des débutants? Bah justement, arrêtes d'enrichir l'éco-système d'un langage si décrié, adoptes un langage plus propre (je suis sûr qu'il y en a. Peut-être python, ruby? J'en sais rien, honnêtement.) et arrêtes de basher le code moderne alors que tu parles en fait d'une fraction de ses utilisateurs, qui utilisent un langage qui n'à jamais eu pour vocation d'être un langage.
Je cite wikipedia: «Le langage PHP fut créé en 1994 par Rasmus Lerdorf pour son site web. C'était à l'origine une bibliothèque logicielle en C»...
Si tu savais ce que je pense du C... c'est l'anti-thèse de la modernité, un langage qui rend complexe l'écriture de code sécurisé et maintenable. Je ne le considère pertinent que pour de la maintenance d'applications historiques écrites en C (et encore) et l'embarqué où l'on doit avoir un contrôle total sur la taille du binaire et son empreinte mémoire (encore que, je pense qu'un subset de C++ permets d'améliorer les choses par rapport au C tout en ayant les mêmes tailles/empreintes).
Liste quasi-complète de ce que je lui reproche:
On reproche souvent au C++ ses exceptions, sa RTTI, mais ces gens là oublient systématiquement de préciser, que l'on est jamais obligé d'utiliser la STL (je n'ai pas trouvé en moins de 2minutes de façon d'utiliser std::vector en mode nothrow. Je pense que ça existe ceci dit, ou que ça ne devrait pas être trop complexe de spécialiser vector pour utiliser nothrow) et que pour l'allocation de classes new/delete sont incomparablement supérieurs à malloc/calloc/free, parce qu'on peut choisir de l'utiliser avec ou sans exceptions.
Bref, vive le code moderne, à bas les langages pré-historiques, et laissez les gens choisir s'ils veulent ou non utiliser des framework.
Ah, et surtout: à bas les bâcleurs de code, même si je pardonne ceux qui n'ont pas le choix parce que leur chef le leur impose!