SPIP, le petit ecureuil grimpe toujours aux arbres

La communauté SPIP vient d’annoncer fièrement la sortie de la version 2.0 du petit CMS d’origine française qui fait tourner un nombre incalculable de site avec, tout de même, un article sur linuxfr.

Le projet SPIP, qui a été initié en 1998, par une communauté restreinte qui découvrait le PHP3, a grandement évolué depuis. Il permet aujourd’hui de créer un site éditorial complexe sans avoir aucune compétences en programmation. Son succès fulgurant s’explique par sa simplicité d’utilisation, sa facilité de déploiement (notamment chez les hébergeurs gratuits) et de prise en main, sa documentation exhaustive, sa communauté extrêmement active.

Les leaders du projet ont, difficilement et avec de nombreuses objections et réticences, adoptés mollement des pratiques de programmation modernes (objet et MVC par exemple). Toutefois il y a bien un truc qui n’a pas changé c’est l’habitude déconcertante pour un projet libre de ne jamais utiliser de briques externes et de tout faire soit même (mis à part des librairies JS et SafeHTML je crois).  Dans la version 2.0 de SPIP une « interface avec le SQL » est annoncé. Ont ils utilisé un des nombreux ORM existant déjà (arf, c’est peut être la dépendance à PHP5 ?) , que nenni ! Tout a été refait from scratch, pour les besoins du projet 😦

Je trouve cette approche vraiment déconcertante.

Publicités

