• # IntĂ©rĂȘt ?

    Posté par  (site web personnel) . Évalué à 10.

    Le site ne donne pas d'argument en faveur de SDLang ou en défaveur de JSON ou YAML. Quel problÚme cherche-t-il à corriger, quelle amélioration apporte-t-il ?

    J'ai parcouru les exemples, je n'ai rien vu d'attirant au premier regard. Je me suis arrĂȘtĂ© au format des dates, en me demandant pourquoi l'auteur n'avait pas repris le format ISO


    Forcément, le XKCD qui s'impose : https://xkcd.com/927/

    • [^] # Re: IntĂ©rĂȘt ?

      Posté par  (site web personnel) . Évalué à 1.

      Peut-ĂȘtre pousser par Oracle pour attaquer les utilisateurs par la suite pour rĂ©cupĂ©rer des sous ?

    • [^] # Re: IntĂ©rĂȘt ?

      Posté par  (site web personnel, Mastodon) . Évalué à -1.

      Je n'en vois aucun en pratique non plus. Par contre j'en vois un stratégique : diviser pour mieux régenter.

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

      • [^] # Re: IntĂ©rĂȘt ?

        Posté par  . Évalué à 3.

        Régenter ? Qui ?

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: IntĂ©rĂȘt ?

      Posté par  (site web personnel) . Évalué à 7.

      Je vois les avantages suivants:

      • on peut mettre des commentaires (json puxor) ;
      • la syntaxe ne dĂ©pends pas de l'indentation (yaml puxor) ;
      • c'est lisible (xml puxor).

      Effectivement le choix du format des dates non iso est curieux.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: IntĂ©rĂȘt ?

        Posté par  . Évalué à 7.

        Toml

        • [^] # Re: IntĂ©rĂȘt ?

          Posté par  (site web personnel, Mastodon) . Évalué à 3. DerniĂšre modification le 17 septembre 2021 Ă  00:14.

          TOML est conçu comme une amélioration de INI (plutÎt orienté configuration que sérialisation de données structurées comme JSON)
          C'est vrai qu'il a aussi les bĂ©nĂ©fices mentionnĂ©s en plus d'ĂȘtre plus facile et bien supportĂ©/intĂ©grĂ© par/avec les divers langages.

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

      • [^] # Re: IntĂ©rĂȘt ?

        Posté par  . Évalué à 3.

        Le format c-style est sympa, mais du coup il est plus faible qu'un DSL fais en groovy/ruby

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: IntĂ©rĂȘt ?

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          ça se prĂ©sente comme un dĂ©rivĂ© human-friendly de XML : c'est dĂ©jĂ  un DSL agnostique de tout langage de programmation, un peu comme recfiles


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

      • [^] # Commentaire supprimĂ©

        Posté par  . Évalué à 5.

        Ce commentaire a Ă©tĂ© supprimĂ© par l’équipe de modĂ©ration.

    • [^] # Re: IntĂ©rĂȘt ?

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      C'est pas mieux d'améliorer, si nécessaire, les formats existants plutÎt que de complexifier (et de bordelifier) en en rajoutant un ?

      « Tak ne veut pas quÊŒon pense Ă  lui, il veut quÊŒon pense », Terry Pratchett, DĂ©raillĂ©.

      • [^] # Re: IntĂ©rĂȘt ?

        Posté par  . Évalué à 4.

        GĂ©rer N versions d'un format pas forcĂ©ment compatible plutĂŽt que N formats diffĂ©rents ? (qui n'ont pas prĂ©vu de versionement au passage) Ça ne change pas grand chose.

        Mais ça dépend de l'objectif.

        S'il s'agit d'un format d'Ă©change comme l'est json tu as besoin d'avoir pleins de choses qui le gĂšrent.
        Si c'est le format de configuration de ton logiciel tout le monde s'en fou. Personne ne se pleins que nginx, apache httpd, vim ou autres ont des formats de configuration dédiés.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: IntĂ©rĂȘt ?

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Que fais-tu du syndrome nih ?

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

      • [^] # Re: IntĂ©rĂȘt ?

        Posté par  (site web personnel) . Évalué à 3.

        Pour json c'est faisable (exemple: https://json5.org/).

        Pour xml, il suffit de ne l'utiliser que lĂ  oĂč il est strictement nĂ©cessaire (documentation).

        Pour yaml, la seule amélioration possible c'est de le mettre à la poubelle.

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: IntĂ©rĂȘt ?

          Posté par  . Évalué à 4.

          json5 est trÚs peu supporté donc tu ne peux pas t'en servir pour une api publique par exemple et les parseurs ne peuvent pas déduire le format (il faut des heuristiques qui valent ce qu'elles valent). Si demain json++ sort avec des choix différents de json5, ça va devenir compliqué par exemple.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # inconsistances

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Quand je vois :

    // Tags may contain certain non-alphanumeric characters
this-is_a.valid$tag-name

    OK, mais quand juste aprĂšs on a :

    // Namespaces are supported
renderer:options "invisible"
physics:options "nocollide"

    ça me pose souci parce-que les balises peuvent contenir n'importe quel caractĂšre 
y compris les deux points non ? Au passage, je me demande quel est l'Ă©quivalent de cet exemple, avec les espaces de noms, en XML !

    De mĂȘme, bien plus tĂŽt on a :

    // Anonymous nodes are supported
"This text is the value of an anonymous node!"

    c'est sympa, mais pareil : les balises pouvant contenir n'importe quels caractÚres, pourquoi ce ne serait pas une balise avec une valeur vide ? Et sinon, dans quel cas a-t-on des valeurs qui flottent comme ça ?

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

    • [^] # Re: inconsistances

      Posté par  . Évalué à 3.

      ça me pose souci parce-que les balises peuvent contenir n'importe quel caractùre 
y compris les deux points non ?

      Non, c'est dans la doc :

      Names and namespaces are identifiers.
      [
]
      An SDLang identifier starts with a unicode letter or underscore () followed by zero or more unicode letters, numbers, underscores (), dashes (-), periods (.) and dollar signs ($).

      les balises pouvant contenir n'importe quels caractĂšres

      Non des lettres et quelques caractĂšres et pas les espaces du coup.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: inconsistances

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Ah, pas vu cette doc. Mais du coup, ça fait moins que JSON et YAML mais bon ça se positionne par rapport au XML.
        Y a des restrictions sur les attributs ?

        Et le coup des valeurs sans identifiants ? (nƓuds anonymes
)

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

        • [^] # Re: inconsistances

          Posté par  . Évalué à 2.

          La référence du format peut probablement répondre.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # trĂšs mal nommĂ©

    Posté par  (site web personnel) . Évalué à 7.

    Le nom du projet (son acronyme) entre en conflit avec la vénérable SDL.

    git is great because linus did it, mercurial is better because he didn't

Suivre le flux des commentaires

Note : les commentaires appartiennent Ă  celles et ceux qui les ont postĂ©s. Nous n’en sommes pas responsables.