LupusMic a écrit 1481 commentaires

On touche le fond \o/

« Pourquoi utiliser des mots de passe complexes ? Pourquoi sécuriser mon poste de travail ? Je ne suis pas connu, personne ne veut prendre le contrôle de mon ordinateur ! »

C'est quelque chose que j'entends souvent. Et là, il faut que j'explique qu'il y a des robots qui scannent automatiquement les machines sur l'Internet, à la recherche de failles.

J'ai un jour eu la mauvaise idée de créer un utilisateur dummy, avec mot de passe dummy. Plusieurs mois après avoir oublié l'existence de se compte, j'ai installé SSH pour pouvoir accéder à ma machine depuis le boulot. Il n'a pas fallut longtemps pour que je découvre un script tentant de décrypter mon shadow.

Non, je ne confonds pas. Si tu regardes les ressources que j'ai fournit dans mon précédent message, il est question de foncteurs et autres barbarismes issus des langages fonctionnelle.
Si j'ai bien compris le paradigme fonctionnel, il permet avant tout de parcourir des collections et d'en générer d'autres, sans toucher à l'état de la collection initiale, et donc de pouvoir utiliser la composition de fonction.

std::transform(orig.begin(), orig.end(), dest.begin(), dest.end(), compose<f, g>()) ;

Une discussion intéressante avec Herb Sutter et Bjarne Stroustrup où est abordée l'aspect fonctionnel de C++ : http://www.informit.com/articles/article.aspx?p=1332753

je te concède qu'il sont plus nuancé que moi. Mais je ne fais pas dans la nuance. ;) Ceci dit, Sutter, Meyers et Stroustrup affirment l'intégration du paradigme fonctionnel dans leurs livres. Je chercherais les passages ce WE.

Quel bout-en-train !

Je n'ai manqué de respect à personne, j'ai émis une critique acerbe sur un point qui me hérisse le poil.

Je ne lis jamais les journaux publiés sur DLFP. Pourquoi en ferais-je un moi-même. Je préfère venir débattre plutôt que de râler dans mon petit coin (sur mon petit piédestal).

Je ne connais effectivement pas ce point précis du code, ça fait un moment que je n'ai pas fouiné dans Gecko.

Je m'en fous de connaître ou non la personne avec qui je discute. Ce qui m'intéresse c'est la discussion, le débat (voir le troll), les arguments échangés. Pour l'instant je m'en prends plein la gueule parce que je déplore un état de fait.

De plus, j'en veux bien plus à ceux qui m'encensent qu'à ceux qui me critiquent ouvertement. Ces derniers me font avancer, évoluer, plutôt que de croupir dans la médiocrité.

Ben non, justement, pas dans ce fil de discussion : https://linuxfr.org/2011/01/19/27791.html#1201207

Je n'ai pas dit que je n'ai jamais de bogue. D'ailleurs, statistiquement, il y a toujours de bogues.

Quand on arrive après la bataille, on compte les morts, on tire les leçons des erreurs commises. C'est un travail important, qui est souvent négligé.

Au passage le code tournait avec certains drivers

Ce code compile et « tourne » :
#include <string.h>
int main()
{
char * orig = "toto", dest ;
strcpy(&dest, orig) ;
}

Bon d'accord, cet exemple n'est pas du même tonneau. Mais imagines-tu faire un *scanf, un write, un read, un open, etc sans vérifier qu'ils ont bien retourné une valeur attendue ? Non, évidement que non. Parce que les développeurs qui ont un peu de bouteille savent que ne pas contrôler le résultat d'une fonction, c'est s'assurer une consommation excessive de paracétamol dans un futur plus ou moins proche.

Et c'est uniquement cela que je critiquais.

Planter dans quel sens ?

Lorsqu'en C une fonction segfault, je considère d'abord que c'est de ma faute. Parce qu'en C il est parfois difficile d'utiliser une fonction correctement. Du genre, fournir une zone mémoire non-allouée ou non-initialisée. Un segfault dans ces cas-là est évidement salutaire (c'est toujours pire un programme qui tombe en marche), et quelque soit la localisation du segfault. Si memmove plante, je ne vais pas râler contre UNIX/POSIX.
En l'espèce, dans le présent thread, on parlait des fonctions OpenGL qui échouaient, et que le développeur a ignoré de vérifier le retour. Les crash du serveur X (ou d'un module noyau s'il y a) n'étaient pas considérés. Il est évident que l'utilisateur des fonctions ne peut rien faire si elles partent totelement en couille, malgré la rigueur du développeur.

