Thomas Douillard a écrit 9164 commentaires

De bon matin, René se rendit tant bien que mal
au garage associatif réparer sa voiture qui marchait pas génial

Intéressante occasion à pas cher,
tentante occasion pour des poches un peu trop claires.

Initiative avortée faute de standards ouverts,
le garage ne pouvait pas s'offrir la mallette propriétaire.

C'est fichu pour tes envies libertaires,
un pas de côté, te v'la embarqué.

T'étais pourtant bien dans la légèreté du code
télécharger, copier, améliorer, faire toi même
et profite que d'autres la liberté aiment
que d'autres puissent améliorer cette ode.

Fais attention au propriétaire,
il pourrait te chiper tes terres.

punycode(Firefox ne peut trouver le serveur à l'adresse la-flemme.saimal.fr.).saimal.fr

PS: ce commentaire ayant été conçu à la RACHE extension flemme, le lecteur est invité à calculer le résultat de la fonction punycode lui même.

La devise shadok Plus ça rate et plus on a de chances que ça marche a des chances de marcher du coup. On peut lui reconnaître un certain sens de la persévérance, ce qui n'est pas forcément inutile pour faire prendre un projet.

Désolé, j'aurai du être plus précis dans ce que je voulais évoquer : je parlais en l'occurence de la possibilté d'étendre le langage avec des "macros syntaxiques" : http://ojs.statsbiblioteket.dk/index.php/brics/article/viewFile/20151/17772

Ce type de macro permet d'étendre le langage lui même par un système prévu pour à la base. Sinon je dis depuis le début qu'en mélangeant les compétences des différentes communauté on peut très certainement faire un truc bien, pas que j'ai une solution toute faite. Le truc c'est que justement on (enfin une partie de) la communauté des informaticiens a trop le nez dans le guidon pour réfléchir autrement, et que la recherche a un peu de mal à faire sortir ses travaux d'une communauté un peu trop restreinte.

Euh, t'es sûr que tu répond à mon commentaire ?

Question de niveau d'abstraction. Linq montre qu'on peut avoir des abstractions simples et puissantes.

Mais à l'origine on parlait de langage "hôte" et de langage "clients" histoire d'éviter les collisions de langage, genre garantir qu'une entrée utilisateur ne va pas injecter de SQL dans une requête construite en SQL. La nécessité pour garantir ça n'implique pas du tout qu'on perde en puissance dans l'expressivité de la dite requête construite en SQL résultante, "juste" qu'on soit capable d'assurer la traçabilité des données utilisateurs entre le moment où ce sont de simple chaînes de caractère et le moment ou on les fait basculer dans le monde du SQL. Et qu'au moment de cette bascule, on soit capable d'assurer que ces chaîne entrée utilisateurs ne vont pas se faire interpréter comme des bouts du langage client (SQL dans notre cas) et donc que l'escaping ait bien été effectué.

Ça n'implique pas du tout qu'on fasse perdre des moyens d'optimiser le SQL si on en reste là dans les principes. C'est uniquement parce que le problème est mal dévoupé et qu'on mélange différents niveau/problème qu'on peut perdre à certains autre niveau, ça n'implique pas du tout que ce soit une fatalité de l'abstraction de problème en soit. Au contraire en fait, souvent on abstrait certaines données du problème qui ne sont pas pertinentes pour ce qu'on veut résoudre pour séparer plus facilement les problèmes …

Quand on dépend directement de l'interpréteur, c'est tout de même beaucoup moins souple si l'on souhaite étendre le système

Pardonne moi mais ça c'est encore une bêtise, tu as lu les papiers que cite https://linuxfr.org/news/tex-et-traitement-de-donnees-par-flot-e01-lire-du-tex ? Je te le conseille, tu verrais qu'il existe des langages dont les macros travaillent au niveau de la grammaire du langage de l'interpréteur, ce qui est un niveau d'abstraction assez élevé et pertinent, qui permettent d'offrir énormément de souplesse sans avoir à se battre avec l'interpréteur puisqu'il est prévu pour.

J'ai voté inutile parce que j'ai vraiment l'impression que je connais ton discours par coeur et que j'ai justement essayé de le contrer avant qu'il n'arrive. Donc j'arrête là, on a déjà tout dit, désolé.

Mouais ton commentaire me fait penser à une méchante dissonnance cognitive quand même "bon ok, il y a des systèmes élégants et très puissants" … qui font partie du langage, donc qui devraient faire partie de son apprentissage, ce qui résoud le problème de "savoir que ça existe".

Mais : PHP dispose de 10aines de systèmes d'abstractions … dont certains bouts peuvent être considérés comme des palliatifs à l’absence de système élégant intégré au langage, et surtout, je veux faire comme j'ai toujours fait et je suis pas spécialement prêt à repenser mes idées toute faites en y intégrant l'apport du nouveau système élégant :p

Du coup, on peut considérer ces dixaines de systèmes comme un inconvénient qui disperse les efforts de dev avec les devs qui réinventent la roue, et une dispersion des compétences des utilisateurs de ces systèmes qui peuvent être confrontés à plusieurs d'entre eux au quotidien.

Le truc du bas niveau, franchement, c'est probablement un faux problème. Parfois le bas niveau c'est utilisé pour pallier aux faiblesses du haut niveau mal conçu … Les perfs, si c'est une abstraction au niveau du langage, il n'y a pas de raison qu'il y ait une pénalisation par rapport aux abstractions codées dans des libs qui sont la pratique la plus courante, au contraire même, donc non je ne pense pas que ce soit un argument non plus.

et en attendant on a toujours pas réglé le problème de base : le langage rend trop simple l'écriture de code vulnérable et oblige à des compétences pour écrire du code non vulnérable.

Mais en l’implémentant au niveau des fonctions SQL de PHP on risque de s'embêter beaucoup plus pour faire des choses simples / voulues aussi, pas que pour la balle dans le pied :).

C'est avec ce genre d'idées reçues qu'on se trouve des excuses pour pas faire d'efforts dans cette direction ;)

