Journal la rouille et la comtesse

Posté par  . Licence CC By‑SA.
27
17
nov.
2021

Salut 'nal.

Il y a quelques mois, je me suis mis au langage Rust qui était alors le plus plébiscité de StackOverflow (et ce quatre années de suite…) et qui arrive second au dernier AOC sur Redit.
Les début de la noce furent belle. Cependant, après moins d'une semaine, j'ai du faire une pose qui dura plus longtemps que prévu, et au retour il ne fut pas aisé de se remettre dans la syntaxe cryptique. Ce n'est pas le problème ceci dit.

J'ai poursuivi l'aventure cahin-cahan pour me familiariser avec la plupart des concepts du langage. Bien qu'étant loin de sa maîtrise, j'ai quand même voulu prendre le recul par rapport à d'autres langages… Pas de panique, je ne vais pas faire la comparaison avec les langages Go ou C++ etc. Non, je me suis rappelé que ce qui est mis en avant pour ce langage à la mode, ce sont la fiabilité et la sécurité.
Et sur ce point, on a l'ancien et discret Ada très prisé pour les programmes dans le domaine militaire (états-uniens en tout cas) et les transports (aviation, contrôle aérien, ferroviaire, etc.) J'ai donc commencé à prendre des notes pour pouvoir partager avec les moules, puis en vérifiant certains points, j'ai découvert que d'autres avaient fait le boulot, en particulier Quentin Ochem, gestionnaire de compte chez AdaCore et intervenant chez EPITA qui écrit en avril 2017 un bel article sur Electronic Design et dont le titre se traduirait par « Rust et SPARK : Fiabilité logicielle pour tous ». Il y a là tous les constats que j'ai fait (d'où l'air parfois de déjà vu, masqué par la syntaxe) et un peu plus. Ah oui, mais SPARK ? C'est un sous-ensemble de Ada2012 avec le contractuel.

Bref, tout en parvenant à éviter le sort de D avant, on continue à réinventer la roue, mais il n'est pas mauvais d'avoir des compétiteurs.
Pour la route, et pour les perfs, jeter un œil au The Computer Language Benchmarks Game.

