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 devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 17 novembre 2021 à 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 Thomas Douillard . Évalué à 5.
Extrait de l’article précédent :
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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Perf
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
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é"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Perf
Posté par Anonyme . Évalué à 4. Dernière modification le 19 novembre 2021 à 15:03.
En Go par exemple c’est pas possible, alors même que les développeurs aiment redéfinir tout un tas de types :
Il faut « caster »
t
entime.Duration
:Pourtant,
time.Duration
est juste un « alias » du typeint64
.[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Perf
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
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é"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Perf
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
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é"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Perf
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 3.
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 Blackknight (site web personnel, Mastodon) . Évalué à 3.
Je ne suis pas sûr de bien comprendre mais pour ton exemple de 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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Perf
Posté par Meku (site web personnel) . Évalué à 4.
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…).
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 :
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Perf
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
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 Michaël (site web personnel) . Évalué à 2.
Et comment est-ce que ça résout l'associativité? Ou alors il faut explicitement mettre les parenthèses? P.ex
( n1 * n2) * duration vs n1 * n2 * duration vs n1 * (n2 * duration)
(Qu'est-ce qu'on doit dire au compilateur pour pouvoir écrire l'expression du milieu?)
[^] # Re: Perf
Posté par woffer 🐧 . Évalué à 10.
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 devnewton 🍺 (site web personnel) . Évalué à 8.
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 Elfir3 . Évalué à 7.
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 xoddark . Évalué à 10.
Mais dommage que tu n'ai pas un langage qui fasse que ça n'arrive pas 😁
[^] # Re: Perf
Posté par Dring . Évalué à 3.
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 GaMa (site web personnel) . Évalué à 4.
À 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 ff9097 . Évalué à 2.
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 octachron . Évalué à 7.
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 Thomas Douillard . Évalué à 3.
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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
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 Da Scritch (site web personnel, Mastodon) . Évalué à 6.
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 Blackknight (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 20 novembre 2021 à 11:03.
Il faut distinguer deux choses:
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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
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 nlgranger . Évalué à 4.
À mon avis le système de license sur Ada est un frein par rapport à Rust.
[^] # Re: License
Posté par David Demelier (site web personnel) . Évalué à 5.
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.
git is great because linus did it, mercurial is better because he didn't
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: License
Posté par barmic 🦦 . Évalué à 5.
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.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: License
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: License
Posté par Lutin . Évalué à 5.
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).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: License
Posté par David Demelier (site web personnel) . Évalué à 5. Dernière modification le 19 novembre 2021 à 09:01.
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 ?
git is great because linus did it, mercurial is better because he didn't
[^] # Re: License
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: License
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Non… https://www.developpez.net/forums/d762463/autres-langages/autres-langages/ada/gnu-gnat-license/
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: License
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Je l'avais mentionné ailleurs mais nos messages ont du se croiser
;-)
Après, c'est vrai que de prime abord, ce n'est pas clair ; et de toute façon tout ce qui tourne autour de la GPL fait peur (on craint, parfois à juste titre, la viralité) …Je pense que le nom a été gardé parce-que c'est dans la suite logique (et que c'est toujours AdaCore qui se porte garant de l'implémentation de référence)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: License
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
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…
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…
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.)
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/ :
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à
Perso, je trouve ça rassurant…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: License
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
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 Meku (site web personnel) . Évalué à 2.
Ah bon ? T'as eu cette info où ?
[^] # Re: License
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Bon, j'ai dû le rêver :D
La seule info que j'ai trouvée approchant est celle de Fabien sur Reddit.
[^] # Re: License
Posté par Meku (site web personnel) . Évalué à 2.
Merci pour le lien. Je vais jamais sur reddit, je ne savais pas qu'il y avait des discussions sur Ada dessus. Tu sais qui est ce Fabien ? Un employé d'AdaCore ?
[^] # Re: License
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Oui, bien sûr, il s'agit de Fabien Chouteau.
Il travaille chez Adacore et est très sympa :)
[^] # Re: License
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 20 novembre 2021 à 11:55.
[FSF Ada / GNAT GPL / GNATPro]
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 Blackknight (site web personnel, Mastodon) . Évalué à 3.
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 Blackknight (site web personnel, Mastodon) . Évalué à 3.
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 ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: License
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Certaines annexes sont toutefois normatives.
Aujourd'hui, il me semble que seule l'annexe Distributed Systems n'est pas implémentée dans Gnat mais bon, c'est PolyORB qui s'en charge en fournissant en plus un bus CORBA (cf. l'excellente présentation au FOSDEM 2019 :D)
# Site d'ada core
Posté par barmic 🦦 . Évalué à 4.
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).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Site d'ada core
Posté par jmiven . Évalué à 2. Dernière modification le 18 novembre 2021 à 14:21.
Comme souvent, on n'est pas vraiment le public ciblé par ce type de site (après tout, son rôle n'est pas de "promouvoir" le langage directement, mais d'abord l'entreprise). En tout cas, ils ont tout un tutoriel sur SPARK (et Ada…) ici :
https://learn.adacore.com/courses/intro-to-spark/index.html
[^] # Re: Site d'ada core
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 20 novembre 2021 à 10:28.
Bizarre, y a tout plein de liens en bas de cette page-là dont le Reference Manual et le manuel utilisateur.
Après, il y a quelques entrées de blog chez Adacore qui sont intéressantes.
Il y a, par complexité croissante :
# Se remettre dans la syntaxe cryptique
Posté par bux (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 18 novembre 2021 à 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 !
🦀🐍 http://github.com/buxx 🖥 https://algoo.fr 📋 https://tracim.fr
[^] # Re: Se remettre dans la syntaxe cryptique
Posté par Wendigo . Évalué à 2.
As-tu des ressources à conseiller à ce niveau justement ? Merci!
# Juste pour rappel ou info, c'est selon
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 10.
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 abriotde (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 22 novembre 2021 à 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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 22 novembre 2021 à 21:48.
C'est une question de point de vue :)
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.
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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
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
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 abriotde (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 23 novembre 2021 à 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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
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.
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.
Encore une fois, je veux bien une 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 abriotde (site web personnel, Mastodon) . Évalué à 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. 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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 7.
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.
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.
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 abriotde (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 23 novembre 2021 à 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.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 23 novembre 2021 à 10:06.
Pas vraiment l'avantage puisque le source compilé l'aura été avec les mêmes gardes-fours (pas de risque de débordement par exemple) et que Rust sera plus lent…
Lecture complémentaire : https://en.algorithmica.org/hpc/analyzing-performance/compilation/
“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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Les RTC ne sont pas ce que tu sembles penser (mais je peux me méprendre sur ta compréhension)
- https://stitcher.io/blog/we-dont-need-runtime-type-checks
- https://docs.microsoft.com/en-us/cpp/build/reference/rtc-run-time-error-checks?view=msvc-170
- https://blogs.sw.siemens.com/verificationhorizons/2021/06/28/runtime-checks-with-the-cast-method/
- https://sorbet.org/docs/runtime
“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 Dring . Évalué à 7.
Ca reste la cuisine interne du compilateur…
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Les gardes fours, c'est pour éviter les voleurs de pizza?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Oui, en l'occurrence de buffet et de steak en flot.
“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 barmic 🦦 . Évalué à 5.
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 :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Bof, il faut se préoccuper de la mémoire 42 plus que dans un langage à ramasse miette :-)
Gnii? VM != GC
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.
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par barmic 🦦 . Évalué à 4.
C'est pas linéaire. Rust et go1 réduisent pas mal de risque de programmation parallèle ce que ne fais pas du tout java. Python et Ada vont te prémunir des débordements d'entiers, mais pas java (ni rust il me semble).
je ne crois pas qu'on puisse avoir de la mémoire partagée en go c'est vraiment que du passage de message, il me semble. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par Lutin . Évalué à 3.
Les débordements d'entiers bouclent en rust (comme souvent en C et C++, sauf qu'en rust c'est un comportement défini).
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
En C11 aussi il s'agit d'un comportement défini, tant que l'on parle d'entiers non signés (cf. là).
Par contre, oui, pour les entiers signés, c'est un undefined behaviour.
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 10.
Par contre, ce que je n'avais pas vu, c'est la différence de comportement entre le mode debug et le mode release
Ca, je trouve ça piégeux.
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par Tarnyko (site web personnel) . Évalué à 6.
Ce que tu es censé faire est utiliser les méthodes dédiées safe des types élémentaires :
Cela dit je te l'accorde, j'ai du mal à justifier ce choix (sauf rétro-compatibilité avec un gros existant).
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par Dring . Évalué à 6.
Pourquoi pas une option du compilateur, avec un warning deprecated, pour avoir un truc un peu plus propre ?
Se retrouver avec un pansement comme ça sur un langage jeune, c'est moche.
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par Dring . Évalué à 5.
Ben j'aime pas ce que je lis là (https://github.com/rust-lang/rfcs/blob/master/text/0560-integer-overflow.md):
En gros, c'est pas très clair, et c'est laissé au choix du compilateur. Mais c'est "par défaut" uniquement en mode debug. J'espère que j'ai raté un truc, parce que c'est vraiment moche.
[^] # Re: Jamais Ada ne sera utiliser ailleurs que dans son domaine.
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Pour revenir à Ada, sur Gnat, le flag pour le contrôle du débordement des entiers était désactivé par défaut.
Heureusement cela a changé car pas mal de nouveaux venus pensaient que cela ne fonctionnait simplement pas.
L'ARM disant que le compilateur devait gérer prendre ce cas, Gnat a été mis à jour pour l'option -gnato soit active par défaut.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.