Et à bien y réfléchir, prendre des exemple comme "les fonctions SQL" c'est pas le bon niveau d'abstraction. Il faut réfléchir au niveau "langage hôte" et "langage client" pour proposer des mécanismes au niveau langage. Et regarder ce qui se fait ailleurs, genre Link en C#. https://en.wikipedia.org/wiki/Language_Integrated_Query

Ben justement, "string" c'est un type fourre tout qui peut contenir n'importe quel langage. Un typage un peu plus poussé forcerait à manipuler des strings pré-parsées … ou des bouts d'AST.

Du coup au lieux de concaténer des strings et de les passer à une fonction qui va l'interpréter comme du SQL, si on a tout simplement pas de fonction qui lancent des requête qui ne font pas d'échappement systématique de toutes les strings raw avant de basculer dans le type "fragment de SQL", par exemple, on a déjà probablement moins de problème vu qu'il faut que le dev s'embête beaucoup plus pour aller se tirer une balle dans le pied …

Euh, tu sais le but de faire des tables rondes c'est justement de partager les expériences pour pas réinventer la roue :)

Quelque part si l'industrialisation n'est pas faite, c'est un problème aussi pour la recherche. Il y a sûrement des questions à se poser sur ce qui coince.

Nan mais qu'on sorte pas le cas de PHPmyAdmin pour parler du cas de l'immense majorité des applications qui sont des applis front-end pour lesquels il faut pas laisser l'utilisateur accéder directement à la BDD des comptes bancaires :)

Oui il faut pouvoir débrancher les automatismes de vérif en cas de besoin, mais le cas "par défaut" c'est qu'il faut pas laisser passer les cas ou la vérif n'est pas faite.

et un processus qui ne voulait pas faire ça au départ mais se retrouve à le faire à cause d’une entrée utilisateur malicieuse, est extrêmement complexe.

On cause de ça depuis tout à l'heure, et on est en train de dire que c'est certainement pas infaisable, voire pas si compliqué, peut être même démontrable mathématiquement si tu utilises des techniques … déjà connues. Le scandale justement à mon avis c'est que ce ne soit pas fait.

bah si c'est encore du domaine de la recherche puisque des trucs qui pourraient être assurés par le compilo sont d'énormes sources de failles de sécu, c'est un non sens. Et dire que ça ne concerne que PHP c'est se fourrer le doigt dans l’œil.

C'est un coup de gueule de ma part qui dépasse largement PHP. Selon moi c'est exactement le même type de scandale qui fait qu'on peut encore avoir des buffers overflow en C alors que c'est une classe de problème largement connue et étudiée, sur laquelle on a tout dit ou presque.

Ce sont des problèmes que la profession devrait prendre à bras le corps, bosser réellement avec des chercheurs sur les spécification des langages et les outils associés. En parsant une entrée en fonction de la grammaire d'un langage, qui devrait être spécifié, on devrait pouvoir avoir une solution générique qui vérifie qu'une chaîne ne s'interprête pas dans ce langage. En typant les variables chaîne pour les annoter avec le langage qu'elles sont supposées contenir, on devrait pouvoir vérifier qu'une fonction qui va générer du SQL ne reçoit pas une entrée qui n'est pas de type "entrée qui est passé par la fonction qui vérifie que la chaîne n'est pas du SQL" …

