xryl669 a écrit 106 commentaires

Sur les TI aussi, il y avait la possibilité de faire de la programmation, directement en assembleur, via Fargo. De mémoire, il fallait utiliser un cable série jack 2.5mm (à faire soi même, j'en avais vendu quelques un…). Ensuite, installer Fargo, le launcher assembleur. Et zou, un nouveau monde s'ouvrait à vous, pour peu que vous compreniez l'assembleur du 68000.

La Ti92, c'était la classe, beaucoup de souvenir…

franchement en 3 mois la machine s'est presque payée toute seule vu le prix des pièces détachées pour ce genre de réparation.

Je dois pas vivre dans le même monde. Un siphon ~10€, une chasse d'eau ~30€ et un carénage de débroussailleuse ~40€, je vois pas comment ça couvre le prix de la machine, de l'électricité et du plastique (sans parler des essais ratés et du coût horaire du temps de modélisation).

Autant je suis d'accord avec toi sur le principe d'avoir une imprimante clé en main, c'est un gain de temps considérable (j'en ai 3 chez moi, dont la première qui ne tourne plus depuis 5 ans, la flemme de la réparer, une Ender 3 à 100€ que je me suis juré de ne pas modifier, et qui attend sa conversion en extrudeuse de PET et une plus récente Ender 3 SE qui marche très bien, à 200€). Mais là, la P1S est techniquement hors de prix (mettre 600€ dans une machine qui n'imprime pas plus gros que 25cm³). C'est injustifiable.

Safety net, c'est has been. Maintenant, il y a le play integrity, le "live app checking". En gros, ils ont compris qu'il est impossible de faire un DRM sur un téléphone rooté. Donc maintenant, ils (Gogole) maintiennent une base de données des hash des ROM officielles. Le Play service de Gogole calcule le hash de ta ROM et l'envoi pour recevoir une confirmation de la validation de l'authenticité d'un téléphone non rooté.

C'est malin, pour eux, car ça oblige chaque fabriquant à publier (et donc payer sa dime à Gogole pour l'utilisation d'Android) ses hashs pour avoir le badge "Play Integrity".

Quand à la solution technique, c'est de la bonne vieille obfuscation toute pourrie. Le SafetyNet / PlayIntegrity, c'est une sorte de machine virtuelle qui reçoie une charge virale logicielle des serveurs de Google qui est signée par leur clé privée. Si la signature passe, elle est exécutée et valide la signature de l'intégrité.

Ce que je ne comprends pas par contre, c'est pourquoi il n'y a pas un patch "live" qui remplace le retour de la fonction "IsThisPhoneRooted" par un "return false;" sur microG et bypassant tout le merdier.

Parce que:

assert.ok(isString(Object('foo')));


Après, est-ce utile?, tout est là.

Pas tunée, c'est la même build que le code source officiel. La différence étant de fournir des addons par défaut ainsi qu'une configuration de l'interface plus orientée UI/UX (ce que tu peux faire dans FreeCAD 1.0).

Ils ont aussi fait une sorte de thingiverse pour FreeCAD, appelé Lens, malheureusement, trop peu fourni pour que ça prenne (ce genre de projet nécessite des années pour que ça "tienne", difficile pour une entreprise commerciale).

Bref, c'est peut être un peu prématuré pour l'instant.

Je plussois fortement. On est exactement dans l'exemple d'une "norme" supplémentaire inutile, pondue par des parasites qui n'ont même pas eu le courage d'utiliser leur cerveau plus de 2 minutes.

Cette certification ne sert à rien, comme le dit Guillaume, si tu veux frauder, tu fais payer en espèce et rien ne sort informatiquement, comptablement ou par écrit. Tout autre moyen de paiement laisse une trace qui est facile à vérifier, sans aucune certification du code par un audit requise. Ainsi un chèque doit être déposé sur un compte (donc trace bancaire), un paiement par carte idem, etc… Vu que les banques sont certifiées, elles, il y a déjà un journal des transactions clair, légal, infalsifiable et consultable.

Les logiciels de caisse propriétaires de Point.x qui permettaient d'effacer des opérations n'empêchaient pas les problèmes de réconciliation bancaire, c'est à dire lorsqu'un comptable devait faire correspondre toutes les transaction du compte bancaire avec une ligne de recette/dépense.

La certification ici est donc, inutile car elle ne résout pas le problème qu'elle prétend solutionner, et une charge supplémentaire, in fine, pour les commerçants (et donc pour nous tous, leurs clients). Elle est injuste car une telle certification n'est pas requise pour un commerce en ligne ou dans un pays européen autre. (Ce qui veut dire qu'un commerce qui ne facture pas ses clients via une caisse n'a pas à subir cette taxe)

On est donc pile dans la maxime de Clémenceau; "planter des fonctionnaires, il poussera des impôts". Visiblement, ils n'ont toujours rien compris après les agriculteurs, les gilets jaunes, les bonnets rouges. Il ne reste plus qu'à arrêter de produire et de vendre, tout simplement, histoire que ceux qui pondent ce genre de texte soient obligés de manger leur milliers de pages de normes, lois et autres élucubrations inbuvables et inutiles. On verra comment ils vivent mieux dans leur monde.

Si le but était de limiter la fraude en limitant la facilité de frauder, au contraire, la législation aurait dû imposer que tous les logiciels de caisses soient open sources (mais pas forcément consultables par tout un chacun) et que les builds soient reproductives, conservées et signées. Ainsi si une version contient de la triche, il suffit alors de chercher le hash du binaire chez un commerçant suspecté de fraude et ainsi, en quelques secondes, vérifier si ça vaut de coup de faire la réconciliation et le contrôle fiscal. La vie des contrôleurs fiscaux serait simplifiée, les fraudeurs prévenus en quelques semaines et les logiciels remplacés par des versions sûres. En cas de contrôle faisant apparaître une triche, le hash du binaire est capturé lors du contrôle, partagés avec les autres contrôleurs, et ainsi ne peut s'étendre plus. Idéalement, le logiciel de caisse pourrait signer/hasher les transactions avec son propre hash, ce qui validerait toute la chaîne.

La certification logicielle par cryptographie est quand même bien maîtrisée, facile à faire, quasiment gratuite et difficilement falsifiable.

il force la récursivité

Ah, je vois pas de récursivité dans le code posté, au contraire, il est complètement itératif.
Par contre, il a des bugs, car is_dir suit les liens symboliques, donc il peut ne jamais sortir (et donc crasher par manque de mémoire) si tu as une boucle dans tes répertoires. Mais pour les besoins de l'auteur, qui maîtrise son arborescence de fichiers, c'est un bon compromis je suppose.

Et vos 2 exemples de code montrent que vous auriez dû utiliser cette dépendance car vous avez faux tout les deux.

let x = "a"
console.log((x & 1) == 0)  // true ? WTF ?
console.log((x%2) == 0) // false
console.log((x%2) == 1) // false ? WTF?

Pour tester une valeur, dans un langage non typé, il faut s'assurer du type, sinon les règles d'autoconversion des types vont vous manger les doigts. En gros, il faut tester si le paramètre est un nombre (ou convertible vers un nombre), via isNaN(x) ou autre et agir en conséquence. Donc la bonne réponse devrait plutôt être const isEven = x => typeof(x) == "number" ? ((+x&1)==0) : false

En gros, vos réponses démontrent clairement que le point d'une des premières réponses à l'article est vrai, à vouloir faire sans dépendances, on reproduit les bugs que les dépendances, plus testées, ont déjà corrigés.

Pour les bibliothèques partagées, moi, je suis carrément contre. L'enfer des bibliothèques partagées, c'est l'impossibilité de faire évoluer l'API/ABI de celle-ci. C'est à dire que ni les signatures des fonctions ni le comportement ne peut changer, sans quoi, soit ça casse le code dépendant, soit ça casse le fonctionnement du code dépendant.

Il y a un OS très connu qui était justement connu pour l'instabilité des applications, le problème de compatibilité des installations et c'est justement lui qui a donné le nom que nous utilisons actuellement pour ces m….s : dll.

L'idée, au départ semblait bonne, pourquoi payer plusieurs fois pour le même code?

Mais, une fois mise sur la sellette, on se rend compte que cette économie de bout de chandelle interdit toute évolution d'un code que l'on ne maîtrise plus. Un effort important de documentation doit être fait pour expliquer les effets indirects du code (qui se souvient des crash de l'explorer de fichier à cause d'un plugin IExplorer qui n'a pas supporté une évolution des modules COM…)

Au final, la légendaire stabilité de OSX/MacOS provient principalement dans le fait de ne pas faire de DLL partagées (il y a bien des "frameworks" bas niveau partagés, mais ceux ci sont limités et en général, il y a une couche d'abstraction pour l'utilisation dans votre langage de programmation préféré). Une application = un dossier contenant le binaire et toutes ses dépendances.

Sous linux, on a souvent ces problèmes également (et ce, malgré tout le travail du curage des distributions). Qui n'a pas eu de problème d'une AppImage qui contient une référence vers un driver OpenGL qui est compilé avec une version plus ancienne que le système et donc empêche la version du système d'être utiliséeet échoue au lancement?.
Tout ça à cause du fait que les drivers graphiques récents charge un .so alors que tout le reste de l'application est buildé en statique.

Bref, si le .so ou .dll pouvait crever, on s'en porterait que mieux, AMHA.

En fait, même dans l'embarqué, où l'espace disque est limité, les .so ne font pas sens. Souvent on peut construire le système entier en une seule build, les .so ne servent à rien.

Bon, j'ai beau lire et relire les commentaires vantant LibreOffice, je n'arrive jamais à y croire.

LibreOffice/OpenOffice, ça fait 20 ans probablement que ça promet d'être la référence des documents libres.

Personellement, au travail, dans la vraie vie (pas celle d'un Geek Linuxien), je n'ai JAMAIS vu un ODT or un ODS / ODP traîner nulle part. L'europe, les clients, l'état, tout fonctionne avec DOCX, XLSX, PPTX.

Il faut se faire une raison, le format OOXML est le format d'intercommunication officiel, OpenDocument, c'est simplement de la masturbation intellectuelle.

De la même manière que jamais vous ne pourrez avoir une voiture qui se pilote avec un joystick (et donc le fameux et infâme volant, l'accélerateur à droite, le frein au milieu). L'usage fait le standard, n'en déplaise à l'ISO.

Et au final, une fois admis cet état de fait, il reste quoi ?

• Libreoffice qui ne sait toujours pas ouvrir un DOCX compliqué (c'est à dire avec une zone de texte ancrée, pfff…) sans bousiller la présentation et encore moins le sauvegarder sans pêter le document.

• OnlyOffice, qui, comme son nom l'indique bien, est la seule suite libre qui sait ouvrir, manipuler et sauvegarder un document OOXML.

Au travail, heureusement qu'OnlyOffice existe, sinon, jamais je ne pourrais utiliser ma machine Linux, je serais obligé de faire tourner ces horribles OS américain et payer un abonnement pour un logiciel inutile.

Tu peux trouver des traces partout dans l'histoire de l'utilisation de tel ou tel mot. Ça ne change rien au fait que la langue est faite de l'habitude et si c'était si courant, on ne perdrait pas la trace et on serait habitué à le lire et le comprendre. C'est un argument complètement fallacieux car incomplet et illogique.

De même qu'au temps de Shakespeare on utilisait encore le Thou/Thee (du vieux français Tu) pour la deuxième personne du singulier, la norme actuelle c'est le You (issue de la 2eme personne du pluriel), il n'y a plus de tutoyement en Anglais. Quitte à imposer le "retour" du They pour la troisième personne du singulier, il faut, par soucis d'équité et de non discrimination, imposer le retour du Thou/Thee.

Utiliser "they" pour dire "he", ce n'est pas la règle de base de la grammaire Anglaise. Celle que l'on t'apprend à l'école, celle que tu entends dans la rue ou dans les films etc…

"They entered the bar and found out they expected them, angry and furious".

Je te met au défi de me dire de combien de personnes et qui fait quoi dans cette phrase avec cette "convention".

En gros, ça oblige le natif de la langue à une effort de cognition supplémentaire pour parser la phrase. Quand au non natif, c'est encore plus dur.

On ne peut imposer un archaïsme à un peuple, c'est l'habitude qui fait la langue et pas la loi (et encore moins la politique).

Bref, c'est purement de l'idéologie et du militantisme. Ce serait du même ordre que d'envoyer des patchs en Esperanto en expliquant que c'est moins discriminatoire, vu que toute personne est supposée comprendre l'Esperanto.

Je vois par contre le bashing sur chaque sujet se référant à Ladybird de près ou de loin et la foule des "transphiles" qui tente de faire du name & shame dans les commentaires. C'est marrant, mais pour moi, ça ne fait que conforter mon dédain pour ces gens qui utilisent les mêmes techniques que les extrémistes qu'ils disent combattre (notamment en faisant de la discrimination, du harcèlement, etc…).

Personnellement, si je vois un "she" dans un texte exprimant une commande, je ne me sens pas offusqué et je corrige inconsciemment (ou pas, d'ailleurs, j'en ai probablement rien à faire) le genre. Je me dis même que c'est plus sympa/galant de considérer que l'utilisateur par défaut est une utilisatrice. Par contre, voir un pluriel, je me demande de qui ils parlent, bref, c'est pas clair, surtout quand tu commences à mixer les pluriels pour le pluriel avec les singuliers.

C'est marrant de voir qu'à chaque mention de ladybird, tu as une palanquée de morons qui débarquent et essayent de casser du sucre sur le choix des développeurs de ne pas faire de politique.

Non les développeurs ne veulent pas intégrer des patchs pour changer les "he" en "they" dans les fichiers d'instruction lorsqu'ils décrivent des commandes utilisateurs.

C'est quoi le délire? Passer pour des débiles mentaux? Vous ne pouvez plus dormir qu'un groupe limité de développeurs n'en n'ont rien à battre du wokisme et de votre combat?

Au final, franchement, c'est votre image qui en prend un coup car vous passez pour des gamins frustrés qu'on ne leur accorde pas d'importance.

Si vous voulez vous rendre utile, développez quelque chose de valeur, en mettant tous les "they" que vous voulez dedans et là, peut être que ce sera accepté comme contribution. Mais une contribution politique, c'est clair c'est non. Sinon, c'est la porte ouverte à des débats sans fin, ils ont mieux à faire de leur temps.

Il n’y pas d’applications Google supplémentaire installée, Google Maps est notamment absent.

J'aimerais savoir comment ils ont fait cela. Car lorsque tu lances Android Auto, il vérifie:

1. Que tous les outils google sont installés (Service Google Play, Google Maps, Play Service Framework, Google Jeux, Google Music, Google aspirateur, etc…)
2. Que les versions sont à jour (impossible de ne pas mettre à jour, sinon AA ne démarre pas).
3. Que les certificats soient à jour pour le décryptage du code (et à défaut, télécharge les nouveaux certificats pour décrypter le code)

Bref, impossible de modifier le code de AA qui est livré (partiellement) crypté. Donc pour moi, soit Graphene OS cache Google Maps (c'est ce que j'ai sur mon téléphone, Google Maps est visible dans AA mais non visible dans la liste des applications Android), soit ils sont sacrément fort et ont réussi à déjouer les contre mesures de Google.

Visiblement, aucune des "distributions" Android ne supporte d'alternative au spyware que représente Android Auto. Sur chaque "version", il faut installer toute la suite des applications Google pour que ça fonctionne, donc merci la bonne dizaine d'applications inutiles, non désactivables et dévoreuses de batterie.

Je suis d'ailleurs étonné que GrapheneOS, qui prône ne pas vouloir de root sur le smartphone, autoriser à installer la suite Google qui elle, fonctionne complètement en root, sans aucun contrôle, en by-passant le mécanisme de base d'Android (comme le fait qu'Android Auto n'apparaît pas comme une application dans Android, les services qu'il a installés ne sont pas listés dans les applications système, etc…) pour quasiment tout son fonctionnement.

À la base Android Auto c'est un protocole type VNC pour envoyer son écran à distance, recevoir la position du doigt sur le touchscreen de la voiture et certaines infos du véhicule. Il y a bien eu un reverse engineering du protocole, mais visiblement personne n'a fait un AA-like open source qui évite cette erreur de Google.

À chaque fois que je dois utiliser une application en python, j'ai un arrière goût de bile dans la gorge. Je sais que quelque chose va casser, je sais que même si rien ne casse, la prochaine chose va casser, je sais que je n'aurais jamais assez de place pour stocker 40 versions différentes de la même bibliothèque (surtout en embarqué).

Honnêtement, à part pour du prototype, je trouve que l'environnement Python est une horreur.

Le python, c'est génial comme langage, c'est concis, c'est simple et facile à apprendre.

Mais l'évolution du langage qui n'est pas rétrocompatible et qui casse donc toute la base de code de la version précédente, ça, c'est mal.

Avec l'avènement de l'IA, et des notebooks Jupyter, il y a eu une explosion des utilisateurs python qui n'apprennent pas le fonctionnement du langage et de son univers.

Résultat: impossible de faire rentrer papa dans maman, le moindre projet utilisant 2 programmes Python ne fonctionnent jamais entre eux. Alors il faut les faire tourner dans un venv séparé et donc les faire communiquer via de l'IPC système. Déjà que Python c'est lent, là, c'est carrément dément.

En ce moment, je dois utiliser une librarie qui utilise un code en C (et donc du binding) sauf que la version système installé partout sur n'importe quel système de moins de 10ans est 4 ans en avance de ce que le code python attend. Si au moins python faisait comme tous les autres langages de programmation (c'est à dire de supporter nativement du FFI), la mise à niveau n'imposerait pas de réécrire tout le code du binding. Mais là, c'est l'enfer…

La preuve, dans le texte, il manque des mots. C'est un problème d'attention qu'on m'a dit ;-)

Typiquement, les coroutines (et le async/await en général) résolvent un problème que l'on aurait jamais eu si on avait pris le bon design dès le départ.

Le problème initial, c'est de vouloir faire un code avec des callbacks, parce que, asynchrone tout ça… Et de réfléchir à chaque ressource comme si on devait y accéder avec un chemin complet: "s'authentifier, demander X, puis Y, enfin Z".

Du coup, on trouve du bon vieux QNetworkReply avec ses callbacks/signaux Qt imbitables.

En réalité, le fonctionnement de ce type d'API (authentication/authorization/actions) est typiquement une machine à état. Ton client doit prouver un état (il est authentifié, et autorisé à accéder à une ressource) mais après les requêtes sont assez simple en 1:1.

Dans l'exemple précédent, X, Y c'est juste un état. Une fois demandé, le client est X ou Y, tu peux demander Z directement, voire W si W dépends de X uniquement.

Et donc, typiquement, le bon design, sans forcément faire appel aux coroutines, c'est de maintenir une variable d'état et une boucle principale qui agit sur cet état. En pseudo code c'est aussi simple que:

struct Client
{
  enum State 
  {
    NoConnected = 0,   
    Authenticated,
    Authorized,
    Ready,
    Requesting,
    [...] 
  } state;

  enum ResourceType
  {
    Me,
    KVMList,
    [...]
  } requiredResource;


  [...]

  std::unordered_map<ResourceType, std::function<...> actions;
  void setAction(RessourceType type, std::function<...> func) { actions[type] = func; }


  string answer; // Where all request answer goes

  // OVH API helpers here
  string me() { setAction(Me, [jsonData] { return jsonData["me"]; }); return triggerAction(Me); } 

  string triggerAction(ResourceType type) 
  {
    if (state < Ready) {
      // Handle state ramp up
      waitMainLoopRampup();
    }
    requiredResource = type;
    state = Requesting;

    waitMainLoop();
    state = Ready;
    return answer;
  }





};

std::unordered_map<Client::ResourceType, const char*> ovhAPI = { 
{Client::Me, "/me/"},   
{Client::KVMList, "/kvmlist/"},   
[...]
};

QNetworkReply nam;



bool mainLoop()
{
   QUrl url;
   switch (client.state) {
     case NoConnected: url = "http://ovhapi/authentification"; break;
     case Authenticated: url = "http://ovhapi/authorization" + ovhAPI[client.requiredResource]; break; 

     case Ready: return true; // Nothing to do
     default: return false;
   }
   // The only network request element
   nam.get(url).connect(client.actions[client.requiredResource]);
}

Ici, tout est replié sur un seul niveau d'asynchronisme, et plus des asynchronismes imbriqués. Tu enregistres la fonction que tu veux voir exécutée dans le client, et lorsque tu déclenche l'action d'accéder à la ressource, le client te retourne le résultat, de manière asynchrone, sans que tu n'aies à implémenter toute la logique d'accès à chaque objet qui t'intéresse.

Le mainLoop ci-dessus, c'est en gros le scheduler caché dans les coroutines, sauf que c'est un code qui ne cache rien du coup sans utiliser les trucs comme la sauvegarde de la pile et les pseudo tâches.

Surtout, tu peux exécuter des requêtes en parallèle (tu peux avoir plusieurs threads qui gèrent un mainLoop avec le client partagé), ce qui est très difficile à faire correctement avec les coroutines, car justement lorsqu'une coroutine est en "await", elle est ininterruptible (vu que techniquement, elle n'existe même plus sur la pile d'appel).

Non c'est pas du tout évident, un qatari consommant méchamment plus qu'un nigérian (j'en sais rien, j'ai pas vérifié), c'est le mode de vie qui compte, pas le nombre de personnes sur Terre.

Méchamment, c'est méchant. Un qatari mange comme les autres humains, environ 2000kCal par jour. Il a en moyenne autant d'enfant. Son mode de vie, aussi dispendieux qu'il soit, ne rattrapera jamais les ressources d'une personne supplémentaire.

Même un USien qui utilise 5 Terres par an (métrique complètement farfelue en plus, mais passons), tu auras donc plus à gagner à limiter une personne supplémentaire (tu "économises" 5 personnes virtuelle) qu'à limiter sa consommation (tu "économises" 4 personnes virtuelles si d'un coup, il se met à consommer en adéquation avec la capacité de production de la Terre , ce qui n'a que très peu de chance d'arriver).

Il n'y a aucune chance qu'un enfant USien consomme comme un Éthiopien en plus, donc il faut également prendre en compte la croissance exponentielle de ses propres enfants, etc…

Bref, l'impact d'une baisse démographique majeure est le plus court chemin vers la soutenabilité.

Non seulement ces générations devront payer nos retraites mais aussi la transition écologique. Si en plus tu leur laisses une démographie en berne, ils sont cuits et ne pourront rien faire.

Je vois aucun rapport avec les retraites, à part une sorte de bourrage de crâne franco-français. Il y a de nombreux pays qui n'ont pas notre système de retraite et qui s'en sorte sans problème avec une démographie en décroissance. Un moment ou à un autre, il faudra payer le cadeau d'une génération qui a été fait à la première génération de retraité en France. Si tu veux que ce "coût" impacte le moins possible, forcément, il vaut mieux qu'il y ait moins de cotisants qui souffrent que beaucoup de cotisants qui souffrent.

Je ne comprends pas pourquoi si la démographie est en berne, ils seraient cuit. Bien au contraire en fait. Avec un peuple moins nombreux, les problèmes de logements seraient quasiment résolus (et en plus, si l'offre dépasse la demande, les loyers & crédits baissent, la surpopulation anxiogène baisse, les incivilités aussi, etc…).

Le problème, ce n'est pas des enfants sur des vélos, le vrai problème, c'est les boomers dans leur SUV (1 par personne sinon c'est pas drôle).

À part un jalousie latente et une haine injustifiable, je ne comprends pas ce genre d'argument. Un SUV consomme moins de fait que la voiture qu'il remplace. Du point de vue écologique, la plupart des SUV sont donc un bénéfice pour les problèmes les plus urgents (à savoir la diminution de l'effet de serre). Les VE ont maintes fois prouvés avoir un impact plus que positif sur la réduction de CO2 dans l'atmosphère (en tout cas, en France).

Quand au 1 par personne, je te rejoins sur ce point. Le jour où on arrêtera la centralisation forcée vers les villes (métropoles et autre), magiquement le nombre de véhicules sur les routes chutera de manière exponentielle. Les véhicules ne seront plus remplacés aussi souvent (car c'est le kilométrage qui cause le remplacement des véhicules, pas leur âge), donc moins d'impact écologique. Mais ça veut dire plus (+) de télétravail, remettre les services de proximités dans les agglomérations plus petites où se situe la majorité des travailleurs au lieu de centraliser dans la "métropole", etc…

Intéressant, merci.

Il me semblait que pour faire une pointure plus petite, il suffisait de ne pas monter toutes les aiguilles. En gros, tu montes une aiguille sur deux et tu as une pointure 1.41 fois plus petite (d'après la vidéo).

Avec cette machine imprimée en 3d, on peut tricoter une chaussette en 2 temps, 3 mouvements.

Par contre, je ne comprends pas bien comment on fait le talon.

Franchement, on en fait tout une histoire de faire du code parallèle, mais il est sacrément plus difficile de faire du code perpendiculaire.

Là, aucun langage ne propose quoi que ce soit, surtout dès qu'il s'agit d'utiliser un nombre de dimensions supérieures à 2.

À la limite, il y aurait le brainfuck:

   ,
   ,
 .+++.
   ,
   ,

Contrairement à ce qui est indiqué dans l'article, on peut parfaitement avoir des pointeurs null dans Zig. Cf cet exemple. Sinon, impossible d'implémenter une liste chaînée, une queue, etc…

En même temps, vu que Zig peut utiliser un "module" C++ qui lui supporte le RAII, rien ne t'empêche de RAIIser ton code en C++ et de l'utiliser dans Zig, non ?

Ah, c'est encore pire que ce que je pensais.

Dans cet exemple de code, comment accèdes-tu à la variable err "globale" dans le scope du else ?

Si tu ne peux pas, dans ce cas, impossible d'utiliser une variable err ou a ou b nulle part, car le jour où la fonction gen_ten_or_none change de signature (suite à une maintenance de code par exemple) pour retourner une erreur, une variable err vient "shadow aliaser" tes propres variables sans aucun message d'alerte.

Autant dans ce cas, définir err et it et a et b comme mot clé du langage. C'est assez déroutant en fait.

De plus map prend un "fonction scope" comme argument et pas un "parameter list" du coup, ce qui fait un peu mélanges d'effluves, car les autres fonctions attendent toutes un "parameter list".

Comment faire pour avoir un code plus long dans un map ? (Genre 2 lignes, ou assigner une variable externe lors de l'itération?).

C'est l'it qui sort du bois dans le map, qui rencontre un a qui se croit supérieur au b lorsqu'il sort, mais en cas de problème, il err sans exception.

Magnifique… Je suppose qu'écrire 'a,' ou 'it,' pour pouvoir choisir le nom de la variable dans une fonction lambda eu été trop de dépense d'énergie, résultat, il y a des variables magiques qui sortent de nulle part, qui empêche (du moins, je l'espère) l'utilisation de ces noms partout ailleurs (c'est clair que it, a, err sont jamais utilisées dans du code standard).

Bref, c'est nul comme choix.