Ciao tutti.

  • # Perf

    Posté par  (site Web personnel) . Évalué à 10 (+7/-0). Dernière modification le 17/11/21 à 17:29.

    Les perfs à l'exécution c'est très important, mais à la compilation aussi. Est-ce que Spark se défends bien sur ce point? Pour Rust, disons que ce n'est pas le plus rapide de l'Ouest.

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

    • [^] # Re: Perf

      Posté par  . Évalué à 5 (+4/-1).

      Extrait de l’article précédent :

      the SPARK formal prover is able to verify that the condition “the index of the element must exist before a replacement” cannot be verified

      Il y a des chances que ce types de vérifications à la compilation coûte un peu de temps de calcul. C’est des langages qui mettent la priorité sur la fiabilité du code plus que sur la vitesse de compilation brute.

      (ça répond pas à la question mais c’est probablement un élément de réponse)

      • [^] # Re: Perf

        Posté par  . Évalué à 3 (+1/-0).

        En effet, à codes équivalents (comme je ne suis pas encore assez bon dans ces langages je ne suis pas certain que ce soit exactement équivalents, mais sinon on peut utiliser les sources de https://benchmarksgame-team.pages.debian.net/benchmarksgame/ ainsi que TapTempo…) dans mon expérience, Rust et Ada mettaient bien plus de temps que C pour compiler. Cependant, Ada était un brin plus rapide que Rust. Je suppose que c'est parce-qu'il ne tente pas de faire toutes les optimisations possibles (c'est expressément demandé par le standard parce-qu'il est important que le comportement du binaire soit celui attendu quelque soit l'architecture/processeur, donc pas d'optimisation qui pourrait amener des effets de bord spécifique… je soupçonne que ce soit aussi pour ça que c'est légèrement en retrait quand on compare les vitesse d'exécution…)

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

        • [^] # Re: Perf

          Posté par  (site Web personnel) . Évalué à 10 (+8/-0).

          J'ai adoré l'Ada quand je l'ai découvert lors de mes études. Les véritables points forts que j'avais relevé à l'époque :
          - possibilité de faire des pré et post condition directement sans avoir à utiliser des outils tiers
          - la puissance du typage, notamment dans la spécialisation de type simple. Il est possible de définir des types à virgule fixe en choisissant la précision souhaitée, des entiers dans l'intervalle [3, 10], de définir de nouveau type numérique (permettant d'éviter d'additionner des choux et des carottes), etc… je ne connais pas Rust, mais à ce jour, je ne connais aucun langage qui permette de faire tout cela
          - le multitâche nativement supporté
          - la portabilité
          - la procédure de build fait parti du langage. Il suffit juste d'appeler le compilo avec les bonnes options. Pas besoin d'outils tiers (bash/make/autotools/autoconf et j'en passe)

          Aujourd'hui je ne fais plus d'Ada, non pas parce que c'est un mauvais langage, mais plutôt par choix/contraintes. Il y a peut être eu du nouveau côté IDE, mais à l'époque, le meilleur était Adagide et je le trouvais déjà limité (plutôt un éditeur enrichi qu'un véritable IDE). Le développement en Ada était aussi plus lourd qu'avec d'autres langages, et développer des applications de bureau était grosso modo limité à l'usage de Gtk avec des différences de comportement entre les versions Windows et Linux.

          Les choses ont peut être changées depuis 15 ans. Mais maintenant je suis un "vieux crouton" qui se complait très bien avec le C# :)

          • [^] # Re: Perf

            Posté par  . Évalué à 3 (+0/-0).

            de définir de nouveau type numérique (permettant d'éviter d'additionner des choux et des carottes)

            Est-ce que cela a réellement une utilité sans système d'unité intégré ? Certe, on n'additionne pas de choux avec des carottes, mais on les multiplies souvent (vitesse, temps, distance, énergie…)

            "La première sécurité est la liberté"

            • [^] # Re: Perf

              Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

              Avoir des types numériques incompatibles ne signifie pas qu'il n'est pas possible de définir certaines opérations comme la multiplication, afin de permettre de faire des choses qui ont du sens.

              Et dans le cas où ce n'est pas prévu, on peut toujours le faire avec un cast explicite. C'est ça qui est pas mal avec Ada, tu peux tout faire, tant que tu le dis explicitement.

              • [^] # Re: Perf

                Posté par  . Évalué à 4 (+2/-0). Dernière modification le 19/11/21 à 15:03.

                Avoir des types numériques incompatibles ne signifie pas qu'il n'est pas possible de définir certaines opérations comme la multiplication, afin de permettre de faire des choses qui ont du sens.

                En Go par exemple c’est pas possible, alors même que les développeurs aiment redéfinir tout un tas de types :

                // Valide
                d1 := 10 * time.Second
                
                // Invalide
                // invalid operation: t * time.Second (mismatched types int and time.Duration):
                t := 10
                d := t * time.Second

                Il faut « caster » t en time.Duration :

                t := 10
                d := time.Duration(t) * time.Second

                Pourtant, time.Duration est juste un « alias » du type int64.

                • [^] # Re: Perf

                  Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

                  En Ada, il suffit de définir la fonction "*" qui va bien

                  function "*" (Left: Integer, Right : Duration) return Duration;

                  Et tu pourras faire l'opération sans problème. Et comme en Go, tu peux aussi explicitement caster.

                  D'ailleurs, à noter que la fonction"*" fera très certainement appel… à un cast explicite pour implémenter l'opération !

                  • [^] # Re: Perf

                    Posté par  . Évalué à 3 (+0/-0).

                    avec left/right je pense que tu va avoir des problèmes selon les sens de l'expression, et comment tu fait pour gérer vitesse et distance en plus ?

                    "La première sécurité est la liberté"

                    • [^] # Re: Perf

                      Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

                      avec left/right je pense que tu va avoir des problèmes selon les sens de l'expression

                      Non, car Ada ne présuppose pas de la commutatibilité des opérateurs. S'il est un opérateur doit être commutatif, alors tu dois implémenter les deux versions.

                      comment tu fait pour gérer vitesse et distance en plus ?

                      J'ai pas trop compris la question. Mais tu définies les fonctions qu'il te faut et c'est tout.

                      • [^] # Re: Perf

                        Posté par  . Évalué à 3 (+0/-0).

                        En général, le polymorphisme couche mal avec l'héritage. Mais j'imagine qu'ici ce n'est pas de l'héritage.

                        "La première sécurité est la liberté"

                        • [^] # Re: Perf

                          Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

                          C'est assez bizarre ce que tu dis, ou je ne comprends pas ce que tu veux dire. Le polymorphisme "classique" nécessite l'héritage. Donc dire qu'il couche mal avec, c'est un truc que je ne comprends pas.

                          Ici, il n'est pas question d'héritage, juste de surcharge.

                          En Ada, on peut définir une surcharge d'opérateur n'importe où, pas nécessaire dans la classe qui est manipulée. C'est une fonction comme une autre, elle a juste un nom particulier.

                          • [^] # Re: Perf

                            Posté par  . Évalué à 2 (+0/-0).

                            Je vérifie les définitions : L’héritage désigne l’utilisation du structure et du comportement d’une super classe dans une sous-classe. Bien que le polymorphisme se réfère à la modification du comportement d’une super-classe dans une sous-classe.
                            Je vérifie ce qui se fait en C#, Java, Python, etc. Je ne vois pas non plus à quel moment le polymorphisme nécessite l'héritage. :-/

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

                            • [^] # Re: Perf

                              Posté par  . Évalué à 3 (+0/-0).

                              Je pensais surcharge.
                              B hérite A, C hérite de A.

                              A.m(A a, A a) existe (ex: multiplication d'entier).
                              Que pensez de B.m(B b, B b) C.m(C c, C c) C.m(C c, B c) qui existe aussi etc… (multiplication de vitesse ou de temps)

                              "La première sécurité est la liberté"

                              • [^] # Re: Perf

                                Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

                                Je ne suis pas sûr de bien comprendre mais pour ton exemple de vitesse

                                with Ada.Text_Io; use Ada.Text_Io;
                                
                                procedure Vitesse is
                                   type Distance is new Positive;
                                   type Speed is new Positive;
                                
                                   function "*"(Left: Duration; Right: Distance) return Speed
                                   is
                                   begin
                                      return Speed(Left * Positive(Right));
                                   end "*";
                                
                                   function "*"(Left: Distance; Right: Duration) return Speed is ("*"(Right, Left));
                                
                                   My_Dist: Distance := 12;
                                   Time : Duration := 1.0;
                                
                                begin
                                   Put_Line("Speed = " & Speed'Image(My_Dist * Time));
                                end Vitesse;

                                Les types Speed et Distance dérivent du type Positive, la multiplication entre deux distances et entre deux vitesses est donc définies.
                                Par contre, pour mélanger les types entre eux, je dois préciser de quoi il s'agit et comment doit être fait le calcul.
                                Le type Duration est quant à lui un type flottant.

                              • [^] # Re: Perf

                                Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

                                Ok, surcharge, c'est ce que je pensais sans en être sûr.

                                Pas vraiment de problème, car on peut dire ce que l'on souhaite. On peut définir un le type souhaité. Par exemple, on peut dire je veux un paramètre de type "Figure" mais pas un de ses descendants, ou dire, je veux un paramètre de type "Figure" ou un de ses descendants. On peut faire les deux versions.

                                Les langages orientés objets classiques (C++, Java, C#, etc…) ne permettent pas cette distinction.

                                Après, si Ada est un langage objet, il n'est pas tout à fait comme les autres, dans le sens où dans un langage OO classique, l'objet sur lequel on appel à la méthode est implicitement passé en paramètre et accessible via le mot clé "this".

                                En Ada, c'est un paramètre comme un autre. On défini des fonctions qui manipules des objets, et non des méthodes. Du coup, on peut créer les fonctions n'importe où, et pas uniquement dans la classe correspondante. Bon, je suis un peu rouillé, ça fait des lustres que je n'ai pas fait d'Ada donc j'espère ne pas dire trop d'anneries…

                                • [^] # Re: Perf

                                  Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

                                  Après, si Ada est un langage objet, il n'est pas tout à fait comme les autres, dans le sens où dans un langage OO classique, l'objet sur lequel on appel à la méthode est implicitement passé en paramètre et accessible via le mot clé "this".

                                  C'est pareil dans d'autres langages, comme Python par exemple où il faut explicitement mettre le paramètre self en premier lors de la définition d'une méthode.

                                  Pour l'appel de la méthode, en Ada 95 c'était limité à method(object, params…), mais depuis Ada 2005 on peut également écrire object.method(params…).

                                  En Ada, c'est un paramètre comme un autre. On définit des fonctions qui manipules des objets, et non des méthodes. Du coup, on peut créer les fonctions n'importe où, et pas uniquement dans la classe correspondante. Bon, je suis un peu rouillé, ça fait des lustres que je n'ai pas fait d'Ada donc j'espère ne pas dire trop d'anneries…

                                  On peut définir des fonctions/procédures un peu partout (dans des corps de package, de procédure ou fonctions, dans des blocs de code même). Mais on ne peut pas définir des méthodes n'importe où : il faut impérativement les déclarer à la suite de la définition du type de la classe et avant la classe suivante.

                                  Exemple :

                                      type Foo is tagged
                                         record
                                            ...
                                         end record;
                                  
                                      type Bar is tagged
                                         record
                                            ...
                                         end record;
                                  
                                      procedure P1 (Self : Bar; ...);
                                      procedure P2 (Self : Bar; ...);
                                      procedure P3 (Self : Foo; ...);

                                  Le compilateur va dire que P3 est déclarée trop tard (this primitive operation is declared too late). Elle doit être déclarée avant le type Bar.

                                  La POO dans Ada est apparue avec Ada 95, ce n'était pas natif au langage auparavant. Ça donne des constructions un peu exotiques comparées à d'autres langages directement conçus pour être orientés objet.

                            • [^] # Re: Perf

                              Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

                              Je ne vois pas non plus à quel moment le polymorphisme nécessite l'héritage. :-/

                              Réponse ici :

                              Bien que le polymorphisme se réfère à la modification du comportement d’une super-classe dans une sous-classe.

                              Notion de super-classe et de sous-classe, donc héritage ;)

                              • [^] # Re: Perf

                                Posté par  . Évalué à 2 (+0/-0).

                                Arf possible. En regardant les exemples de mise en œuvre dans certains langages (C#/C++/Java) j'ai surtout vu la « modification du comportement » d'une classe instanciée en tentant de surcharger le retour d'une de ses méthodes.
                                Heureusement qu'il a précisé sa pensé entre temps parce-que les implémentations des concepts et tout ça (cf. le polymorphisme dans Python et dans Smalltalk)

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

    • [^] # Re: Perf

      Posté par  . Évalué à 10 (+10/-0).

      Une fois j'ai taquiné un collègue sur ce point (à savoir la lenteur de la compilation de Rust). Il m'a répondu :
      OK, mais Rust compile vraiment…

      J'ai trouvé sa réponse marrante mais assez pertinente.

      • [^] # Re: Perf

        Posté par  (site Web personnel) . Évalué à 8 (+5/-0).

        Tu peux lui répondre: oui mais moi avec $lang_qui_compile_vite je travaille vraiment !

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

        • [^] # Re: Perf

          Posté par  . Évalué à 7 (+5/-0).

          D'ailleurs ça fait 2 jours que je déplie du code pour essayer de comprendre où un null vient s'insérer dans mon vecteur.
          Heureusement qu'en java on a des temps de compilation un poil plus rapide.

          • [^] # Re: Perf

            Posté par  . Évalué à 10 (+12/-0).

            Mais dommage que tu n'ai pas un langage qui fasse que ça n'arrive pas 😁

        • [^] # Re: Perf

          Posté par  . Évalué à 3 (+1/-0).

          Cela dit, avec un système de build qui ne reconstruit que ce qui a changé, ça peut passer. Le problème, c'est quand c'est l'édition des liens qui est lente…

      • [^] # Re: Perf

        Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

        À noter qu'on peut demander à cargo de ne PAS compiler justement :
        cargo check

        Ça compile pas, c'est plus rapide et comme le nom l'indique ça permet quand même de vérifier son code.

        Matthieu Gautier|irc:starmad

    • [^] # Re: Perf

      Posté par  . Évalué à 2 (+1/-0).

      Le langage est complexe donc lent a compiler. Pareil pour C++.
      C est simple donc rapide a compiler. Rien ne bien étonnant donc

      • [^] # Re: Perf

        Posté par  . Évalué à 6 (+5/-0).

        Ce n'est pas vraiment une bonne dichotomie, à moins de considérer qu'OCaml est simple parce qu'il est compilé rapidement.

      • [^] # Re: Perf

        Posté par  . Évalué à 3 (+2/-1).

        C’est pas tant une question de volume de fonctionnalité du langage, plutôt une question de nature des fonctionnalités … Ce qui fait que C++ est long à compiler c’est principalement une fonctionnalité, les template qui sont Turing complètes et qui peuvent générer beaucoup de génération de code.

        Pour Ada et SPARK c’est pas la complexité du langage, Rust est pas si compliqué, c’est plus que le compilateur fait de l’analyse statique pour vérifier que le code est correct, ce qui peut prendre du temps. Certaines constructions buguées qui sont valides en C et que le compilateur laisserait passer sans broncher sont non valides en Rust, par exemple. Mais ce serait pareil si on avait un langage avec juste les feature de C auquel on aurait simplement ajouté les contraintes de Rust sur les pointeurs.

        • [^] # Re: Perf

          Posté par  . Évalué à 2 (+0/-0).

          Tout à fait. On le voit bien à certains messages d'erreurs de ces compilateurs qui ressemblent fortement à ceux des outils d'analyse statique pour C par exemple (il y en a pour d'autres langages mais je n'ai pas testé), outils qui mettent aussi un certain temps à faire leur boulot.

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

      • [^] # Re: Perf

        Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

        Plutôt que la complexité du langage, ce que fait le compilateur : À savoir déterminer le scope des variables créées pour bien les libérer, déterminer si le code a une cause déterminable d'erreur, quelques tests qu'on peut aussi étendre…

        Franchement, Rust a un compilateur assez punitif, mais alors, quel confort !

    • [^] # Re: Perf

      Posté par  (site Web personnel) . Évalué à 7 (+5/-0). Dernière modification le 20/11/21 à 11:03.

      Il faut distinguer deux choses:

      • Spark est un sous-ensemble d'Ada et se compile donc normalement avec le compilateur Ada
      • Un code Spark peut (et devrait sinon, autant faire de l'Ada, c'est plus simple) être vérifié

      Les temps de compilation sont donc les temps du compilateur Ada qui n'est pas non plus franchement le plus rapide du Far West.
      Ceci dit, c'est normal, il compile beaucoup plus de choses qu'un compilateur C, ne serait-ce que les spécifications (en gros, les headers C) et vérifie tout une batterie de règles de cohérence (compatibilité des types, portée des pointeurs…).

      A cela, s'ajoute dans le cas de Spark, l'étape de preuve du programme.
      Cette étape fait appel à un autre outil que le compilateur dont le but est de transcrire les éléments Spark (post-, pré-conditions, invariants de boucle, assertions) dans le langage Why3.
      Le "programme" Why3 est ensuite envoyé au moteur de preuve pour être analysé. Cette étape peut être très longue, beaucoup plus qu'une simple compilation mais l'enjeu n'est vraiment pas le même qu'une "simple" compilation.

      A ce jour, les "provers" CVC4, Z3 et Alt-Ergo sont supportés et il est parfois nécessaire de faire passer son programme à la moulinette d'un ou plusieurs de ces programmes.

      Petit anecdote, après discussion avec Yannick Moy à l'OSXP , Adacore a commencé à décorer la bibliothèque standard avec du Spark, histoire de prouver qu'il n'y a pas d'erreur dedans… Il semblerait qu'ils aient d'ailleurs trouvé une petite erreur passée inaperçue depuis des lustres :D

      Voilà, j'espère avoir répondu à la question sans avoir dit trop de conneries :D

      • [^] # Re: Perf

        Posté par  . Évalué à 3 (+1/-0).

        Non, t'as pas dit de connerie, tout en restant succint ;-)

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

  • # License

    Posté par  . Évalué à 4 (+3/-0).

    À mon avis le système de license sur Ada est un frein par rapport à Rust.

    • [^] # Re: License

      Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

      Je suis pas sûr de comprendre, tu peux élaborer ? C'est un langage normé implémenté par des compilateurs indépendants (comme GNAT).

      Comme C et C++, écrire du code ne te soumet pas à une licence.

      l'azerty est aux dispositions ce que subversion est aux SCMs

      • [^] # Re: License

        Posté par  (site Web personnel) . Évalué à 8 (+7/-1).

        De mémoire, c'est au niveau des compilateurs que cela se passe.

        Un compilateur ne peut se prétendre comme tel qu'après avoir passé une série de test et être certifié. Donc oui, le langage est normé, mais il y a une étape de validation des outils (notamment compilateur) ensuite.

        En "libre" je ne connais que GNAT. Et encore, il me semble qu'il n'implémente pas tout Ada. Les seuls compilateurs à implémenter entièrement la norme sont propriétaires. Et GNAT ne peut être utilisé que pour développer des logiciels libres (c'est dans la licence).

        • [^] # Re: License

          Posté par  . Évalué à 5 (+3/-0).

          C'est ce qu'on trouve pour java aussi. C'est pas au niveau du compilateur (le compilateur C1 (celui qui transforme les .java en .class) qui est plutôt simple), mais soit de la bibliothèque standard soit de la jvm (ou des 2). Il y a une batterie de tests nommé TCK (Technology Compatibility Kit). Ça a toujours fait couler beaucoup d'encre, mais il me semble que tu as le droit de faire sans (c'est ce que Google a fait pour android, mais ils sont pas seuls et c'est les seuls à avoir subi un procès et ils l'ont gagné) et tu peut bidouiller comme tu veux OpenJDK l'implémentation de référence qui passe les tests et qui est en GPL2.

        • [^] # Re: License

          Posté par  . Évalué à 4 (+2/-0).

          Donc (je sais que ce n'est pas académique de commencer une phrase ainsi) on est d'accord qu'il n'y a pas de licence sur le langage lui-même (ouf) ; mais qu'il s'agit de compilateurs certifiés (dont la majorité est propriété, mais il y a quand même GNAT qui est une référence libre…)

          Ça tombe bien : comme c'est utilisé pour des choses critiques, on aimerait avoir la garantie d'obtention du même code quelque soit la chaîne de compilation.
          Pour l'instant, pour Rust, il n'y a que La Fondation qui s'en occupe. Mais à terme ça devrait pouvoir évoluer, et si comme pour C ou Pascal ou d'autres il y a incompatibilité entre les compilos ça va moyennement le faire non ?

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

          • [^] # Re: License

            Posté par  (site Web personnel) . Évalué à 2 (+1/-1).

            on est d'accord qu'il n'y a pas de licence sur le langage lui-même (ouf)

            On est d'accord. C'est un standard ISO. Bon, l'accès aux documents est payant mais le langage en lui-même est utilisable.

            Au pire, tu dis que tu fais du "Lovelace", un dérivé d'Ada non certifié et tu seras tranquille :p (car je ne sais pas si le terme Ada est protégé ou non)

            Mais même si le langage est "libre", il n'existe pas de compilateur aujourd'hui qui le soit. Comme je le disais plus haut, même GNAT, pourtant sous licence libre, ne peut être utilisé que pour des projets open-source… sinon, il faut passer sur une version GNAT Pro. Et d'après ce que je lis ici, ça coûte une blinde (ticket d'entrée à 15 000 $ en 2011 !)

            • [^] # Re: License

              Posté par  . Évalué à 5 (+3/-0).

              J'ai du mal comprendre une partie.
              De ce que je comprend de la licence justement on peut faire du pas libre (https://en.wikipedia.org/wiki/GNAT_Modified_General_Public_License).

              • [^] # Re: License

                Posté par  (site Web personnel) . Évalué à 2 (+1/-1).

                GNAT permet une gestion des licences via des pragmas.

                Grosso modo, l'idée s'est de pouvoir vérifier la licence du logiciel final. La version GPL modifié de GNAT (GMGPL), c'est un peu l'équivalent de la LGPL (je schématise). Grosso modo, ton programme peut utiliser une bibliothèque (unit dans le langage Ada) sans avoir besoin d'être sous GPL.

                Mais la licence dit aussi ceci :

                This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Public License.

                Autrement dit, ce n'est pas parce que tu utilises une bibliothèque sous GMGPL que ton programme doit être sous GMGPL, mais cela ne veut pas dire que ton programme ne doit pas être sous GMGPL pour une autre raison.

                GNAT, s'il existe bien une version community, existe aussi sous licence "entreprise" et "assurance". Ces deux dernières licences permettent de développer n'importe quel type de logiciel. La community, le logiciel doit impérativement être sous GPL.

                • [^] # Re: License

                  Posté par  (site Web personnel) . Évalué à 5 (+3/-0). Dernière modification le 19/11/21 à 09:01.

                  GNAT, s'il existe bien une version community, existe aussi sous licence "entreprise" et "assurance". Ces deux dernières licences permettent de développer n'importe quel type de logiciel. La community, le logiciel doit impérativement être sous GPL.

                  Le logiciel final doit obligatoirement être sous GPL ? Si c'est le cas je comprends sa non-adoption (pas une critique de la GPL, mais je peux comprendre la non volonté d'être obligatoirement obligé d'utiliser cette licence). Par contre synth, un outil similaire à poudriere est fait par un contributeur FreeBSD est écrit en Ada et sa licence est ISC. Comment est-ce possible alors ?

                  l'azerty est aux dispositions ce que subversion est aux SCMs

                  • [^] # Re: License

                    Posté par  . Évalué à 4 (+2/-0).

                    Nos réponses se sont croisées :-) Justement, le produit final ne doit pas être obligatoirement sous GPL : Synth en est la preuve. Par contre, si tu compiles avec GNAT et que ça fait appel à des bibliothèques externes (le besoin est assez rare à ma connaissance), soit celles-ci sont libres soit elles doivent être distribuées : il ne faudrait pas que tu te retrouves coincé pour faire évoluer/tourner/évaluer ton programme.

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

                    • [^] # Re: License

                      Posté par  (site Web personnel) . Évalué à 2 (+1/-1).

                      Justement, le produit final ne doit pas être obligatoirement sous GPL : Synth en est la preuve. Par contre, si tu compiles avec GNAT

                      C'est plus fin que ça. Si tu distribue des binaires de ton programme, et que les binaires sont compilés via GNAT community, alors oui, ton programme doit être sous GPL.

                      Si tu ne distribues que les sources, impossible de savoir à l'avance le compilateur (incluant le type de licence) qui sera utilisé, et donc si la contrainte de licence s'applique ou non.

            • [^] # Re: License

              Posté par  . Évalué à 3 (+1/-0).

              C'est un standard ISO. Bon, l'accès aux documents est payant mais le langage en lui-même est utilisable.

              C'est valable pour tous les autres aussi, y compris le très répandu C. C'est ainsi que se finance, en partie, le groupe de normalisation…

              Au pire, tu dis que tu fais du "Lovelace", un dérivé d'Ada non certifié et tu seras tranquille :p (car je ne sais pas si le terme Ada est protégé ou non)

              Je dirai plutôt Augusta que Lovelace ou Byron :-)
              Je ne sais pas si le nom est protégé, et je n'ai pas trouvé de trace (pas pris le temps de bien chercher ceci dit.) Cependant, le nom étant déjà bien établi, ça n'apporte rien d'utiliser le même nom pour un langage différent (c'est la raison pour laquelle il y a, par exemple, ObjectiveC/C++/C#/etc.) Maintenant, si c'est juste un compilateur (et non un autre langage) bah il faut, pareillement, juste que ça s'appelle pas GNAT (pour reprendre le cas du C, on a bien : MS Visual C++, GCC C, Tiny C, Clang, Turbo C, etc. ; pareil, pour Ada aussi, il y a divers autres crèmeries.) Après, quand les applications sont écrites pour des milieux critiques et par/pour des entreprises devant montrer/avoir des garanties, il leur faut des compilateurs (et des environnements/chaines de développement) certifiés…

              Mais même si le langage est "libre", il n'existe pas de compilateur aujourd'hui qui le soit.

              GNAT est l'implémentation de référence libre (comme le sont OpenJDK et OpenJRE pour l'écosystème Java) portée par la FSF… Comme c'est la référence, par rapport aux standards du langage, ça ne peut pas partir dans n'importe quel sens. Mais rien n'empêche, à ma connaissance, d'avoir d'autres implémentations ouvertes/libres (visiblement le besoin ne s'est pas fait sentir.)

              Comme je le disais plus haut, même GNAT, pourtant sous licence libre, ne peut être utilisé que pour des projets open-source… sinon, il faut passer sur une version GNAT Pro. Et d'après ce que je lis ici, ça coûte une blinde (ticket d'entrée à 15 000 $ en 2011 !)

              Je ne vois pas en quoi c'est problématique de faire de l'Open-Source, qui n'est pas incompatible avec la monétisation (c'est juste que dans ce cas, le client doit pouvoir avoir accès aux sources et non se retrouver pris en otage…) Et de surcroit je n'ai pas vu cette obligation.

              Je cite cette remarque d'il y a six ans, sur Reddit /r/ada/ :

              If you're going to write Ada software using a free Ada compiler you have basically three options:

              • FSF Ada - This is what is provided on most Linux distributions. You can use this to develop non-free software, just as you could use Emacs to write it.
              • GNAT GPL - This is acquired directly from AdaCore. It is free, and all software compiled with it and subsequently distributed is covered by the full GPL. (No LGPL at all.)
              • GNATPro - This is the professionally supported version of GNAT Ada, and is quite expensive for a single developer--though the support is exemplary because that's what you're paying for. You can develop non-free software with this version.

              Les deux premiers ont fusionné et la GMGPL en a assoupli l'utilisation en passant de la GPL à un équivalent LGPL qui concerne bien la/les chaîne/outils de compilation (et les bibliothèques embarquées) comme précisé ailleurs en 1998 déjà

              a "modfied GPL" like that for libgcc2 that essentially allows you to incorporate runtime code without ANY restrictions if you simply link with what is provided. This means you can compile with GNAT, link with the standard runtime routines, and distribute without concerns for the GPL. However, if you do modify the runtime or incorporate other code that has an unmodified GPL or the LGPL all bets are off.

              Perso, je trouve ça rassurant…

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

              • [^] # Re: License

                Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

                Du coup, maintenant, je répond ici ;)

                D'accord avec quasiment tout, sauf ceci :

                If you're going to write Ada software using a free Ada compiler you have basically three options:

                FSF Ada - This is what is provided on most Linux distributions. You can use this to develop non-free software, just as you could use Emacs to write it.
                GNAT GPL - This is acquired directly from AdaCore. It is free, and all software compiled with it and subsequently distributed is covered by the full GPL. (No LGPL at all.)
                GNATPro - This is the professionally supported version of GNAT Ada, and is quite expensive for a single developer--though the support is exemplary because that's what you're paying for. You can develop non-free software with this version.

                Les deux premiers ont fusionné et la GMGPL en a assoupli l'utilisation en passant de la GPL à un équivalent LGPL qui concerne bien la/les chaîne/outils de compilation (et les bibliothèques embarquées) comme précisé ailleurs en 1998 déjà

                Les deux premiers n'ont pas fusionnés et existe encore aujourd'hui. Il semblerait que la version GNAT Community soit un peu plus en avance que la version GNAT FSF (en terme de version, d'après ce que j'ai pu lire).

                • [^] # Re: License

                  Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

                  Il semblerait que la version GNAT Community soit un peu plus en avance que la version GNAT FSF (en terme de version, d'après ce que j'ai pu lire).

                  Oui, les développements sont faits avant tout pour Gnat Pro ce qui est compréhensible vu que c'est le fond de commerce d'Adacore.
                  Ensuite, tous est remis dans la version Community avant d'être finalement mergé dans la version FSF.

                  De mémoire, la version Community 2021 sera la dernière fournie par Adacore, il ne restera donc que la version FSF.

                  On verra donc ce qu'il se passera en 2022 :)

                • [^] # Re: License

                  Posté par  . Évalué à 2 (+0/-0). Dernière modification le 20/11/21 à 11:55.

                  [FSF Ada / GNAT GPL / GNATPro]

                  Les deux premiers ont fusionné et la GMGPL en a assoupli l'utilisation en passant de la GPL à un équivalent LGPL qui concerne bien la/les chaîne/outils de compilation (et les bibliothèques embarquées) comme précisé ailleurs en 1998 déjà

                  Les deux premiers n'ont pas fusionnés et existe encore aujourd'hui. Il semblerait que la version GNAT Community soit un peu plus en avance que la version GNAT FSF (en terme de version, d'après ce que j'ai pu lire).

                  Tu veux dire « un peu plus en avance » dans le sens où c'est la RC de ce qui sera livré à la FSF (si c'est le cas ça fait sens vu que c'est AdaCore qui qui fait le gros du boulot et travaille en parallèle pour sa version Pro) ? Ou tu veux dire que le majeur de la version Community est largement au dessus de celle de la version Free ?
                  Ou tu parles de l'intégration dans les distributions Linux, qui effectivement n'est pas toujours au taquet de ce qui est disponible côté FSF ?

                  Edit: Je viens de voir que BackKnight a répondu que c'est la première proposition qu'il faut comprendre

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

            • [^] # Re: License

              Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

              Après vérification sur mon exemplaire de la norme AFNOR d'Ada 83 et le site de Ada Information Clearinghouse, il se trouve que la norme est le manuel de référence.
              Toutes les révision de la norme sont donc bien accessibles gratuitement ici.

        • [^] # Re: License

          Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

          En "libre" je ne connais que GNAT. Et encore, il me semble qu'il n'implémente pas tout Ada. Les seuls compilateurs à implémenter entièrement la norme sont propriétaires.

          Je veux bien que tu dises quelles parties ne sont pas implémentées. En effet, Adacore, qui est le plus gros contributeur à Gnat, fait justement l'effort de coller à la norme de très près et est même en avance par rapport à la publication des révisions.

          Peut-être parles-tu des annexes ?

  • # Site d'ada core

    Posté par  . Évalué à 4 (+2/-0).

    Ah oui, mais SPARK ?

    Je ne trouve pas de code sur le site d'adacore… Je trouve fou que le site qui est là pour promouvoir un langage ne présente pas rapidement ce langage. Tous les langages ne sont pas parfait sur ce point, mais c'est tout de même de loin le pire je trouve, même java travail dessus en mettant en avant dev.java (toujours pas parfait mais mieux).

  • # Se remettre dans la syntaxe cryptique

    Posté par  (site Web personnel) . Évalué à 10 (+9/-0). Dernière modification le 18/11/21 à 10:05.

    Je me suis également mis au Rust il y a quelque années. Comme d'habitude, j'ai travaillé sur de petits projets pour me faire la main (par exemple, rollgui - jeux 2D, rollac - serveur d'IA pour rolling, trsync - synchro de fichiers Tracim).

    De mon point de vue, la principale difficulté quand on fait une pause dans son apprentissage de Rust ou plus simplement quand on progresse au début, c'est de maîtriser les concepts de propriétés. Concevoir son application sans se retrouver à vouloir modifier par mutabilité n'importe où.

    Cela nécessite de maitriser le concept de flux/messages dans l'application.

    Merci pour ces articles !

    Blog: http://blog.bux.fr, github: http://github.com/buxx

    • [^] # Re: Se remettre dans la syntaxe cryptique

      Posté par  . Évalué à 2 (+1/-0).

      Concevoir son application sans se retrouver à vouloir modifier par mutabilité n'importe où.
      Cela nécessite de maitriser le concept de flux/messages dans l'application.

      As-tu des ressources à conseiller à ce niveau justement ? Merci!

  • # Juste pour rappel ou info, c'est selon

    Posté par  (site Web personnel) . Évalué à 10 (+7/-0).

    Il y a un atelier découverte du langage Ada ce samedi 20 novembre à Courbevoie. Juste au cas où vous ne liriez pas les dépêches relayant l'Agenda du libre :-)

    « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

  • # Jamais Ada ne sera utiliser ailleurs que dans son domaine.

    Posté par  . Évalué à 3 (+3/-1). Dernière modification le 22/11/21 à 14:11.

    Coder en Ada est bien plus long et complexe que coder en Rust. Rust n'est pas sécurisé en sois, il est juste plus sécurisé que C/C++ mais beaucoup moins qu'Ada.

    En fait Rust est mémory safe (et encore pas totalement parfaitement) alors qu'Ada est aussi exécution safe. A savoir qu'on peut vérifier qu'un programme Ada ne fera pas une boucle infini ou ne fera pas une multiplication qui dépassera la valeur d'un Int. Mais pour arriver a ce résultat, il faut tout dire a Ada. Cela a un intérêt pour un avion, beaucoup moins pour un jeux vidéo ou même pour un driver. Surtout qu'Ada perd un peu en performance par rapport a Rust ou C/C++.

    Pour rappel Python ou Java ne sont pas des langages sûr d'un point de vue exécution, ils peuvent faire des plantages. C'est juste qu'ils ne feront pas de "segfault" car l'interpréteur est là.

    Rust est une révolution car il apporte le mémory safe dans les langages compilés (sans VM) sans avoir a s'en pré-occuper réellement (pour rappel Go et d'autres compilent leur VM dans le binaire).

    En informatique la constante c'est le taux performances x productivité. Si on augmente la productivité du langage on baisse les performance (ou la sécurité). Avec les progrès en langages on fait progresser cette constante de 3 manière:
    1) Les performances du compilateur et de la VM. Les performances de l'OS et des processeur (optimisation hardware).
    2) Les idées de langages (Rust introduit de nouvelles idées)
    3) Les frameworks et solutions dans la manière de faire.

    Alors on peut classer les langages du plus productif au plus performant/sécurisé ainsi Python, Go/Java, Rust, Ada.

    Une fois le langage choisit, un développeur peut améliorer les performances/sécurité en passant plus de temps sur son programme.

    • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

      Posté par  (site Web personnel) . Évalué à 4 (+2/-0). Dernière modification le 22/11/21 à 21:48.

      Coder en Ada est bien plus long et complexe que coder en Rust.

      C'est une question de point de vue :)

      A savoir qu'on peut vérifier qu'un programme Ada ne fera pas une boucle infini ou ne fera pas une multiplication qui dépassera la valeur d'un Int. Mais pour arriver a ce résultat, il faut tout dire a Ada.

      Alors si on parle de vérifier, ce sera via du Spark mais sinon, il y a juste à définir des types ce qui n'est pas en soi insurmontable.
      Alors oui, il faut tout dire mais ça documente aussi beaucoup le code.

      Surtout qu'Ada perd un peu en performance par rapport a Rust ou C/C++.

      Source ? Usuellement, on estime que le code Ada est 30% plus lent que le code C et équivalent au code C++, sans retirer les runtime checks sinon, c'est équivalent au C. Mais bon, j'ai pas plus de source :D

      • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

        Posté par  . Évalué à 4 (+2/-0).

        A savoir qu'on peut vérifier qu'un programme Ada ne fera pas une boucle infini ou ne fera pas une multiplication qui dépassera la valeur d'un Int. Mais pour arriver a ce résultat, il faut tout dire a Ada.

        Alors si on parle de vérifier, ce sera via du Spark mais sinon, il y a juste à définir des types ce qui n'est pas en soi insurmontable.
        Alors oui, il faut tout dire mais ça documente aussi beaucoup le code.

        Le lien suivant montre qu'il ne faut justement pas tout lui dire, mais plutôt que les choses sont dites explicitement (y compris quand on veut faire des conneries contre lesquelles il y a nativement un garde-four, alors qu'en face on s'expose à des surprises ou on rajoute de la bordure cryptique) http://archive.adaic.com/intro/ada-vs-c/ada-vs-c.html
        Corolaire, pour obtenir le même niveau de "ité" en C il faut en dire bien bien plus… https://www.electronicdesign.com/technologies/iot/article/21801203/comparing-ada-and-c
        Voir aussi https://www.adahome.com/History/Steelman/steeltab.htm

        Surtout qu'Ada perd un peu en performance par rapport a Rust ou C/C++.

        Source ? Usuellement, on estime que le code Ada est 30% plus lent que le code C et équivalent au code C++, sans retirer les runtime checks sinon, c'est équivalent au C. Mais bon, j'ai pas plus de source :D

        J'ai terminé le journal par ce lien : https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gnat-rust.html
        Comme tu dis, la lenteur apparente est souvent due aux vérifications supplémentaires pendant l'exécution. À noter aussi que la performance du code Ada dépend du compilateur sous-jacent (si on utilise GNAT c'est bien GCC au final) et de ses options… Cf. http://computer-programming-forum.com/44-ada/99cf01d940383de5.htm et http://computer-programming-forum.com/44-ada/641218ec0d2aba9c.htm par exemple.

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

        • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

          Posté par  . Évalué à 2 (+1/-0). Dernière modification le 23/11/21 à 09:47.

          Il y a aussi autre chose et non des moindre, c'est que si les spécifications ont toujours été assez libre d'accès les compilateurs ont toujours eu un train de retard et sont closed-sources pour les plus complet. En fait Ada est un langage qui ne proposait pas vraiment de solutions techniques. Et au départ, beaucoup de ses spécificités n'étaient pas implémenté fautes de solution techniques. Aujourd'hui c'est un peu différent car GNAT arrive a un niveau correct (mais derrière les version payantes, et même très chères).

          Ceci lui fait un gros handicap marketing, il a une image de langage élitiste, mal fini et cher (un peu comme COBOL). Rust est tout au contraire, open-source, plein de librairies, avec un compilateur open-source…

          PS : Perso j'ai découvert Ada avec le projet open-source GHDL (Compilateur et simulateur de VHDL) il y a plus de 5 ans.

          • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

            Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

            Il y a aussi autre chose et non des moindre, c'est que si les spécifications ont toujours été assez libre d'accès les compilateurs ont toujours eu un train de retard et sont closed-sources pour les plus complet.

            Vrai en 1983, beaucoup moins à partir de 1995… D'ailleurs Gnat existe depuis cette date, quand le compilateur a passé l'ACATS 95 avec succès.

            En fait Ada est un langage qui ne proposait pas vraiment de solutions techniques. Et au départ, beaucoup de ses spécificités n'étaient pas implémenté fautes de solution techniques.

            Est-ce au langage de fournir les solutions techniques ? Les standards C et C++ ne fournissent absolument de façon d'implémenter le compilateur. D'ailleurs, il y a quelques années, au boulot, pour des raisons de performances, on utilisait ICC (Intel C++ Compiler) en lieu et place de GCC, les deux compilateurs différent dans la génération du code assembleur.

            Aujourd'hui c'est un peu différent car GNAT arrive a un niveau correct (mais derrière les version payantes, et même très chères).

            Encore une fois, je veux bien une source.

            Ceci lui fait un gros handicap marketing, il a une image de langage élitiste, mal fini et cher (un peu comme COBOL). Rust est tout au contraire, open-source, plein de librairies, avec un compilateur open-source…

            Ce dont tu parles date d'il y a plus de 30 ans et il y a un compilateur opensource conforme à la norme depuis 27 ans.
            Par contre, oui, il n'y a pas plein de bibliothèques contrairement à Rust.

            • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

              Posté par  . Évalué à 0 (+1/-2).

              Les standards C et C++ ne fournissent absolument de façon d'implémenter le compilateur

              Ils ne fournissent pas de façon explicite l'implémentation, mais ils savent que c'est faisable et ils expliquent les grandes lignes. Alors que pour Ada il a fallut attendre très longtemps (plus de 10 ans de mémoire) pour avoir un compilateur et encore il a fallut bien plus de temps (30 ans?) pour avoir une implémentation complète. Le problème était que de base techniquement il était pratiquement impossible à implémenter. Quand tu dis Gnat résout le problème depuis 27 ans, il y a 27 ans son implémentation n'était que très partiel (Il y a 15 ans je lisais des articles expliquant a quel point).

              Je ne suis pas là pour dire qu'Ada est un mauvais langage, mais il faut quand même remettre les choses dans leurs contextes. Et quand pendant 20 ans ou 30 ans un langage est en développement, fermé forcément même si depuis 20 ans il est au point les informaticien s'en sont détourné et il n'a pas fédéré une communauté et se retrouve très discriminé. C'est une question de marketing.

              • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

                Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

                Ils ne fournissent pas de façon explicite l'implémentation, mais ils savent que c'est faisable et ils expliquent les grandes lignes. Alors que pour Ada il a fallut attendre très longtemps (plus de 10 ans de mémoire) pour avoir un compilateur et encore il a fallut bien plus de temps (30 ans?) pour avoir une implémentation complète.

                Si on regarde cette frise, les deux premiers compilateurs à passer les tests de conformité sont le compilateur de l'université de New York en 1983 et le compilateur pour Vax de DEC en 1984, puis ALSYS en 1987.
                Pour Ada 95, le compilateur Gnat est donc sorti en 1995, comme je l'ai déjà précisé, t celui d'Intermetrics pour le missile Patriot (because le runtime)… On est loin des 10 ans.
                Effectivement pour la version 2012, seul Gnat était prêt rapidement et PTC a sorti sa version 10 d'ObjectAda qui est certifié Ada 2012 l'année dernière.

                Quand tu dis Gnat résout le problème depuis 27 ans, il y a 27 ans son implémentation n'était que très partiel (Il y a 15 ans je lisais des articles expliquant a quel point

                Au risque de me répéter, je veux bien des sources !
                Il y a 27 ans, Gnat passait le test de conformité ACATS pour Ada 95 ce qui en faisait de facto un compilateur Ada 95 complet hors annexes non normatives.

                Je ne suis pas là pour dire qu'Ada est un mauvais langage, mais il faut quand même remettre les choses dans leurs contextes. Et quand pendant 20 ans ou 30 ans un langage est en développement, fermé forcément même si depuis 20 ans il est au point les informaticien s'en sont détourné et il n'a pas fédéré une communauté et se retrouve très discriminé. C'est une question de marketing.

                Donc si j'ai bien compris, tu considères aussi que le C++ est toujours en développement depuis 40 ans, encore plus fermé qu'Ada puisque la norme n'est pas récupérable librement et gratuitement (cf. le site isocpp) ?
                Ce qui est drôle, c'est que j'ai récupéré du code Ada 83 qui date de 1993 et qui se compile encore très bien sur un compilateur moderne… Pas mal pour un langage en cours de développement.

                En dehors de ça, ce qui a fait qu'Ada n'a pas décollé rapidement, c'est simplement que ce n'est pas du C-like mais Pascal-like.
                D'un autre côté, quand on venait du C, faire du C++, c'était simple (au passage, c'est faux sauf à faire du C with classes).
                Pour faire de l'Ada, il fallait apprendre un nouveau langage, de nouveaux concepts et se plier à une rigueur importante.
                Donc c'est chiant, ce n'est pas hackable facilement, on ne peut pas pisser de la ligne facilement sans se faire traiter par le compilo.

      • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

        Posté par  . Évalué à 2 (+2/-1). Dernière modification le 23/11/21 à 09:49.

        Je ne savais pas que l'on pouvait retirer les "runtime checks". Mais si en les retirant on perd beaucoup de sa sécurité… Rust reprends l'avantage.

      • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

        Posté par  . Évalué à 5 (+3/-0).

        […] il y a juste à définir des types ce qui n'est pas en soi insurmontable.
        Alors oui, il faut tout dire mais ça documente aussi beaucoup le code.

        Disclaimer : je ne connais pas Ada.

        C'est pas forcément si simple que ça d'exprimer des types. J'ai pas l'impression que ce soit un travers d'Ada, mais quand je vois le niveau d'abstraction continuellement utilisé dans les exemples d'Haskel par exemple ça laisse sur le carreau pas mal de gens.

        Ensuite ce qui est compliqué c'est moins de définir des types que de maintenir des propriétés (lié à ces types). Souvent j'ai le cas de vérifier qu'une fonction polymorphique maintiens des propriétés? Ça peut être compliqué (ou demander beaucoup de types ou beaucoup de spécialisation de la fonction → ce qui est un peu triste).

        Par exemple :

        • J'ai une fonction qui ajoute des roues à la voiture que je lui donne ;
        • Comment faire comprendre au compilateur que si je lui donne une peugeot j'aurais une peugeot en retour ?
    • [^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.

      Posté par  (site Web personnel) . Évalué à 3 (+0/-0).

      Rust est une révolution car il apporte le mémory safe dans les langages compilés (sans VM) sans avoir a s'en pré-occuper réellement

      Bof, il faut se préoccuper de la mémoire 42 plus que dans un langage à ramasse miette :-)

      (pour rappel Go et d'autres compilent leur VM dans le binaire).

      Gnii? VM != GC

      Alors on peut classer les langages du plus productif au plus performant/sécurisé ainsi Python, Go/Java, Rust, Ada.

      Pas sûr que Rust soit plus sécurisé que Java :-)

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

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.