• # 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¬† . √Č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/09/21 √† 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

      • [^] # Re: Int√©r√™t ?

        Post√©¬†par¬† (site Web personnel) . √Čvalu√©¬†√†¬†5.

        Je trouve que JSON5 est une meilleure solution alors.

        Notamment, je trouve que les attributs sont une mauvaise idée. Cela donne deux manières de renseigner une valeur, avec les dérives qui vont avec et la complexité pour naviguer dedans (cf Xpath).

        JSON et YAML représentent de la donnée universelle qu'on peut directement manipuler dans les types de bases de tous les langages de haut-niveau : dictionnaire, liste, etc. Tu parse et après tu oublie le format pour utiliser les API natives du langage.

        XML requiert une API spécifique pour manipuler les éléments, leurs enfants et leurs attributs. C'est un vrai fardeau à l'usage. SDLang a la même API DOM avec element.getTagAttribute, element.getTagValue, element.getTag, etc.

        En fait, SDLang est à XML ce que le YAML est au JSON, un variante plus facile à rédiger manuellement. Donc c'est bien quand on est payé à la ligne de code.

    • [^] # 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.