Gil Cot ✔ a écrit 5730 commentaires

Tu as donné les réponses dans les questions ;-)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Voir https://github.com/kdeldycke/awesome-falsehood#dates-and-time (notamment You Advocate a Calendar Reform - Your idea will not work. This article tells you why., dont they tried that in France once and it didn't take)

→ https://qntm.org/calendar
Juste une liste d'excuses pour la résistance aux changements, avec un grand focus sur l'année solaire (365 jours, bissextiles, tout ça, voir mon autre commentaire…)

La vrai raison du rejet d'un calendrier plus cartésien en France s'appelle Napoléon (qui l'a aboli au 1er janvier 1806 : si ça ne tenait qu'à lui on aurait probablement eu le pied napoléonien au lieu du mètre…) Zut, on n'est plus vendredi sur aucun fuseau horaire.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Pour un calendrier régulier, je n'entends pas forcément l'abolition des années bissextiles mais d'avoir un système globalement plus régulier dans le comptage des semaines (la semaine de 5 jours est un exemple, 7 ne me pose pas de souci non plus sauf si ça doit justifier d'autres complexités) et des mois (des noms pour vénérer des dieux ou des empereurs, des durées aléatoires n'obéissant à aucune logique.) La complexité du système actuel demande bien plus de travail d'adaptation qu'un truc qui serait plus régulier, et les erreursproblèmes dans différents logiciels l'illustrent bien.