Je ne peux constater qu'avec effrois que l'époque où les contributeurs aimaient la qualité et la rigueur, avaient une exigence en regard des logiciels propriétaires, est belle et bien révolue sur DLFP. Toute critique franche d'une pratique misérable (la programmation à la truelle, en l'occurrence) est violemment réprimée par la masse. C'est déplorable.

Planté dans quel sens ?

Un segfault n'est évidement pas rattrapable. Une fonction qui échoue renvoie un code d'erreur, qui est toujours testable.

Dans les prototypes je prends des raccourcis. Et encore, ce n'est pas toujours une bonne idée, parce qu'on perd souvent plus de temps à chercher des erreurs à la con, alors qu'on aurait eu le message d'erreur immédiatement si on avait gérer l'erreur au bon endroit.

Ceci dit, je ne vois pas pourquoi tu t'emportes sur mon commentaire. Ce que je relevais, c'est la phrase « il reste que les drivers ne sont jamais censes planter ». C'est bien ça qui me pourri quotidiennement la vie. Avec des développeurs, collègues ou non, qui suppose que ça ne vaut pas le coup de se casser la tête à vérifier le retour des fonctions. C'est un peu pour contrer ce genre de comportement qu'on a d'ailleurs inventer les exceptions, histoire que ce ne soit pas aussi facilement ignoré.

Personnellement, je préfère dégoûter un souillon plutôt que de le soutenir dans l'erreur. On a assez de code sale, impossible à maintenir et a fortiori bourré de faille de sécurité pour se payer le luxe de soutenir ceux qui en rajoute.

Systématiquement, quand j'utilises une fonction qui peut générer des erreurs, je les gère.

Et l'ouverture d'un fichier n'échoue jamais. Et il y a toujours de l'espace disque disponible. Il y a toujours de la mémoire disponible. Pourquoi s'embêter à tester le retour d'erreur des fonctions appelées ?

C'est un peu comme l'idée d'utiliser des accents.

Je ne sais pas depuis quand, mais depuis longtemps. L'en-tête functional fournit la plupart des outils pour faire de la programmation fonctionnelle en C++ :
http://www.cppreference.com/wiki/functional/start

À noter que le tout est amélioré dans C++0X grâce au travail réalisé dans Boost.Functional http://www.boost.org/doc/libs/1_45_0/libs/functional/index.h(...)

C'est bien pour ça que la France est un pays riche.

Si le budget de la France s'effondre, tout ceux qui auront prêté à la France l'auront dans l'os. Donc, il faudra toujours qu'ils prêtent à nouveau à la France.

Nous ne rembourserons jamais la dette, car la dette est structurelle au capitalisme. Il n'y a actuellement aucun autre outil que le capitalisme pour développer l'économie. Le principe du capitalisme, c'est d'emprunter pour pouvoir créer de la richesse. la richesse est ainsi redistribuée à ceux qui l'ont permises : les investisseurs et les travailleurs. Je ne dis pas que c'est sain, mais c'est un système qui fonctionne plutôt bien.

En ce qui concerne l'expression « vivre au-dessus de ces moyens ». J'ai tendance à le dire de manière assez arrogante, mais je n'ai jamais dépensé ce que je gagne, je gagne ce que je dépense. Vivre au-dessus de ces moyens permet d'élever son niveau de vie, alors que vivre comme un pauvre ne permet qu'une seule chose : accepter sa condition et ne pas en sortir.

> Déjà dans les années 70, de talentueux programmeurs avaient démontrés tous les défauts de ce type de langages.
Source ?

> Le principal étant la persistance des données.
Un exemple ?

> L'objet est une mode qui consomme la puissance phénoménale de nos ordinateurs actuel
Je dirais plutôt que ce sont les conditions économiques qui poussent à ne pas créer des programmes performants, mais utiles.

> sous le fallacieux prétexte, de la réutilisabilité du code ( qui est très faible aujourd'hui !! ).
Source ?

> Les langages fonctionnels sont mieux pour la réutilisation raisonnée du code, et de plus elle
peut aussi se concevoir en procédural classique.!
C++ est un langage qui intègre le paradigme fonctionnel.

Rappelle-nous un peu quand le Nobel a été institué ? :)

Sauf que ce n'est pas une base noSQL C'est un format structuré de stockage, comme CSV, XML, JSON ou BSON, etc. Ça peut faire office de backend de stockage pour une base de données SQL ou noSQL.

Un exemple assez éclairant est MySQL, qui peut utiliser BerkleyDB (un équivalent de Rec dirons-nous) pour stocker les données qui ont été traitées via des requêtes SQL.

La véritable guerre entre les bases se réclamant de l'héritage relationnel et les bases s'en affranchissant, c'est la manière dont gère l'accès aux données, leur répartition, et la gestion de l'intégrité de ces données (les compromis ne sont pas les même).

C'est vrai que c'est le seul projet qui n'a pas bénéficié du tampon Oracle. Tout les autres projets sont renommés progressivement à l'occasion de la sortie d'une release majeure.

Mais au delà de ce troll, il y a tout de même la réponse de MySQL AB aux serveurs dictionnaires (clé-valeur) qu'est HandlerSocket. Le principe est de contourner le parser de requête SQL pour directement servir les données en fonction d'une clé. Je n'ai pas encore eu l'occasion de tester, mais c'est une réponse intéressante de la part de MySQL aux jeunes bases de données servant des documents.

Et le compromis entre fonctionnalité et performance fait reculer le moment à partir duquel on va s'orienter vers un foutoir tel que MongoDB ou tout autre base d'objets.

Pour les plus curieux : http://planet.mysql.com/?tag_search=9762

Ce qui est exotique, c'est de voir du Lisp habillé en C.

Des spécifications ? Pourquoi faire ? :D

Je crois que c'est la principal question à se poser : pour quel usage le langage d'apprentissage doit-il être choisi ?

À mon avis, je pense qu'il faut d'abord faire le point sur soit-même. Savoir où on en est dans les langages qu'on connais, quels sont les paradigmes qu'on y applique et lesquels on ignore totalement.
Par exemple, le C++ a de nombreux paradigmes, et de nombreuses techniques sont liées à ces approches. Elles permettent d'emprunter plusieurs voies pour appréhender et résoudre un même problème. Mais telle ou telle approche sera plus apparente dans un autre langage. Par exemple, la programmation fonctionnelle en Javascript m'a permis de comprendre et de maîtriser le contenu des en-têtes algorithm et functional. Python me permet d'avoir une approche plus directe et d'explorer la programmation orientée objet sans devoir souffrir du typage statique. Même si en Python, l'absence d'encapsulation (ce qui me pousse à considérer Python comme un langage absolument pas orienté objet) et le passage par référence par défaut (sauf exception) est parfois surprenant.

PHP m'a permis de manger quelques temps. C'est le premier langage dans une optique professionnelle que j'ai assimilé. C'est là encore un autre but dans l'apprentissage du langage : quel est la technologie qui me permettra de bien manger (parce que bon, du boulot pour les développeurs, il y en a beaucoup).

Un troisième objectif peut être la découverte absolue. Apprendre un nouveau langage dont on sait déjà ce qu'on va y trouver n'est pas forcément très intéressant. Le conseil du livre cité est agrémenté d'arguments et de raisons pour lesquelles il faut apprendre de nouveaux langages, mais pas seulement. L'auteur conseil aussi de s'intéresser à d'autres champs de connaissances. C'est ainsi qu'on produit des réponses originales, inédites, à des problèmes qui n'ont reçu que des réponses insatisfaisante.

Pour l'année à venir, je pense continuer à apprendre C++0x et Python 3. Mais aussi solidifier mon expérience en Javascript. Car comme c'est parti, 2011 sera l'année du Javascript (HTML5, Node.JS, MongoDB, CouchDB, etc).

On en a pas parlé, mais les langages de traitement de flux texte (awk, XSL) et de grammaire (bison, EBNF) sont autant de langages délaissés parce qu'on en voit pas l'utilité intrinsèque. Jusqu'à ce qu'on en ai besoin.

Et pourquoi pas un peu d'assembleur ? :D

Moi j'attends de voir les fork de Pylons pour assurer la pérénité des applications qui ne pourrons pas migrer ;)

Pourtant, quand on a un HTTP > 400, la première des choses à faire est de regarder les logs. Alors qu'est-ce qu'ils disent ?

Je suis au courant de ces détails. Ça ne change rien au principe de base : les végétaux se « nourrissent » de dioxyde de carbone.

Les autres éléments et composés chimiques, c'est dépendant de la plante. Mais surtout, j'ai du mal à les considérer comme des nutriments. Ce sont plutôt des compléments alimentaires qui améliorent ou permettent la croissance. Au même titre que les vitamines, ce sont plus des dopants et stimulants que des aliments.

Quand au dioxygène solide, j'ai fait assez de chimie dans ma jeunesse pour savoir que ça risque d'être un peu violent pour la flore terrestre.

Les engrais permettent de faciliter la croissance des plantes. Ce ne sont pas des aliments, même si l'imaginaire populaire continue de relayer cette vision.

Et wikipedia n'est pas une source, ni une référence.

Tu es au courant que les plantes mangent du CO2 et non de la terre ? Tu as déjà entendu parler du concept de culture hydroponique ?

Que la qualité du sol diminue sous l'intensité de la culture, c'est un fait. Mais ce n'est pas un appauvrissement.