10 réflexions au sujet de « SPIP, le petit ecureuil grimpe toujours aux arbres »

  1. Nicolas Hoizey

    Même si je partage partiellement ton regret que SPIP n’adopte pas plus les principes de base des frameworks modernes, je comprends bien que l’intérêt de faire sa propre couche d’abstraction, c’est de générer des requêtes adaptées précisément à chaque besoin et SGBD, donc des performances et charges mémoire et CPU optimales.

    Un ORM ou une abstraction quelle qu’elle soit implique souvent la nécessité de faire des compromis et notamment de réduire les possibilités de requêtage à un tronc commun forcément restrictif, et aussi une charge mémoire et CPU accrues du fait des traitement intermédiaires supplémentaires.

    Répondre
  2. NiCoS

    Sans parler de leur convention de nommage, que tout soit en français (pratique pour les SSII française qui outsourcent leurs dev 😉 ) etc.

    Pour le rapport à PHP5, la POO n’est pas encore arrivée dans SPIP à ma connaissance ou alors de façon très marginale. C’est balo car je pense qu’avec la généralisation de PHP5 et de la POO, cela va plus leur porter tord qu’autre chose à moyen terme…

    Leur syntaxe devant de plus en plus compliquée et spécifique, j’ai perso de plus en plus envie de regarder du coté de modx par ex qui reste dans une syntaxe plus PHP, plus habituelle je trouve. Surtout que la future version 2.0 sera full PHP5 et POO.

    Répondre
  3. NiCoS

    @Nicolas : ont-ils vraiment cette préoccupation en tête quand on voit que la mémoire nécessaire pour l’utilisation de SPIP a considérablement augmentée apparemment avec la dernière version (vu sur spip-dev) ?

    c’est une question et non une tentative de troll…

    Répondre
  4. Nicolas Hoizey

    @NiCoS: Euh… demander un peu plus de 8 Mo pour fonctionner, ce qui a lancé la discussion sur spip-dev, c’est vraiment un mauvais signe, quand on voit tant d’autres applications PHP qui ne fonctionnent pas avec 16 Mo ? 😉

    Concernant le support full PHP5 et POO, cela suppose d’abandonner le support de PHP4, mais une fois de plus, je pense que c’est surtout une question de réponse spécifique à des besoins spécifiques. En exagérant un peu (beaucoup), faire à tout prix de la full POO, ce serait comme utiliser Documentum pour gérer 3 pages de contenu… 😉

    Et quoi qu’il en soir, contrairement à bien d’autres, l’équipe de SPIP se focalise plus sur le fonctionnel et le service rendu aux utilisateurs que sur la « beauté » technique du code, c’est sans doute aussi pour ça que tant de gens, pas du tout techniciens et enclins à regarder le code, adorent cet outil.

    Répondre
  5. NiCoS

    En même temps, j’ai très peu suivi la discussion et il me semblait avoir vu des chiffres plus important. Autant pour moi donc 🙂

    Que le fonctionnel prime sur le technique ne me gène pas plus que ça. C’est plus la pérennité du projet qui me laisse perplexe de temps en temps.

    Répondre
  6. Nicolas Hoizey

    Non, non, c’était vraiment quelqu’un qui disait que SPIP ne fonctionnait plus sur son hébergement limité à 8 Mo, ce qui est de plus en plus rare. Des évolutions ont du coup été faites pour charger moins la mémoire quand c’est possible, mais je ne sais pas si on est retombé sous la limite fatidique.

    Côté pérennité, je ne voit pas ce qui peut menacer SPIP !

    Répondre
  7. Committo, Ergo Sum

    Les affirmations contenues dans ce article sont assez surprenantes.

    Depuis la 1.9, SPIP utilise JQuery, utilitaire infiniment plus gros que
    SafeHtml. Pourquoi ne pas citer le premier (qui montre que
    SPIP utilise des briques externes contrairement à ce qui est dit),
    et citer le second (qui est plutôt un contre-argument, car c’est un projet arrêté ce qui montre que justement la croissance externe, comme on dit, n’est pas toujours un bon plan) ?

    En ce qui concerne l’interface aux bases de données, pourquoi ne pas avoir lu l’article expliquant ce choix (http://www.spip.net/fr_article3683.html) avant d’afficher le smiley de la déception ? Si justement il y a déjà autant d’ORM, et nous ne faisons qu’en rajouter un de plus, c’est qu’aucune n’est entièrement satisfaisante, aucune n’est disponible aussi largement que PHP lui-même alors que SPIP doit pouvoir tourner partout. De plus, la majeure partie du travail a consisté à abstraire le code MySQL du cœur de SPIP, travail qui aurait dû aussi être fait si on avait utilisé un ORM, le portage sur les différents serveurs SQL étant ensuite assez trivial.
    On pourrait d’ailleurs facilement porter l’interface SPIP/SQL sur un ORM, et c’est peut-être ce qui sera fait un jour si l’un d’eux remplit un jour les critères que nous jugeons indispensables.

    Pourquoi dire ensuite que SPIP s’est mis au modèle objet, alors que ce n’est pas le cas, et que ce n’est pas une preuve de mauvaise qualité. On a fait et on fait encore de la très bonne programmation sans ce soit-disant modèle (par exemple Linux et Apache, excusez du peu). Quiconque a vécu l’arrivée de ce modèle dans l’univers de l’informatique sait que ses vertus sont largement surestimées par rapport à des disciplines de programmation ayant moins recouru à l’intox publicitaire sous toutes ses formes, mais étant au moins aussi performantes (et à propos de performances, celles du modèle objet de PHP sont particulièrement mauvaises, donc la question des ressources nécessaires que vous évoquez également en aurait aussi pris un coup).

    Je retiens plus la remarque quant au modèle MVC (bien qu’à nouveau on se serait passé d’une intox publicitaire qui cherchait à masquer tout ce que cela devait au modèle Print-Eval-Read de Lisp). SPIP est un projet collaboratif qui se veut ouvert au plus grand nombre; partant imposer à qui veut collaborer un savoir encyclopédique des langages et pratiques de l’informatique irait contre ses objectifs. Le recours à une architecture genre MVC s’est imposée naturellement avec le temps, lorsque le besoin de mutualisation et de surcharge est apparu. Il est bon de redécouvrir par soi-même les raisons profondes d’une technologie. C’est ce qui a empêché SPIP de céder aux effets de mode, et lui permet d’attirer autant de contributeurs qui ne prétendent pas détenir la vérité de l’informatique, et ont du coup plaisir à faire avancer ensemble le projet. Pourquoi s’en plaindre ?

    Répondre
  8. Olivier Mansour

    Committo, Ergo Sum, merci pour ces précisions. Je comprend bien qu’il n’est pas facile, compte tenu des contraintes que SPIP s’impose (PHP4, faible empreinte en RAM) d’utiliser des logiciels tiers. Ce que je comprend moins c’est la volonté manifeste de ne pas le faire pour d’autre raisons que celles citées plus haut.

    Donc en plus de ne pas utiliser de briques externes (la philosophie « do it yourself » comme dirait Jacques P) la communauté SPIP considérerait de manière suspecte les pratiques de programmation moderne ? Désolé, mais je trouve toujours ça vraiment déconcertant (comme considérer la programmation objet comme un effet de mode !!).

    Ceci dit je trouve SPIP très bien pour ce qu’il est sensé faire. Ce n’était pas mon propos.

    Répondre
  9. Committo, Ergo Sum

    Il me semble pourtant avoir été clair: ce n’est pas la programmation moderne que je considère comme suspecte, ce sont les raccourcis à l’emporte pièce qui prétendent que le pire des programmes écrits dans un modèle objet sera toujours meilleur que le meilleur des programmes écrit sans ce modèle. Ce qui compte c’est d’avoir une discipline de programmation claire; on peut en avoir une même quand on code en binaire, et on peut ne pas en avoir même quand on code dans un modèle objet. Mais évidemment juger un programme en lisant vraiment le code, c’est autrement plus prenant que de porter des jugements à l’aide de critères superficiels.

    Point supplémentaire, le mot « objet » est par définition très vague, et quand on interroge les informaticiens pour savoir ce qu’ils entendent par là, on n’obtient jamais la même réponse, et rarement autre chose que le renvoi à un exemple, au lieu d’une définition claire. Quand de plus on regarde de quoi est fait une extension objet, on s’aperçoit que c’est facile à simuler avec des variables statiques et des fonctions calculées. C’est ce qui me fait dire que son importance est surestimée tellement c’est trivial, et que nous le simulons quand nécessaire.

    Enfin je répète que nous utilisons des briques externes, mais que les problèmes d’installation et de performances restent une priorité. Quel inconvénient cela a-t-il ? Encore une fois c’est le débat croissance interne / croissance externe que connaissent aussi les entreprises commerciales, et on sait bien qu’il n’y a pas de réponse toute faite à cette question.

    Répondre
  10. Olivier Mansour

    ha ! que c’est fascinant !

    Je n’ai pas dit : « le pire des programmes écrits dans un modèle objet sera toujours meilleur que le meilleur des programmes écrit sans ce modèle ». Mais par contre j’adhère à l’affirmation que « le pire des programmes sera toujours moins pire si il utilise la programmation objet, le MVC, les design pattern etc… ». Mais c’est peut être céder à un effet de mode …

    « Quand de plus on regarde de quoi est fait une extension objet, on s’aperçoit que c’est facile à simuler avec des variables statiques et des fonctions calculées. » -> tout de même ! C’est le genre de réflexions à plomber le moral de générations de développeurs. :-p

    et oui, c’est vrai les objets et le procédural à la fin ça devient du code binaire, quelle différence alors ? (cette vielle blague !).

    Sinon content de voir que même sur mon modeste blog, le « SPIP spirit » reste vivace. Longue vie à SPIP.

    Répondre

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s