LupusMic a écrit 1481 commentaires

Ce qui me déplaisait fortement à l'époque, c'était le paradigme de sauvegarde systématique dans la base de données de l'instance applicative. Et puis, il faut avouer que j'avais déjà du mal à gérer C et PHP, alors ajouter un autre langage par dessus ça me faisait un peu peur. Je sais aujourd'hui que c'était une erreur, mais bon, il faut en faire.

Bref, je n'ai dû entendre parler de MVC qu'en 2003/2004, quand la mode a atteint PHP. Donc oui, pour moi MVC et le web, c'est bientôt 10 ans, mais pas tout à fait :-D J'avais déjà entendu parler d'architecture 3-tiers, mais pour moi ça désignait la trinité front-back-rdb, plus ou moins.

C'est surtout du Java, il n'y a que des gens sérieux qui font du Java.

Je ne trouve plus où je me suis disputé à propos du choix de retourner dès que possible ou en un seul point. Ce ne doit pas être si récent que ça ^;

Donc ce n'est pas un problème d'utiliser des float pour gérer des comptes (d'argent) ? :-D

Peux-tu citer un framework web MVC qui a au moins 10 ans ?

Ce n'est malheureusement pas du bon sens. N'oublions pas que le bon sens est la logique du pauvre : c'est évident, donc c'est vrai. Bien souvent, l'évidence est l'ennemi du développeur.

Et tout le monde ne partage pas le même "bon sens". Certains vont considérer un return par fonction comme étant du bon sens. D'autres vont considérer qu'il faut sortir le plus tôt possible (bien sûr, en C, on peut sortir le plus tôt possible et un seul return avec un goto). Ceux qui m'ont moinsé allègrement dans une discussion sur du code PHP pourri sont de la seconde école.

Donc oui, il faut l'écrire. Mais il faut aussi le justifier, sinon ça ne sert à rien.

J'ai respecté le kilo ? Wunderbar !

Ceci dit, ayant lu le Stroustrup, une livret de 200 pages ne me fait pas flageoler les jambes ;)

Tu imagines mal.

En fait, l'auteur de DMMT soutiens que les internautes sont des gens pressés, que de par sa nature immédiate et simple, le Web entraîne une impatience de l'internaute. Lorsqu'un internaute découvre une page web pour la première fois, il va jauger le niveau d'intérêt de la ressource à l'aide d'un certain nombre de critère. Le temps d'affichage est l'un des premiers. Puisque les internautes sont des gens pressés, une page qui met plus d'une seconde à s'afficher contribue à l'agacement de l'internaute. C'est d'ailleurs une des raisons qui ont poussé Google à intégrer ce paramètre dans le calcul du ranking. Le second concerne la clareté de l'interface : à quoi sert le site, comment accéder aux ressources, etc. C'est ainsi qu'il ne faut pas raconter sa vie, ne pas encombrer l'interface avec du texte inutile, qui n'est là que pour que le créateur du site se branle la nouille. Le livre aborde différents éléments qui ne nous intéressent pas ici, mais c'est un must read pour tout professionnel du web qui se respecte.

Bref, le site de Seenthis mériterais d'être revu, pour que les gens s'y intéresse. D'ici là, le taux de rebond restera très élevé.

J'habite et travaille en Irlande. Et je ne ressens pas mon manque de maîtrise de l'anglais comme un handicap.

L'anglais est la lingua franca en informatique. Il ne faut pas s'étonner d'avoir un web en retard de 10 ans sur le reste du monde quand on continue à ne considérer que les ressources francophones.

Je te conseille la lecture du formidable http://sensible.com/dmmt.html

Et oui, 5500 signes, c'est long sur le Web, surtout pour un document promotionnel.

Au temps pour moi, il y a des mentions légales illisibles inaccessibles depuis la page d'accueille, mais à la suite d'un long et inintéressant article :D

Je crois que les gars qui ont créé le contenu éditorial aiment se lire. Il y a trop de texte, c'est totalement incompréhensible.

Quand on va sur le lien pour savoir ce qu'est seenthis, on a un immense pavé qui nous explique ce que c'est. Sans respiration, sans capture d'écran. On est sur le web, il faut faire court, surtout quand on prétend être sur un outil de microblogging.

Ensuite, quand on va dans la section « le minimum à savoir », on a un document qui est d'à peine un tiers plus petit. Franchement, ça ne vas pas encourager le Skybloger à venir raconter sa life.

Par contre, pas un mot sur la vie privée, pas de mentions légales, etc

SPIP, avec PEAR, a toujours été pour moi le symbole de ce qu'il ne faut pas faire en développement web. SPIP, effectivement parce que c'est écrit en Français, et parce que la sécurité n'a jamais été au cœur de la philosophie de développement. On se souviendra avec nostalgie des nombreux trolls qui ont accompagnés son existence.