Sauf qu'on a jamais vraiment su faire parler des chercheurs qui font des langues formelles avec l'industrie sérieusement comme la Méthode_B, les gens qui font des langages comme Haskell ont du mal à parler avec des gens qui font de la vérification … C'est pas les compétences qui manquent. Faut arrêter de se chercher des excuses et se mettre à bosser là dessus sérieusement.

N'importe quoi, on utilise juste pas les bonnes méthodes : les méthodes formelles. On apprend à la fac/l'école les notions de différent langage/d'automate de reconnaissance qui font partie des principes de base.

Et on est pas fichu de spécifier l'ensemble des langages qu'utilise une fonction / une librairie, et de faire des outils qui sont capable de te dire que tu utilise une variable qui provient des entrées extérieures que tu refile sans avoir utilisé de fonction de nettoyage au préalable ?

Faut arrêter l'amateurisme d'urgence.

En cherchant un peu dans mémé Julia on peut sûrement trouver les courbes de mémé Léna.

le choix n'est jamais laissé: si on ne va pas de l'avant, quelqu'un d'autre le fera avant nous et nous serons forcés par la suite de nous soumettre.

Je pense pas que ce soit la raison prépondérante. Le côté "on est obligé de se soumettre" est parfois carrément une conséquence de choix qu'on a fait (ou nos ancètre) dans le passé qui ont des répercutions qu'on avait pas du tout envisagé à l'époque, des "effets secondaires" comme la pollution ou le réchauffement climatique.

Du coups des îles ou des peuplades qui ont très peu participé se retrouvent embarquées dans une aventure un peu malgré elles : http://www.lemonde.fr/planete/article/2015/12/11/cop21-une-nuit-de-negociations-en-tweets_4830191_3244.html

La machine s'est emballées et on va peut être devoir régler des problèmes posés par la technique par d'autres techniques. La doctrine progressiste veut que ce soit une sorte de fatalité et que le progrès résoudra bien les problème qu'il engendre. Rien n'est moins sûr.

Entre les bonnes nouvelles électorales et les états d'urgences, le terrorisme et les nouvelles mitigées de la COP ? Lisez une news G'MIC et vous reprendrez foi en l'humanité.

Tu mens.

Dans ce cas on peut prendre les choses en sens inverse : si vraiment tu peux pas supporter les puzzles en conditions extrême, tu choisis un autre métier même si c'est bien payé :)

J'avais vu une autre explication : le salaire joue peu sur les tâches ou il faut réfléchir, parce que le défi intellectuel est une motivation en soi, et c'est pas soudain parce qu'on a doublé un salaire que la solution va te venir comme par magie.

Par contre pour les boulots répétitifs et un peu chiant, la motivation financière fonctionne pour améliorer la vitesse d'exécution. Il suffit d'aller un peu plus vite pour gagner plus. Pour résoudre un problème complexe c'est totalement différent.

Éternelle question, est-ce qu'on peut être démocrate avec les ennemis de la démocratie, être ouvert avec les ennemis de l'ouverture ?

En tout cas on note que comme d'habitude, on a le droit de pas aimer les étrangers d'un côté, mais si on veut pas du Front National on est fermé d'esprit.

parce que ça n'a pas spécialement d'impact et que le logiciel reste libre. Après c'est aux électeurs FN de savoir si ils ont envie de respecter l'avis du développeur, sinon.

À part ça on a jamais interdit à un auteur de logiciel libre de s'exprimer, et il n'a pas moins le droit qu'un autre. Et pas plus d'être neutre. C'est pas comme si il avait le pouvoir de lire les fichiers que les autres écrivent, et c'est libre donc on peut regarder si il y a une backdoor avant d'utiliser le logiciel si on est parano.

Personnellement je trouve que ça décridibilise des messages qui mériteraient malgré tout d'être entendus…

Si il y a des questions à se poser, elles sont peut être aussi à se poser du côté des moyens disponibles pour ce genre de recherches. J'ai fortement l'impression que ces moyens sont sans rapports avec ce qui peut se donner dans d'autres domaines, la physique par exemple. Est-ce que ce ne serait pas aussi le résultat d'un mépris pour les sciences humaines qui fait qu'elles ont peu de moyens, et ainsi de suite peu de résultat, donc sont méprisées en retour pour leur faiblesse ?

Je pose la question, je suis pas capable de donner des chiffres de financement. J'ai juste l'impression que les moyens pour faire des expériences sont considérables (tu parles de taille des échantillons) et surtout très compliqués à mettre en place, sur des temps très longs genre au moins 20 ans sur des populations sur lesquelles on a aucun contrôle expérimental et qu'on doit donc se contenter d'observer.