Sommaire
Cher journal,
Avant propos
Développeur PHP depuis près de dix ans, internaute depuis quinze et geek depuis vingt-cinq, comme tout bon geek, je fais de la veille. Je m'intéresse aux nouveautés, j'étudie scrupuleusement les spécifications des langages que j'utilise (soit PHP, Javascript, CSS et HTML), en bref, je me tiens au courant et j'applique les recommandations les plus récentes.
C'était mieux avant
J'adorais Internet. Je l'aime toujours, mais moins qu'avant. "Avant" ? Avant l'avènement des réseaux sociaux.
Similairement, bien que j'aime toujours coder, j'aime le code moins qu'avant. "Avant" ? Avant l'avènement des frameworks usines-à-gaz qui ne respectent même pas les principes élémentaires de codage ou du modèle MVC (du code logique dans des commentaires ? du code brut dans les templates ?).
Mon framework à moi !
Je travaille depuis quelques temps sur un framework maison, composé d'un loader du même genre que celui de CakePHP mais en plus lisible (CoreLoader::load_vendor('phpmailer') ou CoreLoader::load_controller('home') par exemple), d'un routeur particulièrement complet (prenant en charge des routes automatiques, les droits des utilisateurs en fonction de la route demandée, etc.), de templates, etc.
Bien que j'ai codé moi-même le gros du framework, l'idée reste qu'il s'agisse d'une agrégation des meilleures librairies dans leur domaine respectif:
Changement de cap
La philosophie du Libre
Hier, j'ai eu une épiphanie:
"Hey, coder toi-même ce qui existe déjà ? Pas trop la philosophie du Libre !"
Ok. Ça implique - apparemment - d'utiliser des trucs tout moches modernes du genre composer. Bon, allez, je m'y colle.
Je cherche un peu une librairie pour remplacer mon routeur, et je tombe sur un certain nombre d'entre elles:
Et puis tiens, PHP-Error pourrait être pas mal.
La déconvenue
Oh ! Il y a un éditeur intégré pour modifier le code en direct quand une erreur se présente ! Cool ! Oh, ça m'enregistre un fichier presque vide quand il y a un antislash dans un namespace ! Bon, ben encore une application moderne qui mise sur l'apparence et qui en fait est tout bugguée…
Mon application de test n'est pas à la racine. Aucun problème pour mon routeur, mais klein ne fonctionne pas sans .htaccess pour le rewrite, Aura est beaucoup trop gros et aucun des trois ne matche mes routes sur la variable PATH_INFO mais sur le chemin relatif depuis DOCUMENT_ROOT. Bizarre…
Cause et effet
De façon assez étrange, ni Smarty, ni Redbean ne mentionnent composer dans leur documentation, et PHPMailer s'en passe parfaitement. D'ailleurs, j'aime beaucoup la raison avouée pour laquelle l'auteur de Redbean ne propose pas de package composer. Certe, les trois peuvent s'installer via le gestionnaire de dépendances, mais de manière plus ou moins officieuse.
Personnellement, j'ai bien envie de tomber dans la facilité et voir un lien entre la qualité des librairies, le fait que composer soit obligatoire ou non pour les installer, et la vétusté/simplicité de leur site Internet.
J'ai testé pas mal d'autres librairies encore et je constate une chose: une grosse partie a une page web créée avec Bootstrap. Encore des clones de bootstrap… Certains mieux réalisés que d'autres toutefois, mais on sent toujours cette patte bootstrap, c'en est désespérant. Ni Redbean, ni Smarty n'utilisent bootstrap sur leur site.
Là encore, j'ai envie de tomber dans la facilité: comment avoir confiance dans une librairie dont l'auteur ne prend pas la peine de faire un site sans tomber dans le piège oisif de bootstrap, ou du moins, faire en sorte que ça ne se voit pas ?
Du coup, je ne comprends pas comment il est possible que de telles librairies ou outils puissent avoir une telle cote de popularité.
Le mal-aimé
En parlant de popularité, autre exemple: PEAR.
PEAR existait avant composer. Avoir sa librairie disponible sur PEAR était, à une époque, la quintessence, l'aboutissement, une reconnaissance extrême. Bien sûr, PEAR est un framework alors que composer est un gestionnaire de dépendances, mais tout de même. Aujourd'hui, tout le monde boude PEAR, à part Horde et quelques irréductible de ce que j'appelle l'artisanat du web, vestige d'une époque où le code devait être bien écrit, quasiment exempt de bugs, et fonctionner partout sans la moindre nécessité d'adaptation. Il semblerait qu'on ait perdu cette versatilité au prix d'artifices plus ou moins alambiqués (genre certains design-patterns, les namespaces, les traits, etc.).
Interopérable ?
Le pire, c'est que toutes ces libs modernes suivent les recommandations PSR, donc devraient être facilement utilisables partout quelle que soit la configuration du serveur sur lequel elles sont installées.
D'ailleurs, je crois que les "standards" recommandés par le PHP-FIG ne servent qu'à composer. Il y a évidemment quelques bonnes idées dedans (UTF-8 sans BOM, LoggerInterface, etc.) qui contribuent effectivement et efficacement à l'interopérabilité des librairies PHP, mais désormais, je fuirai les librairies arborant fièrement avoir suivi ces recommandations parce que cela signifie qu'il va être pratiquement impossible de les utiliser sans composer (qui a, par ailleurs, la fâcheuse tendance à installer tout un tas de truc que je n'ai jamais demandé et qui n'existe pas dans les archives).
On n'est jamais mieux servis que par soi-même
Au final, je vais faire ce que j'ai toujours fais: continuer de tester des librairies, et intégrer à mon framework les meilleures d'entre elles, les plus simples à installer et utiliser, même si elles devaient être quelque peu obsolètes (simplepie par exemple).
Pour ceux que ça intéresse, voici les différentes librairies que j'utilise, outre Redbean, PHPMailer et Smarty (sans composer et sans les avoir modifier de quelque manière que ce soit):
- Munee - concaténation et minification à la volée de CSS et JS avec support de less, scss, coffescript, etc.
- Parsedown - parser markdown
- phpass - génération de hash sécurisés pour les mots de passe, en l'absence de blowfish
Happy end, quand même
Je note tout de même que cette expérience m'a tout de même apporté de bonnes surprises, comme monolog, sentry ou climate que j'intégrerai peut être à mon framework, malgré l'utilisation "nécessaire" de composer et leur usage abusif des namespaces…
Ou bien je coderai mes propres libs, les distribuerai sous licence Libre, hors composer, en mentionnant que j'ai une approche plus conservatrice du dév…
# Mieux avant, vraiment?
Posté par Kalenx . Évalué à 10.
Je suis toujours un peu dubitatif face aux gens qui regrettent le "bon vieux temps". Des frameworks lourdingues et mal conçus, ça ne date pas d'hier (bonjour PHP-Nuke!), et des développeurs qui se fichent de la qualité de leur code également.
Au contraire, le web en 2000-2001, c'était l'asile :
Où est le problème avec le fait que les gens utilisent des frameworks, si ça marche bien justement? Je connais assez mal le PHP, mais en javascript (jQuery et consort côté client, node.js côté serveur) et en Python (Django, Pyramid, etc.), je serais bien en peine de me passer de ces frameworks.
Bien sûr il y a parfois de l'exagération, des usines à gaz utilisées pour le livre d'or de l'association de bowling cosmique des trombonistes unijambistes de Provence, mais de manière générale, ces frameworks ont au contraire apporté une bien meilleure qualité de code que ce que pourraient faire bien des développeurs (et en bien plus de temps).
Bon, après, je ne connais pas particulièrement composer—et je n'aime pas particulièrement PHP—mais je persiste à trouver l'amalgame "des gens codent mal" -> "c'était mieux avant" un peu bancal…
[^] # Re: Mieux avant, vraiment?
Posté par totof2000 . Évalué à 6.
A mon avis, le problème n'est pas d'utiliser les frameworks, mais d'utiliser un framework lorsque ce n'est pas adapté, ou de ne pas utiliser le bon framework pour le bon usage. Personnellement je constate que beaucoup de projets utilisent des frameworks "usine à gaz" parce que les devs ne connaissent pas autre chose, alors que le framework n'est pas vraimentr nécessaire (ou alors un outil plus light suffirait).
[^] # Re: Mieux avant, vraiment?
Posté par reynum (site web personnel) . Évalué à 10.
Où est le lien je veux voir ça :-D
kentoc'h mervel eget bezan saotred
[^] # Re: Mieux avant, vraiment?
Posté par mazarini . Évalué à 3.
Ah PHPNUKE qui m'a permis d'apprendre le PHP et découvrir la GPL même si Francisco Burzi semblait programmer avec ses pieds et était laxiste avec la GPL en oubliant Thatware qui l'avait largement inspiré.
Content de voir que certains se souviennent encore de ce fabuleux (à l'époque) CMS.
Moi qu'en suis resté là niveau PHP, mes premier pas avec Magento et Symfony ont été douloureux.
# d'autres priorités?
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 15 janvier 2015 à 08:26.
Parce que le sujet est sa lib, pas un site web "différent", et qu'il préfère passer du temps sur sa lib que sur un site web "différent"?
Pas compris : l'auteur upstream refuse de mettre un fichier en plus dans son archive par conservatisme? (je vois qu'un fichier JSON sur le patch composer).
C'était mieux avant.
[^] # Re: d'autres priorités?
Posté par barmic . Évalué à 4.
:) tu parle en connaissance de cause (tu as eu beaucoup de critique sur ton site si je ne me trompe pas ?)
Mais je suis d'accord surtout qu'un peu avant il dit :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: d'autres priorités?
Posté par Renault (site web personnel) . Évalué à 3.
Il y a eu une belle refonte ces derniers mois j’ai l'impression, la navigation me paraît agréable pour moi maintenant ce qui est sympa (contrairement à l'ancienne version).
[^] # Re: d'autres priorités?
Posté par barmic . Évalué à 3.
D'où l'utilisation du passé composé
^^Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# mocheté
Posté par Adrien . Évalué à 8.
Tu parles de « mocheté », est-ce l'aspect esthétique des sites web, ou le côté technique ?
Parce que niveau esthétique on a quand même fait un bond en avant depuis ça :
http://jvachez.free.fr/
[^] # Re: mocheté
Posté par Richard Dern . Évalué à -4.
Ce que je critique c'est que le web est inondé de sites dont le front-end repose sur bootstrap peu ou prou modifié, et qu'il y en a marre de voir des clones de bootstrap partout.
Je ne dis pas qu'il faut faire un site ultra beau et abouti pour présenter une librairie (justement, je dis bien que le site de Smarty est vétuste et celui de Redbean est simple et sobre). Je dis que quand on est un dev web et qu'on fait du Libre, on pourrait se creuser un peu la soupière pour faire quelque chose qui ne repose pas sur Bootstrap.
Utiliser Foundation par exemple, ça changerait un peu…
[^] # Re: mocheté
Posté par Zenitram (site web personnel) . Évalué à 10.
Ne pas utiliser un outil parce que les autres utilisent, quel argument pertinent.
Sinon : programmeur web != designer web.
[^] # Re: mocheté
Posté par Faya . Évalué à 9.
Je suis développeur, pas graphiste. Les sites beaux je sais pas faire ça tout seul. Donc si je code une lib et qu'elle a besoin d'un site, ça risque fort d'être du bootstrap. Parce que je ne veux pas faire
comme tu le dis si bien à propos de PHP-Error.
Enfin bref tu te contredis et mélanges un peu tout (les traits c'est alambiqué, bootstrap c'est mal, composer c'est le diable) juste pour nous dire que tu n'as pas envie d'évoluer et d'apprendre de nouvelles technos.
Je te rejoins néanmoins sur une chose : je n'aime pas les gros framework qui font tout même le café à la symfonie donc ouais je fais comme toi, j'assemble des libs intéressantes. Et pour ça composer est bien pratique.
[^] # Re: mocheté
Posté par Richard Dern . Évalué à 1.
Et tu ne lis pas les posts en entier :)
Pardon, je ne vois pas où je me contredis…
Oui, je parle du code moderne, donc ça englobe un certain nombre de choses…
J'utilise bootstrap dans mes projets persos non diffusés, j'utilise CakePHP dans les devs pro, j'utilise foundation dans certains projets, ink (du même auteur) pour les mails HTML. Qui a dit que je ne voulais pas évoluer ou apprendre de nouvelles technos ?
Je ne suis simplement pas prêt à accepter la modernité juste pour dire que j'utilise quelque chose de moderne.
Par ailleurs, quand ces outils modernes fonctionnent, je les utilise avec plaisir. Par contre, je ne suis pas d'accord avec l'obligation d'utiliser un outil moderne pour utiliser des librairies bancales.
[^] # Re: mocheté
Posté par Faya . Évalué à 3. Dernière modification le 15 janvier 2015 à 13:35.
"encore une application moderne qui mise sur l'apparence" et "comment avoir confiance dans une librairie dont l'auteur ne prend pas la peine de faire un site sans tomber dans le piège oisif de bootstrap" c'est contradictoire.
Alors fais toi plaisir : les traits, les namespaces, Composer, ne sont pas bancals ou alors je veux bien que tu m'expliques en quoi.
EDIT : je connais la rengaine "ouais vous les utilisez juste parce que c'est à la mode". Ou alors ça a facilité la vie de beaucoup et de fait c'est devenu "à la mode". Parce que ça marche. Parce que c'est pratique. Tout à fait comme le PHP il y a 10 ans d'ailleurs.
[^] # Re: mocheté
Posté par Richard Dern . Évalué à 1.
Vraiment, j'essaye de comprendre, mais je ne vois toujours pas en quoi c'est contradictoire.
Les traits sont un paliatif au fait que PHP ne supporte pas l'héritage multiple. Je trouve leur syntaxe confuse:
Premièrement, jusqu'à présent, le mot-clé use n'était utilisé que pour importer une variable dans une closure. Là on a le sentiment d'importer une classe dans une autre, ce qui n'est pas exact. Je pense qu'il aurait été plus harmonieux de faire quelque chose du genre:
Pour les namespaces, là aussi c'est la syntaxe qui me pose problème. L'antislash n'est pas un bon séparateur selon moi, le slash aurait été plus approprié, plus logique.
Enfin pour composer, j'ai expliqué en quoi il est bancal dans un autre commentaire de ce topic.
[^] # Re: mocheté
Posté par Faya . Évalué à 4.
Dans le premier cas tu juges l'application sur le fait que le maximum soit mis sur l'apparence du site web, dans le deuxième cas tu juges l'application sur le fait que le maximum ne soit pas mis sur l'apparence du site web (piège oisif).
Si c'est la syntaxe des traits et des namespaces qui te pose problème tu devrais vite changer de langage ! Parce que les incohérences de syntaxe dans PHP sont légions
[^] # Re: mocheté
Posté par Richard Dern . Évalué à 1.
Non, ce que je voulais dire c'est qu'on peut faire un site vite fait bien fait sans bootstrap :)
Un normalizer pour la compatiblité, deux trois classes pour les liens ou les menus et voilà, pas besoin de pondre du less pour une page de présentation de la lib.
Oui, ça, je suis parfaitement d'accord. Les incohérences sont nombreuses et la dev team de PHP n'est pas encline à les corriger.
Je lorgne de plus en plus du côté de Python. Si je ne m'y suis pas encore mis, c'est parce que je veux concevoir des applications Libres que le débutant peut installer facilement. Je me disais qu'une appli PHP était plus simple à installer qu'une appli Python (en terme de paramétrage de serveur web notamment).
Mais vu que je passe beaucoup de temps à coder et que je n'ai pas publié grand chose, j'aurais peut être pu passer ce temps à étudier Python plutôt que m'énerver contre la "mauvaise" modernisation de PHP :)
[^] # Re: mocheté
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
<Ironie>Ouuuuh là!! Attention, tu va être TRÈS décu. en effet, beaucoup de lib et d'applis s'installe avec PIP, qui est très similaire à Composer. Tu ne vas pas pouvoir faire totalement du dev à contre courant de ce que l'écosystème propose :-p</Ironie>[^] # Re: mocheté
Posté par Richard Dern . Évalué à 2.
Je précise quand même que certains points soulevés par PHPSadness sont franchement tirés par les cheveux:
Je suis d'accord sur les inconsistances des noms de fonctions par exemple, mais le reste il faut avouer que c'est du bashing :)
[^] # Re: mocheté
Posté par Faya . Évalué à 2.
Tout à fait il y a clairement du bashing sur ce site. Et oui les incohérences sont bien présentes ce qui ne t'empêche pas d'utiliser les fonctions …
[^] # Re: mocheté
Posté par Anthony Jaguenaud . Évalué à 4.
Ben, ça dépend, si tu dois couper une chaine en deux, et que avoir deux chaines vide en résultat n’est pas gênant. Je préfère couper la chaine en deux systématiquement. Ça simplifie le code (pas de branche multiple…) et il n’y a pas de perte de performance notable.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mocheté
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
Non les traits n'est pas un paliatif. Ça n'a d'ailleurs rien à voir avec l'héritage multiple, et ça ne cherche pas à remplacer l'héritage multiple (qui pose lui même bien des problèmes dans d'autres langages).
Et il n'y a pas que PHP qui supporte les traits, il y a d'autres langages comme le tout nouveau Rust.
[^] # Re: mocheté
Posté par Richard Dern . Évalué à 2.
Source: http://php.net/manual/en/language.oop5.traits.php
L'objectif reste bien d'utiliser les méthodes d'une classe dans une autre, donc quelque part faire de l'héritage. Non ?
[^] # Re: mocheté
Posté par Thomas Douillard . Évalué à 5.
Où il est écrit que l'héritage est une bonne manière de réutiliser du code ? Et surtout, la seule.
C'est pas parce que c'est la seule méthode que tu connaisse que c'est la bonne manière de faire, et encore moins que c'est un palliatif.
[^] # Re: mocheté
Posté par Richard Dern . Évalué à 2.
Ben, je te pose la question. Je n'ai rien dis de tel. Je dis juste que selon la doc de PHP les traits permettent d'hériter des méthodes de plusieurs classes dans la mesure où PHP ne supporte pas l'héritage multiple.
Au lieu d'être aggressif, désobligeant et insinuer que je ne sais pas de quoi je parle, il serait plus constructif que tu étaye tes propos par des exemples de réutilisation de code hors héritage tu ne crois pas ?
[^] # Re: mocheté
Posté par Thomas Douillard . Évalué à 3.
La composition de fonction, tout bêtement, le copier coller, les bibliothèques et j'en passe … on réutilise du code depuis la nuit des temps :)
[^] # Re: mocheté
Posté par Richard Dern . Évalué à 2.
Mettre "copier-coller" dans la liste des techniques de réutilisation du code valides, faut oser…
[^] # Re: mocheté
Posté par Marotte ⛧ . Évalué à 3.
Il l'a quand même mis à part, à la fin ;)
[^] # Re: mocheté
Posté par tyoup . Évalué à 1.
ça ne veut pas dire que les autres soient valides pour autant…
[^] # Re: mocheté
Posté par Thomas Douillard . Évalué à 4.
valide c'était pas dans l'énoncé :)
évidemment que la non duplication est une propriété qu'on cherche dans la réutilisation. détent toi un peu.
[^] # Re: mocheté
Posté par maboiteaspam . Évalué à 3.
Je dirais que la différence se situe dans ce que l'héritage est une liaison verticale, alors que le trait est totalement horizontale. Maintenant j'ai peu fait usage de ces deux mécanismes, alors je n'irais pas plus loin. Préférant me cantonner à marcher comme homme et aboyer comme un chien, selon les envies : )
[^] # Re: mocheté
Posté par ckyl . Évalué à 7.
Oh mon dieu de vrais problèmes de fond ! Je comprends ta révolte et ton désarroi.
Note que je te soutiens aussi de manière sans limite sur le fait qu'étant un vrai opinniated developer avec du bon goût et du style, tu ne peux éviter de rendre ce monde meilleur en releasant de la vraie lib bien faite ! C'est clairement ce qu'il manque au monde du web qui n'avait pas vécu ça depuis au moins deux minutes :facepalm:
[^] # Re: mocheté
Posté par Richard Dern . Évalué à -4.
Ok. Donc en fait, on exprime une opinion, et on reçoit des commentaires ironiques, désobligeants qui ne servent à rien, c'est donc comme ça que ça marche. Soit.
Ce n'étaient que des exemples des ajouts récents à PHP qui m'ont rendu sceptique. Ce n'est pas ces deux exemples le problème que je soulève dans mon post. Donc j'aurai tendance à dire que tu t'es contenté de venir pourrir les coms de ce journal sans même prendre la peine de le lire.
Au moins, ce post de Laurent J, en désaccord avec moi, prend la peine de me dire en quoi il estime que composer c'est bien, ce qui contribue positivement au débat. Toi, tu te contente de faire un :facepalm:.
J'attendais un autre niveau de la part des commentateurs en fait. J'aurai mieux fais de ne m'attendre à rien du tout.
[^] # Re: mocheté
Posté par groumly . Évalué à 10.
Ben disons que t'arrives avec tes gros sabots de c'etait mieux avant, en citant le pire language web qui ait jamais été pense, notoire pour être troue de partout, que ce soit niveau design ou niveau implementation, a l'eco système notoire pour être une veritable passoire, que ca soit niveau design ou implementation.
Langage/eco système qui commence finalement a sortir lentement de l'impasse, et donc le c'etait mieux a vent fait légèrement sourire quand meme.
Quand tu rajoutes par dessus que ce qui te plait pas c'est des \ plutôt que des / et un point mineur de syntaxe, comment dire? PHP a des problèmes, beaucoup de problèmes, mais les backslash n'en font pas partie.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: mocheté
Posté par Richard Dern . Évalué à -8.
Commentaire encore une fois très constructif, surtout de la part de quelqu'un dont la signature est:
Ceci explique cela.
Juste une question: j'ai insulté vos mères pour justifier un tel comportement de votre part ?
[^] # Re: mocheté
Posté par Dinosaure (site web personnel) . Évalué à 5.
Non par contre il soulève un point intéressant. Déjà, parler de code moderne et de PHP nous laisse sourire.
Ensuite, parler des problèmes de syntaxes (qui ne sont que des problèmes de styles au passage, donc assez bien subjectifs) pour PHP montre une certaine ignorance des vrais problèmes de PHP qui sont de l'ordre de sa sémantique et surtout de son implémentation.
Il suffit de parler de PHP 6 pour se rendre compte que ce langage allait droit dans le mur et continue aujourd'hui à se dépatouyer de son héritage qui dénote particulièrement que: non, ce n'était pas mieux avant.
Au final ton article ressemble a un aigri qui veut continuer a faire du COBOL et se plaint qu'on puisse supplanter sa technologie (et ses habitudes) par quelque chose de nouveau (qui, avec un peu d'optimisme sur la communauté informatique, puisse nous convaincre qu'elle est objectivement mieux). Si tu reste dans cette position à dire non au code moderne (et il n'est pas moderne), tu risques de tomber dans des dogmes et finir comme le vieux tonton a chaque repas de Noël qui boit et qui se plaint - mais ton passif avec PHP n'en sera que meilleur pour en rigoler.
[^] # Re: mocheté
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 16 janvier 2015 à 07:55.
On pourrait te retourner la question : la planète (j'avoue ne pas savoir qui exactement, tellement ça tire sur tout gratutement, donc planète) a insulté ta mère pour justifier un tel comportement de ta part ?
(note : jamais j'aurai eu l'idée de parler des mamans des gens, mais bon je ne fais que recopier, je m'excuse pour les gens qui trouvent ça nul : je suis d'accord, attaquer en mettant les mamans dans l'histoire est le -273ème degré d'une discussion constructive, et je sais bien que généralement c'est quand une personne n'a pas confiance en elle et veut provoquer)
Parce que bon, le premier à sortir des énormités, celles qui font réagir les gens, c'est toi, tu provoques les gens avec des trucs absolument pas sérieux, qui ressemblent à la blague du bar du coin, pas du tout constructif, puis tu t'étonnes qu'ils répondent, pas forcémént sérieusement, pas constructif?
Hum… Je propose que tu commences à être constructif avant de critiquer les autres à ce sujet.
[^] # Re: mocheté
Posté par maboiteaspam . Évalué à -1.
/hs/ hmm on dirait que la propagande actuelle à déteint sur ta personne, nous savions déjà tous, je le crois, qu'il est mauvais, dérangeant, déplacé, de parler des mamans des gens. M'enfin, je ne sais pas si j'irais jusqu'à dire comme l'auteur du journal que cétait mieux avant HAHAHA /hs/
[^] # Re: mocheté
Posté par freem . Évalué à 4.
Je pense que la plupart des mamans, passé un certain âge, te diront que c'était mieux avant ;)
[^] # Re: mocheté
Posté par Faya . Évalué à 3.
TOut frais d'il y a 4 jours :
Le bon outil pour le bon usage
[^] # Re: mocheté
Posté par Richard Dern . Évalué à 2.
Et contribuerait à la diversité chère aux libristes :)
# à propos de Composer et autres
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Parce que peut-être les développeurs de ces libs ne s'y sont pas vraiment intéressé ou ne veulent pas, ou sont réfractaires à certains changement ? D'ailleurs Redbean le dit bien : le gars est "conservateur".
Cela ne veut pas dire que Composer c'est de la merde.
Et tu noteras que tu cites quand même des projets vraiment vieux (voir à peine maintenu comme PHPMailer). Lourd passif donc.
M'enfin bon, même si des libs comme celle-là ne sont pas fournie en paquet Composer, c'est juste 3 lignes de code supplémentaires à rajouter dans ton composer.json pour les intégrer dans ton projet. Pas la mort quoi.
J'ai l'impression que tu ne maintiens pas de projet public pour dire ça, ou alors tu es super compétent en design web et c'est super facile pour toi de pondre un design html/css.
J'ai plusieurs projets open source en PHP que je développe et maintien depuis des années. J'ai beau être compétent techniquement en HTML et CSS, je peux te dire une chose : ça me fais chier grave de faire les sites web de mes projets. Parce que je suis incompétent en design web et du coup, quand il faut que je refasse l'un deux, j'y passe des jours pour que ça ressemble à quelque chose. Ce temps, je préfère le passer à développer la lib. Donc je comprend très bien ceux qui choisissent bootstrap ou autre trucs "pour se faciliter la vie".
Ça c'est normal : le site de Smarty n'a pas bougé depuis 10 ans. Idem pour PHPMailer. Ils sont probablement comme moi : ils préfèrent passer du temps sur leur lib que sur le design de leur site.
Maintenant, utiliser bootstrap, ça a ses avantages : c'est responsive nativement, ça offre d’amblé un design "moderne" etc…
parce que j'ai l'impression que tu n'as pas trop en tête les avantages qu'ils offrent…
Je te rassures, même avant tout le monde boudait Pear. Quelle a été la proportion de lib et de projets qui proposait un paquet Pear ? 0,5% ? 1%? Franchement on n'y trouvait pas grand chose.
Et maintenant avec Composer ? 70%, 80%, 90% ? Le nombre de projets dispo via Composer est sans commune mesure avec Pear.
Et si Composer a un tel succès, c'est bien parce qu'il offre quelque chose de mieux non ?
Perso je n'ai jamais aimé Pear.
Déjà, c'est un truc hyper fermé : il faut que ton projet respecte certaines règles, notamment le coding style (que je trouve horrible). Ensuite, il faut qu'il soit accepté par les gens qui gère Pear. Tu ne peux pas avoir de doublons en terme de fonctionnalité avec une autre lib. Au final, Pear ne propose pas grand chose. Ou alors des usines à gaz. Interroge toi par exemple pourquoi tu as choisi PHPMailer plutôt que leur lib de mail.
Ensuite, sur le serveur (en particulier avec Debian), ton depôt PEAR est forcément partagé par tous tes projets. Au final, tu te retrouve coincé : tu ne peux pas mettre à jour au risque de casser tes vieux projets, et donc tu ne peux pas profiter des dernières versions pour des nouveaux projets. Et même si tu veux mettre à jour, c'est la galère avec debian, on ne sait jamais ce qu'il faut faire vraiment (y a toujours eu des trucs qui cassaient chez moi). Ne serait-ce que pour mettre à jour PHPUnit avec Pear. ça a toujours été la galère (à cause principalement qu'il faille faire ça en sudo, qu'il faille modifier le include_path dans la conf PHP etc).
Alors qu'avec Composer, tu as un dépôt par projet, chaque projet évolue comme il veut, utilise les paquets qu'il veut. PHPUnit et les autres paquetes s'installent en deux coup de cuillère à pot. Pas besoin de droits spéciaux sur le système pour les installer. Peu importe au final le système : ton projet reste indépendant.
M'enfin comme tu l'as dit toi même Pear c'est plus un Framework qu'un gestionnaire de dépendance. Donc au final, peu de rapport avec Composer.
Les gros avantages de Composer, c'est qu'il fait un seul truc et le fait bien : installer des paquets et gérer les dépendances. Un apt pour PHP.
L'autre gros avantage de Composer : il génère un autoloader. Adieu tous les includes dans tout les sens pour charger une lib ! Et si en plus les lib utilisent les namespaces (en respectant PSR-0 ou PSR-4), l'autoloader est beaucoup plus efficace.
À l'usage on se rend compte que ça apporte plus de souplesse, moins de tracas, et plus de perf (pas de chargement de classes non utilisées).
Ah non pas du tout ! Les PSR ne servent pas à faire en sorte que ça fonctionne quelle que soit la conf serveur. Je ne sais pas où tu as lu ça. Pour le moment, ils ont des recommandations pour le nommage des classes (PSR-0 et PSR-4), afin de faciliter le développement des autoloaders (que l'on n'a plus à développer si on utilise Composer), des recommandations sur le coding style (PSR-1 et PSR-2), et une recommandation sur l'interface d'un objet qui fait du log. Et ce qui est en discussion actuellement ce sont d'autres interfaces pour d'autres types d'objets courant (gestionnaire de cache, lib http…).
(donc non, ça ne servira pas qu'à Composer).
Bref, ce sont des choses pour améliorer l'interopérabilité entre les frameworks. Rien à voir avec la conf des serveurs.
Et puis ce ne sont que des recommandations. Pas obligé de les suivre.
Composer installe ce que les paquets ont besoin, pas plus, pas moins. Si un paquet a une dépendance envers un autre paquet et qu'il n'utilise pas, la faute est au développeur, pas à Composer. Mauvais paquet, changer paquet. (ça tombe bien, contrairement à Pear, le choix est très vaste).
Avec la nouvelle api password de PHP, cette lib est devenu inutile et obsolète (voir dangereuse, vu qu'elle n'est plus maintenue ?).
Les namespaces, c'est bon, mangez-en : ça évite les collisions de classes entre libs, ça facilite l'autoloading, ça permet une programmation moderne, ça force (un peu) à mieux organiser son code.
Je suis en train de "namespacer" mon framework, ça fait beaucoup de bien au final.
Pour finir, Composer, on peut s'en passer, mais c'est devenu la norme maintenant pour distribuer et installer des libs en PHP. L'ignorer ou le dénigrer n'aidera pas dans tes projets présent et futurs.
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . Évalué à 2.
Moi, ce que je vois avec composer, c'est que quand tu code une appli libre, tu cherche à simplifier au maximum l'installation.
Je suis désolé mais non, pour un débutant qui veut utiliser son application, ce n'est pas plus simple de faire:
que d'extraire une archive. D'autant que composer semble ne pas fonctionner partout de la même façon: sous Mac OSX, l'installation de CakePHP se fait exactement comme dans la doc officielle. Sous Debian, l'arborescence de vendor n'est pas la même et il devient impossible de charger le bootstrap de CakePHP sans modifier une variable pour mette le chemin en dur parce que sous Debian, il chope le repo git au lieu du repo PEAR (ou l'inverse, je ne sais plus).
composer est bien pour gérer les dépendances d'un projet pro, statique, où personne ne va mettre son nez dedans, mais pour un projet Libre, je pense que ce n'est pas une bonne solution.
Je suis loin d'être compétent en web design. Mais bootstrap, comme tout framework qu'il soit front ou back end, est fait pour industrialiser. Quand on code une appli libre, on n'industrialise pas. On industrialise quand on se fait plein de petits projets pour soi-même. Moi aussi j'utilise bootstrap quotidiennement pour mes projets perso (genre gestion DNS, gestion d'Apache, PKI, etc.), mais pour des applications Libres, je n'utilise que normalizer (sur lequel repose bootstrap). Pour les projets pros, pareil.
Je me suis peut être mal exprimé: je ne dis pas que bootstrap c'est de la merde, je dis qu'il faut arrêter d'en mettre partout. Je reste d'accord avec ce que tu dis.
Pas faux, le problème d'être élitiste :)
C'est un détail, mais non. Tu peux parfaitement utiliser PEAR pour un unique projet (c'est ce que fait Roundcube par exemple, qui n'a jamais nécessité d'installer PEAR alors qu'il en utilise des libs)
Pareil Horde permet d'être installé avec sa propre instance de PEAR (leur site est + ou - down là sinon j'aurai mis un lien).
Oui, je suis d'accord, mais ça serait mieux sans les pseudo-dépendances qui n'existent pas dans les archives !
Ou alors, les paquets composer sont structurés différemment des archives, ce qui forcerait les dev à maintenir deux paquets différents ?
Oui pardon je me suis enflammé ^
Ceci dit ils parlent d'interopérabilité, j'ai pensé que ça avait un sens un poil plus large…
C'est bien là que le bât blesse: quelque chose qui n'a rien à voir avec PHP devient la norme pour développer avec PHP.
Si le gestionnaire de dépendance était partie intégrante de PHP, les choses seraient différentes, mais là c'est un projet lambda. Et forcer à son utilisation est contraire à la philosophie du Libre.
[^] # Re: à propos de Composer et autres
Posté par xcomcmdr . Évalué à 5.
La philosophie du Libre, si tant est qu'elle existe, c'est les 4 libertés, rien d'autre.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . Évalué à -3.
Je sais, c'est de l'interprétation, mais pour moi ça implique que si une lib m'impose d'utiliser composer, ça restreint ma liberté.
PHPUnit permet les deux types d'installation (comme d'autres). Ça, c'est la bonne façon de faire, respectueuse de la liberté des devs.
Tu me diras, je suis libre de ne pas utiliser les libs qui me forcent à utiliser composer, je suis libre de les modifier pour les adapter à mon besoin, et ça, elles ne m'empêchent pas de le faire. Du coup on tourne en rond et la discussion devient stérile :)
[^] # Re: à propos de Composer et autres
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 15 janvier 2015 à 14:19.
C'est vraiment du foutage de gueule.
Allez, Linux ne compile qu'avec GCC, ça restreint ma liberté de choisir mon compilo, Linux est contre le philosophie du libre. Ou pas.
tu peux toujours inventer un truc à ce niveau.
Oui. Du coup tu dis toi-même que tes idées sur le libre sont fausses. J'avoue ne pas comprendre à quoi tu veux en venir.
Libre != obligation à l'auteur de faire comme toi tu veux. Fournir un logiciel qui demande composer est 100% dans le respect de la liberté des utilisateurs (et personne ne te force, juste qu'on n'a pas codé pour ton désir), tu n'as aucune restriction.
Ben disons que quand l'auteur d'un post dit que ce post est n'importe quoi sans arrêter de penser que son post est correct, on a du mal à suivre. C'est quoi le but de cette mascarade?
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . Évalué à -2.
Là tu extrapole.
Déjà parce que Linux dépend de certaines extensions de GCC. Une lib qui veut s'installer via composer ne dépend pas de librairies de ce dernier (qui n'en a pas) pour fonctionner, elle fonctionne en toute autonomie.
Ensuite, comparer quelque chose d'aussi critique que le noyau Linux et une librairie PHP qui fait du routage pour une app web, c'est osé…
Je ne dis pas que mes idées sont fausses, je dis qu'il n'y a pas de raison d'obliger un dev à passer par composer pour installer sa lib. Comme je l'ai dis plus tôt, PHPUnit propose les deux méthodes d'installation, c'est donc qu'il est possible de laisser le choix aux développeurs de leur méthode d'installation. Et bien que nous ayons la possibilité de modifier ces outils à notre convenance, tout l'intérêt d'utiliser une lib est de se simplifier la vie, et réduire le temps passé à l'adaptation de l'existant. C'est encore plus embêtant quand on suit des recommandations d'interopérabilité.
Je ne dis ni que mon post est n'importe quoi, ni qu'il est correct. C'est mon journal, j'y écris mon ressenti. Peut être que je m'y exprime mal, mais d'autres dans les commentaires ont compris ma démarche.
Si tu n'as pas compris le but de mon journal, je t'invite à le relire. Je me suis peut être mal exprimé dans mes commentaires, mais il me semble avoir été plus que clair en disant que je n'aime pas le code moderne :)
Toujours dans un soucis de clarification, ce que tu appelle "masquarade", j'appelle ça "un coup de gueule passé contre les librairies qui forcent les devs à utiliser des outils dont ils ne veulent pas sans pouvoir justifier d'une liaison si forte entre la librairie et l'outil que le premier ne peut être installé sans le second". Sur ce point aussi, il me semble avoir été clair tout au long des commentaires.
[^] # Re: à propos de Composer et autres
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 15 janvier 2015 à 15:16.
Personne ne force.
Quitte à me répéter, le libre n'est pas faire ce que toi veut. Le libre n'est pas l'obligation de coder. Le libre c'est fournir du code avec des libertés (les 4 libertés).
Tu extrapoles pas mal le libre.
Que tu n'aimes pas certains liens pour une raison x, c'est ton choix et admettons (même si l'exemple que tu as donné est, de ce que j'ai compris, plutôt un refus d'accepter un patch tout bête pour proposer une autre façon de faire le package, sans rien enlever, plus que du conservatisme), mais n'associe pas le libre à ton choix et à tes idées de comment doit être un projet, le libre n'a rien à voir la dedans, ni de près ni de loin.
[^] # Re: à propos de Composer et autres
Posté par barmic . Évalué à 5.
Tu trouve intéressant de te répéter à longueur d'année ?
Quand les gens affirment que tel ou tel trucs les forces, c'est qu'ils utilisent une expression très classique en français. Ici, par exemple, à la place de:
Il fallait comprendre :
Ça ne change rien au reste de ton commentaire, mais éviter les hommes de paille, ça irrite beaucoup moins tes interlocuteurs et ça participe à un débat un peu plus intéressant (mais bon c'est peut être pas ce que tu recherche).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: à propos de Composer et autres
Posté par kursus_hc . Évalué à 2.
Là c'est toi qui pinaille, personne ne force personne, point. Ce n'est pas un "débat intéressant", c'est simplement n'importe quoi. Si une lib à une dépendance, et que ça ne te plaît pas, tu en choisis une autre ou tu en écris une, point. Voilà ce qu'il faut ramener au libre et certainement pas une crypto-cabale des développeurs.
En plus il faut vraiment être de mauvaise fois pour critiquer Composer : c'est hyper pratique et ce n'est pas une "dépendance" au sens où c'est un simple fichier qui peut être supprimé après la mise en place. Ca pourrait être drôle de comparer les temps de mise en place d'un boilerplate de 10 libs à jour avec et sans Composer. En plus c'est évidemment parfaitement intégré à l'environnement Linux donc bon.
Pour continuer sur les propos incohérents de l'auteur du journal, on a :
Non, c'est fait pour gagner du temps et diminuer les erreurs, comme tout framework. Je préfère qu'un dev fasse son site en Bootstrap si ça peut lui donner plus de temps pour améliorer sa lib. D'ailleurs une simple recherche "Boostrap theme" croule sous les résultats, donc en rajoutant une couche à la surcouche on arrive à un résultat pertinent et indétectable qui berne tout le monde, ce qui tend à démontrer la faiblesse de l'argumentation de l'auteur du journal.
Je passe sur la deuxième phrase qui montre le réel degré de liberté qu'il accorde au "libre".
[^] # Re: à propos de Composer et autres
Posté par barmic . Évalué à 3.
Pour utiliser c'te lib, tu es obligé d'utiliser composer.
Cette lib te contraint d'utiliser composer.
Tu ne peux utiliser cette lib sans composer.
Voila si le mot "force" te gêne choisi celui que tu veux.
Tu y réponds pourtant. Ce que l'auteur veux faire ressortir c'est qu'il trouve qu'une dépendance ne lui convient pas. Il a le droit d'exprimer son avis et de l'expliquer et si cet avis et si idiot, tu peut le lui expliquer comme tu le fait dans le reste de ton commentaire, mais dire "si ça ne te plaît pas ta gueule et va voir ailleurs" ça n'a pas d'intérêt autre que de l'énerver.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: à propos de Composer et autres
Posté par Zenitram (site web personnel) . Évalué à 2.
C'est rigolo, d'habitude quand on parle de logiciel GPL qui force la licence sur du code tiers, ici ça réagit "mais non ça ne te force pas, tu es libre".
Donc on est bien d'accord : Barret Michel dit que la GPL est virale, elle force, et défendra les gens qui le disent.
Et encore, c'est pas un bon exemple, car c'est pire mon exemple : Linux est bien plus horrible, parce que bon, on ne peut pas prendre Linux, virer la dépendance à la GPL, et rediffuser, alors que la, on prend la lib, on la modifie, et hop on peut la rediffuser tout ça (on peut même proposer à l'upstream un patch pour ne pas avoir la dépendance).
bref, pour résumer : réaction très très sélective.
Rappel : l'exemple de conservatisme fourni dans le journal est le refus d'un bete fichier à inclure dans la distribution du logiciel. Qui force?
[^] # Re: à propos de Composer et autres
Posté par barmic . Évalué à 3.
Oui tout à fait. Mais t'en a pas marre de ressasser toujours les mêmes choses ? De la même manière que pour le « non ça ne force pas », tu finis par prendre à parti en imaginant ce que j'ai pu dire ailleurs.
C'est une évidence que la GPL contraint et que le code sous GPL (mais plus généralement sous copyleft) contraint, ça n'est un secret pour personne. C'est pour ça que des gens ont créé des licences sans copyleft, c'est le genre de trucs qui font que zfs ne peux pas être intégré à linux.
Si tu veux aller dans les choses aussi puériles, je peux changer ma signature rien que pour toi, mais bon je me sens un peu con tellement c'est plat.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: à propos de Composer et autres
Posté par Nicolas (site web personnel) . Évalué à 8.
J'ai la nette impression (mais je peux me tromper) que les personnes qui commente l'utilisation de composer de l'ont jamais utilisé. Je ne comprends pas le terme force à utiliser composer. composer n'est qu'un outil permettant d'installer une bibliothèque (library) dans la bonne version. Il est tout à fait possible d'installer la même bibliothèque à la main.
[^] # Re: à propos de Composer et autres
Posté par Guillaume Rossignol . Évalué à 7.
Dire qu'on est obligé d'utiliser composer pour utiliser une lib, c'est comme dire qu'on est obligé d'utiliser un gestionnaire de paquet pour installer un logiciel. C'est simplement faux.
C'est juste que lorsqu'il y a un paquet compatible, c'est 50x plus plaisant de faire un simple
apt-get install le_paquet_plutot que d'aller chercher les 50 libs necessaire, les installer à la main pour ensuite pouvoir lancer l'application.Composer offre en plus l'avantage de faire des installations locales, ce qui fait qu'on peut utiliser simplement plein de versions du même truc pour des sites différents.
Et ça reste vachement plus glamour d'avoir des messages d'erreur explicite (genre il faut avoir telle extensions de php installé pour pouvoir utiliser tel lib) aprés un composer install plutot qu'une fatal assez obscure à l'execution.
Certains logiciels n'utilisent pas composer (ni de tests), quel est le résultat ? On se retrouvent au bout de six mois, avec des bugs dans des librairies tierces, qui sont corrigées depuis belle lurette, mais comme on n'est pas allé voir sur les différents site où en etait les differentes librairies, ben on se retrouve à patcher dans l'urgence.
Alors certes, avec composer, il faut quand meme faire un update pour voir s'il y a eu des modifications. Ca reste vachement plus leger que d'aller vérifier toutes les dépendances une à une.
Mais dans tous les cas, composer est toujours dispensable. C'est un peu comme les dockerfiles. C'est pas parce qu'il y a un dockerfile dans le projet qu'on est obligé de l'utiliser. C'est juste une commodité fournie.
[^] # Re: à propos de Composer et autres
Posté par barmic . Évalué à 1.
Comprenons-nous bien. J'en sais rien et je m'en fou. Je ne connais pas composer, je ne fais pas de PHP et je ne compte pas en faire durant la prochaine décennie.
Ce à quoi je répondais c'est au shemas :
Réponse qui démontre aussi une totale incompréhension de ce qu'est composer.
Justement ce que je dis c'est qu'au lieu de répondre une réponse toute faite, qu'on revoit aussi pour systemd et pour pleins d'autres sujets. Il est largement plus intéressant d'expliquer, comme vous le faites pour me répondre, que ce n'est pas une obligation.
Bref ma participation était plus liée à du méta-débat qu'au débat en lui même (je ne me suis jamais prononcé sur l'intérêt ou non des lib en question ou de composer).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: à propos de Composer et autres
Posté par Faya . Évalué à 6.
Qu'est-ce que ça veut dire "me forcent à utiliser composer" ? Là vraiment je comprends pas.
Utiliser composer, du point de vue du dev c'est juste fournir un json qui te dira de quelles autres librairies tu dois disposer pour que ça marche. Mais tu peux toujours faire sans ! Télécharge les sources, télécharge les dépendances et configure l'autoloading à la main. Voilà.
Je vois composer comme un genre de Phpdoc, tu peux soit suivre le format des commentaires et l'utiliser pour générer ta doc, soit écrire tes commentaires comme tu veux et écrire ta doc à la main … Mais en aucun cas on ne te force à quoi que ce soit !
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . Évalué à -6.
"Forcer" est un raccourci que j'aurai dû utiliser avec plus de parcimonie.
Je m'étonne simplement du fait que certaines libs ou certains outils (PHPUnit me vient en premier à l'esprit) mettent en avant les deux méthodes d'installation (avec ou sans composer), alors que d'autres non.
Oui, bien sûr, on peut utiliser une lib sans composer. Mais on nous "force" la main quand même en ne precisant pas dans la doc de ces libs comment les installer sans composer. Un simple lien suffirait.
[^] # Re: à propos de Composer et autres
Posté par Dinosaure (site web personnel) . Évalué à 4.
Bah au lieu de te plaindre, c'est précisément là où tu devrais faire un patch pour être offrir une installation sans composer. Et, oh wait … C'est ça qu'on appelle le libre ! Le fait de pouvoir modifier le code et le redistribuer (vers upstream ou en fork).
[^] # Re: à propos de Composer et autres
Posté par kursus_hc . Évalué à 3.
Ha oui mais ça implique de faire quelque chose plutôt que de se plaindre dans le vent ? Très peu pour moi.
[^] # Re: à propos de Composer et autres
Posté par totof2000 . Évalué à 2.
Je dirais plutôt la liberté des développeurs.
[^] # Re: à propos de Composer et autres
Posté par barmic . Évalué à 3.
Non ils contraignent les développeurs dès lors que le logiciel en question est copyleft. D'ailleurs c'est à l'utilisateur que tu dois fournir le code source de l'application. Enfin pour le développeur, ça augmente la concurrence parce que tes utilisateurs peuvent se barrer avec ton code (que tu as était obligé de leur fournir) et aller voir quelqu'un d'autre pour demander des évolutions sur cette base de code (et ils ont le droits de te faire un gros fuck si tu demande à voir le code des nouveautés).
Vraiment la liberté, elle est coté utilisateur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: à propos de Composer et autres
Posté par Space_e_man (site web personnel) . Évalué à -1.
J'ajouterais le Manifeste GNU (même si l'on fut déjà plus dans du concret, quoi que…)
[^] # Re: à propos de Composer et autres
Posté par Renault (site web personnel) . Évalué à 4.
Non, le Manifeste GNU c'est comme le Manifeste Mozilla, c'est lié à un projet en particulier ici GNU (d'ailleurs certaines parties comme la gratuité ou la compatibilité UNIX n'ont rien à voir avec la notion de Logiciel Libre).
Ce texte n'a donc rien d'un précepte pour la notion de LL qui n'est que les 4 libertés, le reste sont du fantasmes, des projets particuliers ou des souhaits particuliers mais rien d'officiel.
[^] # Re: à propos de Composer et autres
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Moi quand je code, je veux faire les choses vite et bien, parce que ce qui m’intéresse, c'est avant tout de pouvoir répondre à un besoin. Alors si l'installation d'une lib est simplifiée, si les développeurs peuvent installer mon framework en déclarant une petite dépendance et en tapant une seule ligne de commande, ça me va.
Tu parles d'un utilisateur, ou d'un développeur ? Parce que si c'est pour fournir une application finale (un truc comme wordpress ou phpbb) destinée aux utilisateurs, oui faut être con pour proposer ce genre de chose (encore que, si Composer est installé d'office par les distros, ça peut avoir du sens). Et si je ne me trompe pas, ce genre de projet proposent en général un zip pour les utilisateurs, comportant toutes les dépendances, à déposer quelque part, prêt à être utilisé.
Pour les développeurs de l'application par contre, non, Composer facilite le développement, les mises à jours des dépendances, l'installation du projet etc… Et donc Composer convient très bien au développement.
Faut pas confondre développement et utilisation. Développeur et utilisateurs.
En ce qui concerne debian et cakephp, j'ai bien l'impression que ce que tu racontes n'a rien à voir avec Composer…
Désolé, mais tu me fais bien rire là :-) La majorité des packages installables par Composer sont des projets libres. Donc pour ces projets, ce n'est pas la solution ??? Pourquoi ils sont dans Composer alors ? Pourquoi c'est autant utilisés ?
Gniiii ??? c'est quoi cette histoire ? Pourquoi il ne faudrait pas "industrialiser" ?
Parce qu'on code une appli libre, il ne faudrait pas utiliser les outils que l'on a à notre disposition pour développer, déployer, tester et tout faire à la mimine ou rien faire ???
Bah désolé, une partie de mes projets libres, je les développe sur mon temps libre (qui se restreint de plus en plus). Tout outil qui pourrait me faire gagner du temps, qui me permettrait d'être plus productif, je les utilises.
Et c'est d'autant plus intéressant que j'en profite pour découvrir des nouveaux outils ou libs, qui me permettent ensuite au niveau professionnel de monter en compétence, d'être plus productif (et donc éventuellement d'avoir plus de temps pour dev les projets libres).
J'hallucine là. Tu trolles là en fait hein ? c'est ça ?
Je vais t'apprendre un truc : n'importe quel lib proposée par Composer, tu peux l'utiliser sans Composer. Suffit juste que tu ailles chercher toi même les dépendances, et te faire un autoloader (ce qui est une perte de temps à mon avis).
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . Évalué à -3.
Oui, mais c'est encore plus simple et rapide d'extraire une archive. Je rajoute l'argument sécurité: si l'URL du dépôt de ton framework est comprise et que le dev qui utilise composer ne vérifie pas ce que composer télécharge…
Peu importe: de plus en plus d'applications complètes utilisent composer comme méthode d'installation par défaut (Magento par exemple)
Possible, mais je n'ai jamais pu trouver une autre explication.
La majorité des paquets composer ne sont pas des applications complètes mais des librairies. A mon sens c'est une grosse différence.
Non, ce n'est pas ce que j'ai dis. Pardon, j'abuse de raccourcis, je vais faire plus attention à comment je présente les choses.
Ce que je veux dire c'est que quand on développe une application à destination du "grand public", on cherche à lui donner une identité. Si on se contente d'un bootstrap à peine modifié, on ne lui donne pas une identité. Mais on peut très bien utiliser bootstrap comme une base, et faire des changement plus importants que lui attribuer un nouveau swatch… J'aime bien parfois tomber sur un site dont l'esthétique me plait, me demander ce qui est utilisé pour le frontend, et découvrir que la base est bootstrap.
On n'est pas tous web-designer, d'où l'intérêt du Libre: que des web-designers contribuent à l'identité de l'application.
En entreprise le problème est différent: on s'en tape de l'identité visuelle d'une application à usage interne. Donc là, on industrialise en mettant du bootstrap, possiblement avec quelques corrections mineures, mais le but étant surtout que ça marche et vite. Cette prérogative de "productivité" comme dit ne devrait pas exister dans le cadre d'un projet individuel, non professionnel.
Encore une fois, je précise que j'utilise ces outils pour mes projets privés, des projets qui ne seront jamais diffusés. Je ne suis pas contre leur usage, il faut être clair là dessus. Je suis contre leur usage pour tout et n'importe quoi et surtout lorsque le travail résultant est rendu public. Ce n'est pas un gage de sérieux selon moi.
Désolé si tu as interprété mes propos comme étant du troll.
C'est bien ça le problème. Si les libs étaient proposées avec leur propre auto-loader (ce que fait, une fois encore, PHPUnit, PHPMailer, Smarty, etc.), il n'y aurait pas besoin de faire ça à la main. C'est à la librairie de dire comme se charger, on n'a pas à le "deviner" ou le supposer.
[^] # Re: à propos de Composer et autres
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 8.
en tant que développeur. Non. Pas du tout. Puisque j'ai même pas à connaitre l'url. Juste le nom du paquet. Une ligne dans le json (nom/version), composer install, et c'est terminé. Je veux mettre à jour ? je change la version dans le json, composer update. c'est terminé.
Alors qu'avec une archive : je dois aller la récupérer sur le site du projet, la dézipper dans mon projet, chercher à savoir comment inclure la lib, ou instancier son autoloader, et donc faire un include (voire plus) quelque part dans mon code. Ensuite, je veux mettre à jour (souvent plusieurs mois après) : faut que je retourne sur le site (dont j'ai oublié le lien, hop, détour par google), retélécharger à la mimine, dézipper les fichiers, ajouter les nouveaux fichiers dans le subversion/git, et supprimer les fichiers qui n'existent plus dans la nouvelle version (ce qui peut être fastidieux, et je parles en connaissance de cause), vérifier dans la doc que l'autoloading ou l'inclusion se fait toujours pareil…
Bah désolé, non, avec Composer, je n'ai pas toutes ces emmerdes, puisque Composer me télécharge tout ça automatiquement, qu'il m'évite à un inclure dans mon dépôt git ces libs externes, et parce que l'inclusion/autoloading, c'est Composer qui fait tout ça pour moi.
Parce que le site où tu télécharge ton zip, il ne peut pas être compromis ? tu vérifie tout les zip des libs que tu télécharges ? cela voudrait dire que tu vérifie le contenu de chaque fichier ? et pourquoi alors tu ne pourrais pas le faire dans les sources posées dans le vendor/ par Composer ?
L'argument de sécurité est nul ici.
Perso je trouve ça bête pour un utilisateur final. Mais Magento n'est pas un bon exemple pour ton argumentaire. Le lien que tu montres, c'est la doc pour les développeurs (c'est marqué sur la page). Donc oui, là, utiliser Composer a un sens. Puisque si tu es développeur, cela veut dire que tu vas personnaliser Magento, lui rajouter du code pour des traitements metiers, des plugins ou que sais-je, et donc probablement installer d'autres lib (en utilisant Composer ou pas).
Pour les utilisateurs finaux, il faut aller voir sur le site pour les utilisateurs. Et qu'y trouve-t-on ? Oh, miracle, des tar.gz prêts à l'emploi ! ;-)
Tu parlais de projets libre. Alors, à moins que pour toi une lib libre n'est pas un projet libre, je ne vois pas de différence.
Tu passes de PHP à Bootstrap, du coq à l'âne, donc des problématiques différentes. J'avoue que ton discours est très difficile à suivre.
Oui donc, au final, dans un projet, si tu utilises 25 libs, tu as alors 25 autoloaders, qui font quasiment la même chose. Bonjour les perfs. Avec Composer : on peut avoir un seul autoloader, en particulier si on utilise les namespaces (il est possible de lui indiquer des autoloaders spécifiques si nécessaire, par exemple ceux des libs ayant un autoloader spécifique).
Justement, avec Composer, on a encore moins à s'en charger, puisqu'il y a au final 0 include à faire après avoir installé une lib. Alors que, pour une lib "non composerifiée", il faut que tu saches quel fichier inclure (celui qui fait tout les includes de la lib ou qui déclare l'autoloader de la lib).
[^] # Re: à propos de Composer et autres
Posté par Frank-N-Furter . Évalué à 2.
Products/Open Source CE/View available downloads
Un mouse over, et deux clicks
http://www.magentocommerce.com/download
Mais typiquement, Magento, c'est le genre de truc qui n'est pas installé par l'utilisateur final.
Depending on the time of day, the French go either way.
[^] # Re: à propos de Composer et autres
Posté par Zenitram (site web personnel) . Évalué à 5.
Tu sais ce qu'est le libre?
Je ne vois aucun rapport entre libre et industrialisation.
il y a des outils non libres non industrisalisés comme des outils libres industrialisés.
C'est insultant envers le libre de deux manières : 1/ en ne connaissant pas ce qu'est le libre 2/ En sous-entendant que le libre ne peut pas être professionel.
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . Évalué à -5.
Il semble que mes connaissances en la matière soient moins étendues que les tiennes (je dis sans sans la moindre ironie). Aurais-tu l'amabilité de m'indiquer un projet libre industrialisé, écrit en PHP, et à destination du "grand public" (donc pas destiné à un usage professionnel) ?
Je ne sous entends pas que "le libre ne peut pas être professionel", je sous entends qu'une application libre non professionnelle ne devrait pas être industrialisée. Tu me suis ?
[^] # Re: à propos de Composer et autres
Posté par Zenitram (site web personnel) . Évalué à 2.
La seule chose que je dis est que le libre n'a rien à voir avec tout ce dont tu parles.
Libre ou pas, on s'en fout pour ce dont tu parles, c'est orthogonal.
J'ai du mal à comprendre ce qui est difficile à comprendre la dedans : c'est comme si tu me disais qu'une voiture de couleur bleue ne peut évidement pas aller plus vite qu'une voiture de couleur verte.
[^] # Re: à propos de Composer et autres
Posté par Richard Dern . Évalué à -5.
J'aimerai quand même une réponse à ma première question, ça m'intéresse vraiment.
Et je parle de libre parce que pour du privateur on s'en tape de toutes ces considérations.
[^] # Re: à propos de Composer et autres
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 8.
Faudrait déjà que tu définisses "industrialisé", et "usage professionnel".
[^] # Re: à propos de Composer et autres
Posté par maboiteaspam . Évalué à 1.
C'est pas faux. J'ai un peu le même souci avec nodejs. Mais bon, vu qu'en php il faut en plus se taper le serveur web + bases de données, normalement après ces terribles épreuves, tu sais à peu près comment géré
Maintenant, pour en revenir au problème que tu soulèves. Je pense que tu l'attaques par le mauvais bout. Ce qu'il te manque c'est un installeur simple et rapide, comme papa faisait avec son windows. Un double click, et après une mitraille de YES YES YES OK CONTINUE et bam c'est installé.
M'enfin, apparemment, tout le monde y va de son store et de son système de package à l'heure actuelle. Moi cela me va tant qu'on ne m'empêche pas de publier dessus, sinon c'est de la tyrannie (genre debian et ces paquets, ma ptite crotte de nez)
# Python c'est mieux maintenant
Posté par reynum (site web personnel) . Évalué à 7.
Si PHP et son ecosystème ne te conviens plus il existe Python (WSGI) et un framework Django qui est MVC.
kentoc'h mervel eget bezan saotred
[^] # Re: Python c'est mieux maintenant
Posté par xcomcmdr . Évalué à 6.
Ou Ruby On Rails, ou node.js, ou …
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Python c'est mieux maintenant
Posté par Tangi Colin . Évalué à 4.
Python pourquoi pas, par contre Django bof bof, y a des choses qui me manque dedans et qui sont pas évidant à faire ou avec des plugins non-maintenue tels que Server Sent Event par example.
Je préfère largement flask à choisir.
[^] # Re: Python c'est mieux maintenant
Posté par Richard Dern . Évalué à 0.
Jamais dis que PHP ne me convenait plus: ce sont les "trucs" modernes qui ne me conviennent pas, et surtout, la quasi obligation de passer par des outils comme composer pour choper des libs.
Je ne dis pas non plus que tous les trucs modernes me dérangent: Redbean est une lib moderne développée par un conservateur. Ça pour moi c'est l'idéal du développement en PHP.
[^] # Re: Python c'est mieux maintenant
Posté par Faya . Évalué à 0.
Moi le framework qui me force à utiliser un ORM ça ne me convient pas. Inclure une floppée de classes juste pour écrire un CRUD propre je trouve ça tout much donc ton Redbean moderne conservateur me dérange …
À conservateur, conservateur et demi !
[^] # Re: Python c'est mieux maintenant
Posté par Richard Dern . Évalué à -2.
L'intérêt est surtout de faciliter le développement sans ciblage d'une BDD spécifique en l'occurrence.
[^] # Re: Python c'est mieux maintenant
Posté par Faya . Évalué à 2.
Je crois (puisqu'on parle de PHP) que c'est précisément à ça que sert PDO
[^] # Re: Python c'est mieux maintenant
Posté par Richard Dern . Évalué à -2.
Tout à fait, et d'ailleurs Redbean s'appuie sur PDO en simplifiant certaines opérations et surtout en modifiant à la volée la structure de la base de données.
Si ça c'est pas fait pour aider les développeurs…
[^] # Re: Python c'est mieux maintenant
Posté par Moonz . Évalué à 8.
Tu veux dire, un peu comme composer et bootstrap ?
[^] # Re: Python c'est mieux maintenant
Posté par Faya . Évalué à 3.
C'est ce que j'appellerais moi "fancy", comme le tag de ton journal. Et je n'en veux pas. Ça diminue fortement, pour moi, la lisibilité chère aux libristes.
TU vois, on est toujours le conservateur d'un autre autre, mais toi tu y trouves ton compte, tant mieux. Pas de quoi fustiger un non-respect d'une pseudo-éthique libre ou une "industrialisation" ou que je ne sais-je.
[^] # Re: Python c'est mieux maintenant
Posté par maboiteaspam . Évalué à 1.
Ah ouais…. un ORM qui dispose d'un query writer me semble totalement indispensable aujourd'hui pour faire un CRUD honnête pour mes utilisateurs et sans trop d'efforts. M'enfin, y'à ceux qui regardent devant, et puis y à les autres.
# Plutôt d'accord
Posté par Hodj . Évalué à 8.
Je fait partie des vieux cons qui ont commence le web avec les CGI puis je suis passé à php à l'époque ou ça voulait encore dire "Personnal Home Page".
J'ai récemment fait un projet avec synfony 2 et alors la j'étais sur le cul:
- Ils ont réinventés les annotations : quitte à faire du comme avec java autant le faire en java
- Le framework balance ses header sans même que tu le lui demande, ce qui fait que pour générer à la volée une image la seule solution a été de provoquer un trap : ce qui est quand même très moche.
et plus généralement sur les framework php modernes j'ai lu, il y a quelques temps (je ne me rappelle plus de l'url mais il me semble que je l'avait trouvé depuis linuxfr) du créateur de php qui disait tout le bien qu'il en pense.
[^] # Re: Plutôt d'accord
Posté par Richard Dern . Évalué à 4.
100% d'accord avec tes remarques sur Symfony, et c'est bien de lui que je parlais quand je disais "Du code logique dans les commentaires ?" (ça a peut être changé depuis ceci dit)
[^] # Re: Plutôt d'accord
Posté par Hodj . Évalué à 3.
J'ai retrouve l'url de l'interview de Rasmus
Interview
[^] # Re: Plutôt d'accord
Posté par Richard Dern . Évalué à 1.
Merci pour le lien !
[^] # Re: Plutôt d'accord
Posté par Ozz . Évalué à 3.
les "fausses" annotations sont loin de faire l'unanimité, même chez les "modernes". Tu peux faire du symfony sans les utiliser du tout, c'est pas plus compliqué, ça manque un poil de doc pour les entités doctrine, qui est le seul domaine ou la doc pousse vraiment les annotations, autant que je me souvienne.
Mais surtout n'utilise pas symfony si t'aimes pas, un agrégat de lib qui te plaisent pour faire ta sauce, c'est cool. Et justement PSR, composer et les namespaces, ça permet de faire ça simplement et un peu plus maintenable, même s'il peut y avoir des choses à redire sur les implem/syntax.
Ozz, qui n'a presque plus honte de faire du php pour se nourrir.
[^] # Re: Plutôt d'accord
Posté par maboiteaspam . Évalué à 2.
Ca sert à quoi d'autre le PHP ? C'est pas du code alimantaire ? Mince alors… j'en était totalement convaincu.
[^] # Re: Plutôt d'accord
Posté par Sufflope (site web personnel) . Évalué à 7.
Un avis précieux qui convaincra tout le monde tant personne n'a jamais dit tout le bien qu'il pense de PHP :-D
# Laravel + Twig semble pas mal
Posté par Stéphane Klein (site web personnel) . Évalué à 4.
J'ai quitté le monde Php pour aller vers Python depuis on va dire 2007, mais j'ai l'impression qu'il existe maintenant des trucs pas trop mal en Php qui ressemble à Django, Flask, Pyramid :
J'ai aussi l'impression que Smarty (je l'utilisais en 2002) semble dépassé, http://twig.sensiolabs.org/ semble très bien, clone du moteur de Template Jinja2.
[^] # Re: Laravel + Twig semble pas mal
Posté par Richard Dern . Évalué à 0.
Tout ce que tu viens de linker repose sur Symfony (ou codé par les gars de Symfony, donc avec la même philosophie) qui… on va dire n'est pas fait pour les conservateurs ^
[^] # Re: Laravel + Twig semble pas mal
Posté par Stéphane Klein (site web personnel) . Évalué à 2.
Pour Laravel, tu es certain que c'est basé sur Symfony ? j'ai un gros doute là dessus.
[^] # Re: Laravel + Twig semble pas mal
Posté par Richard Dern . Évalué à 2.
Cf page d'accueil
[^] # Re: Laravel + Twig semble pas mal
Posté par maboiteaspam . Évalué à 1.
De la même manière que tu aimes faire un agrégat de lib pour tes projets. Je vois pas ce que tu leurs reproches. Ils ont agrege des libs qu'ils aimaient bien est mis leurs sauces par dessus.
[^] # Re: Laravel + Twig semble pas mal
Posté par Richard Dern . Évalué à 1.
Ah et pour info Smarty n'est pas du tout dépasé, il est mis à jour régulièrement au contraire (c'est plus flagrant sur leur dépôt github)
# des mauvaises expériences ?
Posté par maboiteaspam . Évalué à 4.
J'étais content que les PSR soit release. J'étais content que Composer soit crée. J'était moins heureux de voir la complexité de symfony2. Mais dans l'ensemble je trouve que ces outils sont des avantages pour les développeurs PHP.
Alors je ne te comprends pas bien.
Je ne peux que t'inviter à pousser tes tests.
Derniere chose, Redbean, c'est bien, c'est pratique, m'enfin, ce n'est pas non plus la panacée, selon moi.
Gabor a des avis tranché sinon il manipulerait du doctrine, mais sur ce point, ce n'est pas très argumenté.
# "leur usage abusif des namespaces"
Posté par xcomcmdr . Évalué à 10.
Euh, QUOI ?!
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# C'est pas le code moderne que tu n'aimes pas, c'est le PHP moderne...
Posté par freem . É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!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.