• [^] # Re: Pourquoi du théorie des patch c'est bien

    Posté par . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 2.

    Il est vrai que prendre C et Unix comme point de comparaison est étrange

    Je n'ai pas comparé Pijul à C. Il faut replacer mon commentaire dans son contexte. J'ai utilisé cet exemple pour montrer que la difficulté d'utilisation n'était pas une condition nécessaire à la puissance d'un outil, et que C a vite remplacé ses prédécesseurs parce qu'il était beaucoup plus facile à utiliser sans être moins puissant.

    Bien entendu, aujourd'hui, après plein d'innovations sur les langages, et d'innombrables couches de re-standardisation, certaines des idées de C et d'Unix ont perdu de leur élégance, semblent moins canoniques ou un peu vieillottes.

    Ça n'enlève rien à mon argument, puisqu'il se référait justement à l'époque où C est sorti.

    quand on sait que le créateur de git n'est autre que Linus Torvalds

    Je n'ai jamais nié les compétences techniques ou la vision de Torvalds. Mais je sais ne pas être seul à juger Unix (et C) élégants et Git pas du tout élégant. Il ne me semble pas choquant que des superstars de l'implémentation de systèmes d'exploitation (qui ont toute mon admiration) ne soient pas nécessairement experts en théorie de la concurrence.

    (on pourrait aussi remarquer que Linus Torvalds n'a créé ni C ni Unix)

    Bien que j'ai déjà lu des personnes défendant la position (qui se tient) que C est un langage fonctionnel pur.

    Je ne sais pas si c'est une blague, mais si je lis ce lien, j'y trouve cette phrase :

    As with any purely functional language, cpp consists only of (nestable) expressions, not statements. Now here’s the clever part: when evaluated (not executed), a cpp expression yields a (pure) value of type C, which is an ADT (abstract data type) that represents imperative programs.

    Ça me semble faux : en CPP, suivant l'ordre d'évaluation des macros, on peut tomber sur du code différent (avec des sémantiques différentes).