Maintenant, tu viens nous parler d'une autre horreur qui s'impose dans le monde PHP : la Javaïfication. Si PHP a eu du succès, c'est entre autres parce que ça permet de faire des trucs assez dégueulasse, en peu de temps. Venir vouloir y imposer son ordre arbitraire, ce n'est pas forcément une bonne idée. Moi j'aime développer en orienté objet, donc j'écris des fonctions. Ça peut sembler bizarre à quelqu'un qui n'a jamais fait de C++, mais dans les véritables langages orientés objets, on considère que le polymorphisme n'est pas forcément une propriété liée à une classe (voir le polymorphisme statique apporté par les fonctions template).

Je n'aime pas PSR0 ou même PSR1. Tout d'abord, parce que ça contraint à faire du CamelCase illisble. Oui, je suis handicapé et j'ai toutes les difficultés à lire le CamelCase. Un peu comme j'ai du mal à lire du code dont les phrases s'allongent sur plus de 70 colonnes, avec plus de deux imbrications, et des fonctions de plus de deux pages. Et cette blague de l'autoload me défrise : quand on ouvre un fichier source, on doit connaître en première lecture ses dépendance par les fichiers qu'il requiert. Vouloir laisser ça au runtime est absurde.

Et puis, je n'ai pas envie d'un environnement où tout le monde fait la même chose. À quoi ça sert d'avoir 10.000 frameworks qui appliquent la même chose ? Dans le monde Python, il y a se genre de blague. Alors d'accord, Pylons, Bottle/Flask/Web.Py et Django se distinguent par une approche de séparation des responsabilité légèrement différente, ce sont trois conception assez différentes. Mais dans l'absolu, elles reposent toutes trois sur une même conception, sur le même design pattern (une chaîne de responsabilité). Dans le monde PHP, aujourd'hui, on a ce phénomène avec Zend, Symphony ou CodeIgniter. Quel est l'intérêt ?

Bref, je continuerais à écrire mon Framework avec des fonctions dans des namespaces, des fonctions en lower case avec des underscores, et des classes et des variables nommées selon la même logique. Parce que, oui, c'est plus joli comme ça.

L'écriture fainéante (et tout processus fainéant, comme l'overcommit memory, COW, etc) est toujours difficile à déboguer, puisque c'est un procédé par nature asynchrone. Et ceci me pose autant de problèmes qu'à toi. Malheureusement, les humains n'aiment pas attendre, et parfois il faut abandonner un peu de fiabilité (oui, ça me fait mal de dire ça) pour un peu de confort (rapidité visuelle).

Je préfère que le programme plante, histoire de ne pas avoir un état incohérent, et que le couillon qui gère l'administration du produit ne se dise pas que ce n'est qu'un « warning ».

Oh oui, mets-moi du singleton là où il n'y en a pas besoin. D'ailleurs, par durée de vie du programme, tu entends une variable statique instanciée lors de la création du process (et donc un comportement indéfini à la clé) ? Oui, le j'ai déclaré le singleton « ennemi public numéro un », puisqu'il est le vengeur masqué de la variable globale.

Ici j'ai pris l'exemple d'une classe qui écrit un fichier pour rester simple. Mais on peut imaginer un ORM, qui flush les données modifiées, ajoutées et supprimées vers la base de données. Dans ce cas, le caractère asynchrone de la communication avec un serveur distant est pertinent, et les exceptions peuvent alors être légion.

Il semble que tu ne comprennes pas pourquoi lancer une exception depuis un destructeur est problématique. Le problème n'est pas le nombre d'exceptions à gérer, mais le fait que la destruction d'un objet est suspendue par la levée de l'exception, et qu'on se retrouve alors avec un objet partiellement détruit, ce qui pose des problèmes de fiabilité.

Non, l'exception n'est pas lancée dans le destructeur. Elle est lancée indirectement depuis le destructeur. Et c'est bien le point que j'essaye de mettre en exergue, et que tu refuses de voir : le RAII c'est très bien, ça permet de mieux gérer les ressources. Mais ce n'est pas magique. Et donc, il faut toujours penser à libérer les ressources dès qu'on peut.

Maintenant, je m'attendais à ce que tu vienne avec une solution qui est encore pire qu'un segfault : attraper l'exception dans le destructeur, et continuer comme si de rien n'était (oui, cracher dans std::cerr revient à ne rien faire). Pourquoi est-ce une mauvaise chose ? Premièrement, parce qu'on ne sait pas dans quel état on est. C'est d'ailleurs pour ça que le programme se termine quand une exception est balancée depuis un destructeur : c'est la panique. Deuxièmement, que se passe-t-il si une exception d'une autre nature est lancée depuis flush ? On pourrait très bien rajouter un catch-all, mais je doute qu'il soit pertinent d'attraper tout et n'importe quoi, et gérer les exceptions n'importe comment.

Alors oui, j'ai déjà vu ça dans du code en production. MongoDB au hasard. Mais ils se définissent eux-même comme des anti-c++ (oui, c'est amusant quand on sait en quel langage est écrit MongoDB), ce qui montre quel type de personnes gèrent la gestion des ressources par-dessus l'épaule.

C'est fou, c'est exactement à cause de ce genre de conneries que je ne comprends pas les power users qui utilisent Mac OS X. L'ergonomie est tellement à côté de la plaque que s'en est pénible.