Concernant le maintien des années bissextiles, tu présuppose que le calendrier doit absolument être de type solaire mais il y a bien d'autres possibilités qui ne sont pas plus déconnantes. Mais bon, même dans ce cas, les calendriers décimaux (cas autrefois en Égypte puis sous la Révolution Française) n'est pas incompatible (on avait en fin d'années des jours dit intercalaires ou sansculottides en plus de la régularité des décades —semaines de dix jours— en douze mois égaux.) Et Grosclaude avait aussi fait une proposition pour avoir un système perpétuel (lire au sujet du calendrier invariable : Popular Science et Sunday Magazine ou encore Popular Astronomy par exemple) dans la même lignée que Armelin/Manin/Achelis (lire au sujet du calendrier universel : dans Time comment le religeux freine encore l'évolution, sur le site l'association de promotion la description et autres, système adopté par le CÉeS de l'ONU en 1954) Bref, on sait déjà faire si ce n'est les habituels freins irrationnels.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Je ne vois pas pourquoi des dates en négatif serait un problème, et je ne vois pas comment tu trouves qu'il y a peu d'années en négatif dans le système actuel.
Pour la neutralité, il n'est pas obligatoire que ce soit un « fait historique » ; un/une fait/convention scientifique ferait plus neutre que n'importe quelle culture religieuse, et on a déjà le TAI qui montre que ce n'est pas impossible.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Il y a toujours un début (même à un mouvement perpétuel), ce n'est pas le débat. Si le début est basé sur un consensus scientifique ça répond à la problématique initiale de ne pas avoir un choix imposé par une religion (qui serait de facto au dessus des autres et encouragerait la défiance des autres religions placées en perdantes.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Qu'on trouve une date plus précise ou une autre date n'est pas et ne sera pas un problème en soi. Me semble qu'on a eu problématique un peu similaire pour le seconde et le mètre : le changement de définition et l'augmentation de précision n'ont pas remis en cause les montres existantes. Le problème qu'on cherche à résoudre n'est pas de trouver une valeur absolue mais de convenir d'une valeur neutre commune (chose que beaucoup de réponses semblent oublier.)
Maintenant, ce ne serait pas la première fois qu'on referait un calendrier et on n'en mourra pas pour autant.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

C'est sûr que si ça passe par G..gl. ça met cette entreprise dans la position d'un état par rapport aux cartes nationales d'identité. Du coup, on peut comprendre ton questionnement et y répondre par le fait qu'ici plusieurs solutions/fournisseurs sont possibles : pas de centralisation G..gl. possible donc, sauf si tout le monde décident de faire ce choix (qui n'est pas imposé par PyPi qu'on s'entende.)

Maintenant, pour la sécurité, il faut voir/comprendre le problème actuel de l'authentification classique : quand une personne malveillante arrive à capter le mot de passe d'une autre personne bienveillante, malveillante peut commettre des exactions au nom de bienveillante ; et malheureusement on a eu beaucoup de cas qui font que ce scénario n'est plus de faible probabilité mais avéré.
Si pour accéder à tes opérations bancaires, il te fallait juste le code de ton espace client (ou de ta carte bancaire) ça sécurise …mais cette sécurité vole en éclat si quelqu'un arrive à avoir ce code. On a vu entre temps des systèmes consistant à demander plusieurs mots de passes mais avec l'inconvénient que ça multiplie les mots de passes au lieu de résoudre le vrai problème (plus les gens en ont, plus on a tendance à les noter ou à réutiliser les mêmes, au mieux certaines personnes utiliseront un gestionnaire de mot de passes mais quand c'est le gestionnaire qui est devenu accessible alors on a juste repoussé le souci et quand ça merde ça fait encore plus mal.) L'autre approche est celle des systèmes qui génère un jeton temporaire qui fait que si on arrive à attaquer une session ça ne vaudra que pour cette session et pas d'autres.) Ce n'est pas le panacée mais c'est déjà beaucoup plus sécure, sachant que les jetons ne sont pas stockés avec le mot de passe mais dynamiquement et via un autre canal : on a donc 2 facteurs qui se valident. L'idée générale est d'associer ce que le/la propriétaire légitime connait (le mot de passe) et ce que il/elle possède (par exemple, le téléphone sur lequel on va envoyer un sms contenant un code), ce qui est forcément plus sécure (bon, dans cet exemple si tu te fais voler le téléphone en même temps que les mots de passe par la même personne on revient au point de départ, sinon comparé à avant la casse est limitée) Pour en revenir à l'exemple initial, pour accéder à tes opérations bancaires, il te faut maintenant aussi bien connaître le code et présenter par exemple une pièce d'identité avant d'accéder à la salle des coffres de la banque : c'est beaucoup plus sécurisé qu'une/un simple consigne/box non ?
Il est là le rapport que tu cherches. L'accès étant plus sécurisé, il y aura moins de code malveillant venant de tierces (cela n'empêche pas le sabotage volontaire ; mais entre une personne qui saborde son npm, comme on l'a vu y a pas longtemps, et la même personne qui serait victime de bots/crackers y a un plus grand fossé.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Bonne question :-) Je ne me suis jamais personnellement penché dessus, mais j'ai remarqué que dans la plupart des distributions Linux (quand j'ai regardé), c'est organisé comme les bibliothèques partagées : plusieurs versions peuvent cohabiter. Mais, je pense que la réponse est ailleurs : PERL est l'un des rares langages de scripting à tenter de garder un maximum de compatibilité ascendante. Du coup, les distributions fournissent juste la dernière distribution stable en sachant que tous les anciens codes vont continuer à tourner.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Tu veux dire de vieux langages?

Février 1991, soit 31 ans ; c'est sûr que ce n'est pas vieux et très moderne.
Février 1988, juste 3 ans de plus ; c'est sûr que ça fait archi vieux n'est-ce pas ?
Juin 1995, soit 27 ans, c'est encore plus vieux que 31… dans la distorsion de vue.
Quand on veut noyer son animal…

encore plus poussiéreux et moins puissant

Mis à part les sentiments tirés du chapeau, peux-tu développer factuellement ?

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

C'est bon, on a compris que tu es juste anti.
Au cas où tu ne le saurais pas, tu crois que ce n'est plus en usage et pourtant : on continue de le lister (parmi sept autres à considérer) en 2022 ; ailleurs c'est en dixième position juste avant C++ pour 2022 ; même github montre une activité importante pour un mort. Bref, on te laisse à tes croyances.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Bof, ça reste un euphémisme puisque la référence est intrinsèquement chrétienne… Ce qu'il faudrait c'est un calendrier dont l'origine serait vraiment neutre aussi (et qui serait plus régulier tant qu'à faire)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

C'aurait pu être recyclé pour l'encyclopédie de 2nd/half life
Il a fallu qu'un romancier veuille faire une fiction plus que vraie pour foutre en l'aire un monde parallèle. Tss

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Comme répondu ailleurs, la plupart des langages de script sont compilables aussi, y compris Perl
https://www.marcbilodeau.com/compiling-perl/

Un autre commentaire a invoqué l'implémentation de busybox… On peut ajouter, par exemple, Jerl et PLJava et perljvm comme implémentations Java. Et Parrot est pensé pour se voir interfacer n'importe quel langage (y compris Python, cf. PEP401) tandis que Raku-do permet à Perl/Raku d'implémenter n'importe quel autre langage.
Maintenant, pendant que certaines personnes s'échinent inutilement à remplacer l'un par l'autre, les principaux acteurs préfèrent faire des ponts : Inline::Python et PyPerl

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Avec un Android 5 à jour (mais donc plus maintenu) et le navigateur natif (dot je pense que c'est le support Unicode natif qui est mis en jeu) j'ai de jolis carrés à coins arrondis et bleutés (zorê du être transparent et se superposer au lieu de se mettre à côté)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Jolii. Je note pour quand j'aurai à utiliser ODT par exemple. Avec du MD, on n'a pas la possibilité de basculer entre les fontes (même s'il reste la possibilité de générer des images externes)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Toute façon faut jamais mêler perso et pro !

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Pour moi déjà quand tu en arrives à devoir écrire un article pour justifier une technologie, c'est que la dite techno est mourante.

Ouch… Ça ne va pas plaire aux gens qui l'ont fait pour… Python, Rust, etc. :-)

Mais bien d'accord que c'est trop succinct (et donc parait cryptique —et non horrible) d'avoir une flopée de mot-clés d'une à deux lettres …même si ça ne bat pas : APL, J, BrainFuck, SKI, …

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Par contre je me demande comment je vais réussir à faire travailler X développeurs ensemble, et comment je peux trouver les compétences pour. Or sur ces deux plans Perl perds.

C'est étrange, je n'ai pas du tout la même expérience.

Déjà que faire travailler du monde ensemble en Python c'est pas facile, mais en perl c'est une autre paire de manches (la philosophie du langage l'implique directement). Et trouver du monde employable pour Perl est … heu… disons ultra complexe. C'est déjà un peu plus jouable en Python même si c'est tendu.

Pour ce que j'en ai vu, c'est exactement la même chose : la philosophie du langage ne dit pas qu'un projet ne doit pas avoir de règles et je n'ai jamais vu de devs Perl ne pas se faire aux règles du projet. Par ailleurs, ces gens (qui son décrits comme des aliens) ne sont pas si rares que tu dis, en tout cas ce n'est pas le constat que je fais.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Non, non, il y a vraiment des compilo pour du Python et du Perl aussi. Mais la plupart du temps en effet, c'est un interpréteur (du byte code)

Pour l'enfer d'audit des dépendance, ce n'est pas forcément la réduction du nombre de langages qui peut solutionner cela je pense. Avec n'importe quel langage, on peut faire beaucoup de dépendances ou en avoir un nombre réduit, et c'est la maîtrise de ce nombre réduit qui doit être recherché et qui n'est pas toujours fait.

Le problème du chefs de projets actuels est que ce sont comme des commerciaux qui promettent toujours d'aller plus vite que la musique et espèrent être très loin quand ça pète. Du coup, n'ayant pas à répondre par la suite de leur méfaits, ils ne peuvent pas rechercher la qualité intrinsèquement. (ma méchante humeur du vendredi.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Enlever les Maths, rajouter du Python, why not :p

La tendance est à fournir des gens qui savent écrire dans un langage de programmation et non des gens qui savent faire des algorithmes et les traduire dans n'importe quel autre langage. Mais je m'éloigne du sujet avec ces allégations.

On est toujours un peu attaché à son premier langage

Ça n'a pas fait pour autant perdurer BASIC (en dehors de µ$) ou Pascal malgré Delphi (qui est son pendant VB non ?)
Mais je comprends ce que tu veux dire quand j'ai vu qu'une génération de gens formés à Java ont eu du mal à appliquer les concepts POO avec d'autres langages.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Des audits du code, une communauté importante et impliquée, un système de mise a jour des dépendances bien huile, tout ça compte. Et la dessus Python a nettement l'avantage sur Perl.

Euh… Que reproches-tu aux modules Perl et qui serait mieux fait de l'autre côté ? Par ailleurs, je ne compte plus le nombre de liens et de journaux ici qui déplorent le système de dépendances de Python, et les soucis pointés ne sont pas présents chez l'autre.

Par contre la facilite de pouvoir relire moi même les scripts dans un langage pas obscure et sans siouxeries de syntaxe toutes les 3 lignes, ca je trouve ca plus important.

Exactement le souci que j'ai avec nombre de scripts Python dont j'hérite et qui sont imbitables à souhait pour une bonne moitié. J'ai souvent plus vite fait de réécrire et ça n'empêche que je tombe une fois sur cinq sur des trucs un peu tordus.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Je ne sais pas si une substitution globale est possible après coup. En effet, après avoir pris conseil sur le forum, je souhaite que toutes les occurrences de

• <kbd> soient remplacées par 〔 : left tortoise shell bracket
• </kbd> soient remplacées par 〕 : right tortoise shell bracket
• 〕〔 enfin soient remplacées par 〕 〔 : une espace oubliée entre les deux

Merci.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Merci beaucoup pour cette trouvaille ; je ne connaissais point.
Je te confirme, après quelques essais que ce n'est pas chassant et que la prise en charge ici aussi provoque comme des chevauchements. Je mets dans ma besace pour un usage futur.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

par exemple entre guillemets (typographiques) ou entre les barres verticales |, voire les signes inférieur et supérieur, éventuellement des crochets. Faut juste être cohérent.

Ça me plait bien les crochets []. Quelques essais ont été refroidissant quand il y a des parenthèses. Je vais retenter avec les chevrons <> voir ce que ça donne.
Je crains que les barres verticales soient difficiles à lire (vu que j'en ai plusieurs de suite) et compliquées (vu que dans nombre de cas j'utilise en plus des tableaux.)

Merci pour toutes ces pistes.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Ce n'est pas vraiment une question de Markdown à mon avis.

En (X)HTML pur, je peux utiliser les balises <kbd> et <samp> d'une part, et <var> ou <code> de l'autre côté.
Ici, ces balises sont virées, comme je viens de me rendre compte Pourquoi pas (c'est plus simple à gérer en terme de sécurité.)
Sur Zds il y a un marquage markdown prévu pour ce cas
Le markdown standard (ni CommonMark) n'a pas prévu ce cas, mais autorise l'usage de balises HTML justement interdites ici sans alternative.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume