sobriquet a écrit 280 commentaires

  • # Angle mort des langages de programmation

    Posté par  . En réponse au journal [Letlang] Faire la différence entre un nombre et une quantité. Évalué à 2.

    C'est une bonne idée ! Pour moi, la dimension des grandeurs manipulées est un gros angle mort de la plupart des langages de programmation. On peut distinguer 3 cas d'usage :
    * Le contrôle de dimension : lancer une erreur de compilation quand on ajoute une masse à un temps
    * Le contrôle d'unités : même si les dimensions sont cohérentes, ajouter des km/h à des m/s est le signe d'une erreur potentielle
    * La conversion automatique : passer de manière transparente de kg·m·s⁻² à 10 Newton

    Certaines librairies gère une partie de ce travail, je pense en particulier à Pint en Python, mais c'est souvent syntaxiquement assez lourd. J'avais codé une preuve de concept qui permettait une syntaxe assez légère, et qui peut parser toutes les unités du Système International (SI). On peut écrire des choses telles que :

        ma_force = 10 * SI.kg.m.s(-2)   # une force de 10 kg·m·s⁻²
        ma_force < 20 * Si.N              # La force est inférieure à 20 Newton
        ma_force > 10 * Si.m              # On compare une force à une distance, ça soulève une erreur

    Ma preuve de concept ne prend en charge que les unités du Système International, c'est un choix idéologique et d'économie de travail : j'ai tendance à penser que les librairies qui passent par une déclaration préalable des unités répondent à des problématiques essentiellement anglo-américaines. Mais on peut aussi s'adapter en écrivant :

        pied_romain = 296.3 * SI.mm
        ma_distance = 10 * pied_romain

    Je n'ai jamais osé publier cette librairie, entre autres par ce que je soupçonne que le surcoût à l'exécution n'est pas toujours négligeable. L'idéal serait de pouvoir faire ça dans un langage compilé, de manière à ce qu'il n'y ait quasiment plus de surcoût à l'exécution.

    Félicitation en tout cas, tu viens de capter toute mon attention pour ton projet :)

  • [^] # Re: La console developpeur a la rescousse

    Posté par  . En réponse au message Télécharger le contenu d'un site pas commode. Évalué à 3. Dernière modification le 20 février 2022 à 20:56.

    Super, ça répond à l'essentiel de mon problème ! pour les curieux, la totalités des réponses est accessible ici en JSON :
    https://open.efsa.europa.eu/api/calendar/getConsultationCommentSection?consultationId=a0c1v00000HePrzAAF&offset=0&limit=500

    Pour les pièces jointes, ça a l'air un peu plus compliqué, mais ça devient faisable. Merci !

  • [^] # Re: Assumer sa bêtise

    Posté par  . En réponse au message JDLL de Lyon - le Libre est incompatible avec l'obligation vaccinale !. Évalué à 5.

    Je suis allé voir la vidéo. Le passage qui soutient la thèse "les non vaccinés ne saturent pas les réas" commence à 1:01:00.
    L'intervenant commence par un point de rigueur utile : les statistiques utilisées concernent les soins intensifs, et pas seulement les réas.

    Tout le monde se base sur les mêmes données qui disent en gros qu'il y a 10 % de non vaccinés en France et 50 % de non vaccinés en soins intensifs. Ces chiffres concernent toutes les causes d'hospitalisation : covid, accidents, autres maladies…

    Les personnes non vaccinées sont donc bien surreprésentées en soins intensifs, et il est très tentant de faire une hypothèse sur la cause de leur hospitalisation : ils ont fait un mauvais covid.

    Sur 100 lits occupés, 40 lits sont donc occupés par des personnes non vaccinées qui ont fait un covid grave qu'un vaccin aurait évité. Autrement dit, les soins intensifs connaissent une baisse de capacité de 40 % par rapport à leur fonctionnement habituel, pour traiter cette surreprésentation.

    Je laisse chacun apprécier si on peut appeler ça une saturation. Personnellement, j'essaie d'apprécier ça via une comparaison : si une usine fonctionne à 60 % de sa productivité normale à cause d'un problème quelconque, j'aurais tendance à considérer cette situation comme catastrophique, surtout elle s'éternise.

    Un peu plus loin dans la vidéo, à 1:08:20, l'intervenant indique un taux de patients covid en soins intensifs de 18 %. J'aimerais bien savoir d'où il sort ce chiffre, car il est en contradiction avec mon analyse, et d'autres sources indiquent plutôt un taux de 43 %.

    Pour conclure, je ne sais pas sur qui il faut jeter la responsabilité : ceux qui refusent de se faire vacciner ou ceux qui suppriment des lits.

  • [^] # Re: Pour moi, toujours pas d'appli.

    Posté par  . En réponse au message Paiement sécurisé sur un téléphone rooté. Évalué à 5.

    Oui, ça marche aussi chez moi avec le code :) Mais d'une part, je n'ai plus assez de place sur mon écran pour mettre un post-it avec un code de de plus. Et on ne peut pas le changer, donc c'est plus chiant à mémoriser quand on ne fait pas un achat en ligne tous les 4 matins (solidarité avec Mme Michu). Et puis ça me navre de voir la sécurité assurée par un code alphanumérique permanent de 4 caractères et un appareil que je trimballe partout avec moi.

    Mais surtout, j'ai l'impression qu'il faut avoir l'esprit tordu pour considérer qu'un smartphone rooté est moins sûr qu'un autre : je ne crois pas qu'on puisse les rooter par accident, si on le fait, c'est qu'on en a les compétences et qu'on veut bien en assumer la responsabilité. A l'inverse, on n'a pas besoin de rooter un téléphone pour installer un logiciel espion. Pégasus en est l'exemple le plus frappant, mais on peut aussi penser à des choses plus ordinaires et tout aussi problématiques : les téléphones Android espionnent constamment leurs utilisateurs et transmettent des informations sensibles au développeur du système d'exploitation.

    C'est surtout ça l'objet de mon message : comprendre comment ils peuvent raisonner ainsi, juger de la pertinence de leur position, et le cas échéant développer un argumentaire adapté. Parce que ça me gêne de voir mon banquier faire involontairement et inadéquatement la promotion d'Android et iOS.

  • [^] # Re: Un cas quasi similaire au tien

    Posté par  . En réponse au message Paiement sécurisé sur un téléphone rooté. Évalué à 2.

    Merci pour cette réponse complète, je suis content de voir que je ne suis pas le seul à qui ces décisions posent un problème. Je n'envisage pas d'engager une procédure hostile contre ma banque (quoiqu'un recours collectif…).

    Une solution technique ne me satisferait que moyennement : faire tourner leur logiciel à leur insu serait certes une petite victoire, mais j'aspire plutôt à leur faire entendre raison ou à comprendre pourquoi ils ont raison :)