D'ailleurs, les power user fans d'Apple sont les responsables de la dégradation de GNOME 2 en GNOME 3. Heureusement qu'il y a des initiatives comme Cinnamon.

Prenons un exemple. Imaginons une classe qui prend en charge l'ouverture d'un fichier, et la gestion de son buffer. L'ouverture du fichier est fainéante, l'écriture aussi, et la fonction close lance l'écriture du buffer en dernier ressort. Une exception io_error est lancée lorsqu'une erreur d'écriture est détectée :

// c++ -o throwing_close{,.cpp} --std=c++11
#include <iostream>
#include <string>


namespace my_ns
{
    class io_error
    {
    } /* class io_error */;

    class file
    {
        public:
            // Lazy opener
            static
            file const open(std::string const );

            void flush()
            {
                throw io_error();
            }

            void close()
            {
                flush();
            }

            ~file() /* file is not declared nothrow, no warranty on exception safety */
            {
                flush();
                close();
            }

            // Append content. Open in append mode if file isn't open yet
            void append(std::string const )
            {
            }

    } /* class file */;

    file const file::open(std::string const )
    {
        file new_file {};
        return new_file;
    }

} // namespace my_ns

int main()
{
    std::string content {"Big content that's going to overflow the harddrive"};

    {
        auto f = my_ns::file::open("throwing_close");
        f.append(content);

        try
        {
            f.flush();
            f.close();
        }
        catch(my_ns::io_error const & e)
        {
            std::cout << "Catched exception!\n";
        }
    }

    try
    {
        auto f = my_ns::file::open("throwing_close");
        f.append(content);

        // Destructor called: an exception is thrown from dtor
    }
    catch(my_ns::io_error const & e)
    {
        std::cout << "That can't be catched\n";
    }
}

Le résultat sur la ligne de commande :

mickael@laptop:~/tmp$ ./throwing_close
Catched exception!
terminate called after throwing an instance of 'my_ns::io_error'
Abandon


Alors, évidement, ici la classe est facile à repenser, si toutefois elle faisait quelque chose. Mais imagine une architecture plus complexe, où l'exception safety n'est jamais garantie, où aucune signature n'indique qu'une fonction peut lancer une exception, où la libération d'une ressource peut être complexe et entraîner moult lancement d'exception.

Oui, il faut libérer les ressources dès qu'on le peut, ou des comportement indéfinis sont garantis (ici on notera que l'implémentation tue directement le processus qui aura tenté de lancer une exception depuis un destructeur, il n'est pas possible d'empêcher sa destruction).

Donc non, même en utilisant un objet RAII, il n'y a pas de garantie à ce que la ressource soit libérée si une exception peut être levée lors de l'exécution d'un destructeur.

Je ne pense pas, array_column ne prend pas de référence du tableau en paramètre. Ceci dit, pourquoi un générateur ? pour une microoptimisation inutile qui prend plus de ressource que si on réduit le tableau ?

En fait, ce ne sont pas des cas : le comportement est indéfini.

Et je te renverrai au « Exceptional C++ » de Herb Sutter, qui conseille fortement de libérer une ressource avant de sortir du scope.

{
  auto f = my_ns::file(".");
  // Do stuff that can raise exception
  f.close();
}

Évidement, la ressource devrait être correctement libérée en cas d'exception, mais dans le cas où aucune exception n'est levée, il est tout indiqué de libérer la ressource inutile, pour éviter qu'une exception ne soit lever dans un destructeur.

Quel est le rapport avec RAII ? Même si cette technique permet de libérer une ressource qu'on a oublié de libérer, il est toujours de bon ton de libérer la ressource après usage. Histoire qu'une exception lancée à la libération de la ressource ne vienne pas tout casser dans le destructeur appelant, par exemple.

On préfère perdre deux heures dans les transports quotidiennement plutôt que dans le TGV mensuellement, pour avoir le plaisir de vivre dans une banlieue dortoir sans vie.

Je suis assez époustouflé par cet argument d'une mauvaise fois totale.

Tout d'abord, 50 min reste plus important que 35 min.
Tu ignores le trajet pour mener à la gare de Lille (ce qui est plus gênant).
La dernière fois que j'ai pris le RER de Paris à CdG, j'ai dû payer 5 €… je n'ose imaginer le coût d'un billet TGV Lille-CdG.

La seule fois que je suis allé à Marne-la-Vallée, j'ai évite de justesse la dépression. Jamais je n'irais travailler dans un endroit aussi mort. Plutôt retourner à la campagne, la vraie, avec des véritables villages.

Non, Paris (villes reliées par le métro comprises) est le seul endroit correct en France pour faire vivre une activité de lobbying ou d'évangélisation.

Il ne faut pas sous-estimer le mur économique ou psychologique de ne pas être dans Paris. Quand on dit qu'on est dans Paris, on sait qu'on aura un métro, des bus fréquents, des RER, et des gares recevant la France et au-delà, sans que cela soulève des questions pénibles.

Oh, heureusement qu'il y a l'opérateur +, on a frolé la déclaration de fonction ;)

En C++11, on écriera:

std::vector<std::string> args {argv, argv+argc};