Journal Nouvelles de "Ada for Automation"

Posté par (page perso) . Licence CC by-sa
26
17
oct.
2014

Bonjour,

Je crois que les automaticiens ne sont pas légion sur linuxfr.org mais je ne désespère pas de les y amener comme je ne désespère pas de les amener à utiliser et créer du logiciel libre, en Ada qui plus est. We will rock you…

"Ada for Automation" (A4A en version courte) est un cadre applicatif, ou framework, pour la conception d’applications d’automatisme industriel dans le langage Ada. Il s’appuie sur la bibliothèque libmodbus pour permettre de réaliser un client ou un serveur Modbus TCP, ou encore un maître Modbus RTU. Il s’appuie également sur les cartes de communication de la société Hilscher permettant de s’interfacer sur les principaux bus de terrain du marché comme AS-Interface, CANopen, CC-Link, DeviceNet, PROFIBUS, EtherCAT, Ethernet/IP, Modbus TCP, PROFINET, Sercos III, POWERLINK, ou VARAN.

Il n'y a pas à proprement parler de gestion de version, seulement la "soup of the day". On télécharge la dernière depuis gitorious et l'on développe avec.

Cette soupe du jour a bien évolué depuis mon dernier article sur le sujet et je m'en vais en établir le menu :

Les applications exemples sont maintenant proposées avec une interface ligne de commande, comme avant, et avec une interface graphique grâce à GtkAda, le binding Ada de la librairie GTK. Et ça fonctionne sur Windows(R) XP et 7 64bits comme sous Linux avec GTK 2 ou GTK 3.

Le binding de la librairie libmodbus est aujourd'hui pour ainsi dire complet, toutes les fonctions de lecture et d'écriture de registres comme de booléens sont disponibles. Le client Modbus TCP ainsi que le serveur intègrent ces nouvelles fonctions.

Pour terminer avec libmodbus, un maître Modbus RTU est également disponible, ainsi qu'une application exemple associée, sur le modèle du client Modbus TCP.

Le plat de résistance est constitué par le binding de la librairie cifX, l'API qui permet l'utilisation des cartes de communication Hilscher sus-citées.

Quel que soit le protocole de communication industrielle utilisé, les échanges s’établissent soit de manière cyclique pour tout ce qui est données procédé – consignes, mesures, commandes et états -, soit de manière acyclique pour la configuration, le paramétrage et le diagnostic.

Aussi Hilscher a défini une interface sous la forme d'une mémoire double accès qui dispose d'une zone d’entrées et une zone de sorties pour les échanges cycliques, la mémoire image procédé, et des boites à lettres en émission / réception pour la gestion des messages acycliques. Auxquelles se rajoutent des zones pour l’identification du matériel et du logiciel, la commande et les diagnostics généraux.

L'API fournit les fonctions nécessaires à l'exploitation de ces informations et le binding Ada en permet l'utilisation dans ce langage.

Au-dessus de cette API, l'on a bâti une infrastructure qui s'occupe de l'initialisation du pilote, de l'identification du matériel et du logiciel, du rafraîchissement de la mémoire image procédé, de la gestion du chien de garde, des informations d'état de la communication.
Cette infrastructure comprend en outre un système pour la gestion de la messagerie avec des files ou queues de messages, les fonctions de routage ad hoc et des blocs fonctions pour le programme utilisateur.

Comme il faut pouvoir configurer ces cartes, on a également intégré les fonctions permettant l'accès et le diagnostic distant, via TCP/IP.

Comme attendu, une application exemple mettant en œuvre l'ensemble est disponible et elle tourne indifféremment sur les OS déjà cités, et ce sans modifier une ligne de code, merci Ada.

Et ça tourne rond sur Linux avec le noyau PREMPT_RT qui donne à la solution un comportement temps réel convenant sans doute à 95% des applications d'automatisme.

Voilà, voilà… A la prochaine !

Cordialement,
Stéphane

  • # Liens

    Posté par (page perso) . Évalué à 3.

    • [^] # Re: Liens

      Posté par (page perso) . Évalué à 1.

      Bonjour martoni,

      Merci pour les liens. Je n'osais pas de crainte d'être lapidé…

      "Ouaich… Il vient faire sa pub sur LinuxFr !!!!" "C'est pour attirer le chaland !"

      Ce qui n'est pas complètement faux.

      Et puis une recherche sur un moteur bien connu en donne à la pelle. C'est il me semble la cause de la mort des annuaires de liens.

      Alors en faut-il ?

      Cordialement,
      Stéphane

  • # Ca tombe à point pour moi

    Posté par . Évalué à 3.

    1/ Je suis actuellement en train de me (re)familiariser avec Ada : je suis également convaincu du potentiel de ce langage, notamment pour l'écriture des couches médium des OS ou des outils sensibles tels que serveurs web, ou libs de sécurit/chiffrage. Par contre je ne vois pas trop si ce serait simple.

    2/ J'ai fait quelques recherches sur les bus de terrrain il y a relativement peu de temps (modbus, par exemple), et j'ai remarqué qu'en dehors de matériel professionnel (automates qui coutent une fortune), il n'y a pas grand chose qui exploite ces bus (j'ai regardé sur ebay, on trouve des automates Télémécanique, mais je n'ai pas trop envie d'investir dedans).

    Sinon, pour en revenir à Ada, je suis toujours en apprentissage. Le problème c'est qu'on trouve trop peu de docs sur ce langage (mis à part des bouquins en anglais qui ne sont pas donnés et qui ne sont pas forcément à jour).

    • [^] # Re: Ca tombe à point pour moi

      Posté par (page perso) . Évalué à 3.

      Le problème c'est qu'on trouve trop peu de docs sur ce langage

      Rhoooo ! Allez, je fais comme d'habitude, je vais donner des liens :
      - Ada distilled qui ne traite pas de l'Ada 2012 bien qu'il y en ai un peu dedans
      - Le wikibook
      - Adacore University
      - Les normes qui, une fois que l'on a compris la syntaxe, permettent de répondre aux questions que l'on peut être amenés à se poser au fil de l'eau
      - Un tuto en Ada95 à l'ENST qui est toujours d'actualité puisque le langage n'a pas subi de grands changements syntaxiques
      - Les cours de Daniel Feneuille donnés à l'IUT d'Aix

      Enfin, en source d'information, rien ne vaut les newsgroups français fr.comp.lang.ada et anglais comp.lang.ada où les responsables de la norme et les pros prendront toujours le temps de te répondre.

      • [^] # Re: Ca tombe à point pour moi

        Posté par . Évalué à 2.

        Merci pour les liens. En fait je me suis mal exprimé : j'ai cherché des docs mais je n'en ai pas trové de potables mis à part 2 bouquins en anglais. j'aurais plutôt du dire que je ne trouve pas vraiment ce que je cherche.

        Le courrs de Daniel Feneuille : je n'aime clairement pas le style. Il est trop orienté cursus scolaire : hors du contexte du cours, il y a plein de choses qui sont floues, et certains aspects du langage ne sont pas approfondis, sans parler du style d'écriture que je trouve inadapté à ce genre de document.

        Adacore University : je ne connaissais pas : je vais aller voir.

        Wikibook : je l'ai vu, enfin apperçu : il m'a été utile comme référence mais pas vraiment pour apprendre.

        En fait ce que je cherche, c'est surtout de la doc sur la programmation système en ADA, commme on trouve des docs de programmation système en C.

    • [^] # Re: Ca tombe à point pour moi

      Posté par (page perso) . Évalué à 2.

      Bonjour totof2000,

      1 - Je me suis lancé dans ce projet dans l'intention justement de me former à Ada que je trouvais alors, et encore davantage aujourd'hui, passionnant.

      2 - Oui, les bus de terrain sont plutôt utilisés chez les industriels. Le matériel coûte cher mais il dure longtemps dans des conditions souvent difficiles. Ce n'est pas vraiment grand public.

      Et il faut également compter l'atelier de développement logiciel qui n'est pas donné en général.

      Si tu veux du Modbus, TCP ou RTU, "Ada for Automation" en fournit grâce à libmodbus et il ne te reste à investir que dans les modules d'E/S ou équipements nécessaires à la conduite de ton procédé.

      L'atelier est fourni par AdaCore, en version libre ou supportée, et il n'y a pas de licence de run time.

      Cordialement,
      Stéphane

  • # ça va être dur

    Posté par . Évalué à 5.

    Les automaticiens ont beaucoup de mal avec la nouveauté et sont embourbés avec omniprésence de Codesys.
    Il propose tout les langages de l'IEC 61131-3 avec en particulier le Texte Structuré et le Ladder et il est souvent refourgué avec les automates de façon plus ou moins maquillé.

    Le Texte Structuré est proche de la syntaxe Pascale et permet de faire des boucles et des tests de façon trivial. Les automaticiens ne l'utilisent pas, et à la limite, le fuit.

    Le Ladder est quand à lui un langage graphique prévu pour faire des programme à la manière d'un schéma électrique. Pour les boucles et les tests, bah, il y a le goto. C'est ce langage que les automaticiens veulent, parce que texto "c'est ça que j'ai appris à l'école." (ça fait 15 ans qu'il est sorti de l'école et ça marche aussi avec les stagiaires)

    Donc un outil de développement pour automate sans ladder semble éviter la cible automaticien.

    Un automaticien utilise un automate. Il ne lui viendra pas à l'esprit d'utiliser une autre plateforme pour voire autre chose, surtout si il n'y a pas de ladder.

    • [^] # Re: ça va être dur

      Posté par . Évalué à 2.

      ça me rappelle les TP d'électronique au lycée. Il y avait les gentils microcontroleurs avec du gentil langage C, et les vieux automates tout moisis que l'on programmait avec du ladder et des graphcets tout pourris sur des ordinateurs Goupil avec leur lecteur de disquette 5'1/4. (en 2003-2004, je précise!).
      je ne comprenais pas bien pourquoi il fallait se taper un langage de merde. si encore on peut appeler ça un langage.

      maintenant je comprends mieux grâce à toi.

      oui je suis aigri car en TPE j'ai eu à utiliser un automate, alors que d'autres ont fait du microcontroleur…

    • [^] # Re: ça va être dur

      Posté par (page perso) . Évalué à 2.

      Bonjour pif17,

      CoDeSys est effectivement embarqué dans nombre d'équipements. Chez Hilscher aussi il est intégré dans ce que l'on nomme des contrôleurs programmables car nous ne fournissons pas de rack ou de modules d'E/S. Tous les capteurs et actionneurs sont raccordés directement sur le bus de terrain ou des stations d'E/S déportées.

      S'il est très répandu il n'est pas le seul, Hilscher intègre également ProConOs de KW Software, l'automate compatible S7 de IBH Softec et chez Hilscher France nous avons intégré ISaGRAF, aujourd'hui dans le giron de Rockwell.

      Nous avons aussi développé un pilote pour nos cartes pour une utilisation avec WinAC de Siemens.

      Toutes ces solutions se déclinent depuis la plateforme embarquée, de l'enfouis à l'automate traditionnel, jusqu'aux PC industriels.

      Quant aux langages utilisés, cela dépend beaucoup de la région du globe, du domaine et des moyens accordés à l'automaticien.
      Pas le temps, pas formé, pas les outils, on fait avec les moyens du bord.

      Certes le ladder est sans doute très utilisé, ça tient à la formation de base de l'automaticien.
      C'est incontournable aux US quand en Allemagne c'est plutôt le list (IL).
      Dans le process, c'est du diagramme de blocs…

      Pour ma part, j'ai souvent été contraint d'utiliser tel ou tel langage qui ne me semblait pas adapté à la situation.

      Développer en Ada me plaît davantage car ça ouvre le domaine des possibles mais je comprends que d'autres préfèrent le langage auquel ils sont habitués.
      Et puis il y a les clients, les gens de la maintenance…

      Les automaticiens sont divers, je pense que "Ada for Automation" peut en intéresser quelques uns.
      Si ce n'est pas pour une mise en œuvre dans un projet industriel, ce peut être pour se former à la programmation structurée, la programmation objet, la programmation concurrente… et l'on pourra réutiliser ce que l'on aura appris dans les ateliers IEC 61131-3.

      Cordialement,
      Stéphane

      • [^] # Re: ça va être dur

        Posté par . Évalué à 1.

        Bonsoir Stéphane.

        Mon commentaire a peut être paru un peu sec. Je souhaite corriger un peu le tire et peut être éclairer un peu plus nos lecteur peu habitué à l'IEC 61131-3.

        En gros, l'IEC 61131-3 définie 5 langages. Il y a les types textuel:
        - Le ST (Structured Text) qui ressemble fortement au Pascal.
        - Le IL (Instruction List), lui, c'est plutôt de l'assembleur.
        Et les graphique:
        - le Ladder, des schéma éléctrique.
        - le Sequential function chart (SFC), Grafcet (enchaînement d'action et de condition).
        - le Function block diagram (FBD), diagramme électronique en gros.
        Il y a aussi une bibliothèque standard.
        Pour les plus curieux il y a ce lien.
        Et les plus acharné, il existe un runtime de codesys pour raspberry PI. (codesys c'est un peu tout, un IDE et un runtime. Le runtime tourne au dessus d'un OS et prend des binaires, peut importe le(s) langage(s) d'origine du programme)

        Les automaticiens ont donc plusieurs langage à leur disposition pour exprimer au mieux leurs besoins. Pour moi, le problème, c'est qu'ils ne savent pas choisir le bon langage pour un besoin donné, pour des raisons culturel, d'enseignement et d’habitude, plus rarement par des impératifs client.

        Il y a un autre souci, c'est l'abstraction. Je n'ai pas encore vu d'automaticien capable cloisonné son code efficacement. Si il y a 15 vérins à piloter avec 30 capteurs, (2 capteurs pour piloter 1 vérin), un automaticien aura la fâcheuse tendance à faire 15 copier-coller en changeant les nom de variable au lieu de faire une fonction ou un bloc fonctionnel (sorte d'objet).
        Peut importe le langage, quand c'est une technique de réflexion qui manque.

        Ada a sûrement d’excellentes qualités, mais j'ai du mal a voire ce qu'il peut apporter, pour un automaticien. Des bibliothèques plus nombreuse peut-être.

        Je reconnais A4A est causant. Il manipule de nombreux protocoles de communication, dont ceux que je pense indispensable. D’ailleurs, pour PowerLink et EtherCat, un contrôleur Ethernet quelconque suffit pour avoir un maître ou il faut impérativement du matos Hilscher? A4A permet-il aussi de programmer des esclaves sur ces protocoles?

        Cordialement.
        Sébastien

        • [^] # Re: ça va être dur

          Posté par (page perso) . Évalué à 2.

          Bonjour Sébastien,

          Les automaticiens ont donc plusieurs langage à leur disposition pour exprimer au mieux leurs besoins. Pour moi, le problème, c'est qu'ils ne savent pas choisir le bon langage pour un besoin donné, pour des raisons culturel, d'enseignement et d’habitude, plus rarement par des impératifs client.

          Oui, enfin, quand on voit les parts de marché de SCHNEIDER et SIEMENS en France…

          Chez Siemens, il y a de base le CNT, LOG, LIST, le ladder donc, le logigramme (j'ignore si quelqu'un programme dans ce langage, je sais qu'ils sont équivalents, on passe de l'un à l'autre sans modifier le code, et le liste d'instructions IL.

          Pour le Grafcet, il y a S7-GRAPH, ça fait peur.

          Pour le ST, il faut acheter SCL, et il faut de bons arguments pour l'imposer. Comme peu d'automaticiens peuvent se former peu l'imposent.

          Pour le schéma blocs, il faut acheter CFC. Quand j'ai dit que c'était pas mal on m'a dit que je faisais de la programmation de luxe. C'est sans doute un peu cher, mais c'est vraiment pas mal. Il faut aussi la CPU qui va bien parce que c'est un peu gourmand.

          Donc, chez Siemens, les cinq langages tu ne les a que si tu es riche et puissant.

          Chez SCHNEIDER, tu disposes du Ladder donc, du ST, du IL ?, du Grafcet si tu as une CPU décente, et du IL.
          Cependant, tu ne peux pas écrire une fonction, il faut acheter le kit de développement. Comment est-ce possible une chose pareille ?
          Par contre tu peux écrire tes blocs fonctions, une sorte d'objet avec des données d'instance mais une seule méthode que tu appelles généralement cycliquement.

          Donc, d'une part le choix est souvent restreint par l'atelier dont l'automaticien dispose, d'autre part cela tient à sa formation de base, électricité, mécanique, mesure et régulation, maintenance… Mais j'ai pu le constater souvent, c'est aussi une imposition client en général par l'historique de la société, on fait comme ça chez nous et on ne va pas former sur un autre langage nos équipes.

          Il y a un autre souci, c'est l'abstraction. Je n'ai pas encore vu d'automaticien capable cloisonné son code efficacement. Si il y a 15 vérins à piloter avec 30 capteurs, (2 capteurs pour piloter 1 vérin), un automaticien aura la fâcheuse tendance à faire 15 copier-coller en changeant les nom de variable au lieu de faire une fonction ou un bloc fonctionnel (sorte d'objet).
          Peut importe le langage, quand c'est une technique de réflexion qui manque.

          Ben oui, c'est l'apport du génie logiciel, la programmation structurée puis orientée objet et les méthodes permettant l'analyse selon ces modèles. Mais c'est enseigné dans la filière informatique et pas dans les filières sus-citées. On considère encore de nos jours que l'automation n'est pas de l'informatique alors que, hormis la nature des informations traitées, les technologies sont les mêmes et que l'on peut très bien utiliser les méthodes qui ont fait leurs preuves en informatique.

          J'ai connu des automaticiens qui ne savaient pas écrire une fonction et encore moins un bloc fonction.
          J'ai connu des clients qui m'imposaient de ne pas en utiliser car c'était plus difficile à déboguer.
          Ça vient des raisons déjà évoquées et c'est certainement vrai. Si l'interface de ta fonction ou de ton bloc fonction est mal gaulée, tu vas te retrouver à corriger toutes les instances et tu ne pourras pas le faire en ligne.

          Ada a sûrement d’excellentes qualités, mais j'ai du mal a voire ce qu'il peut apporter, pour un automaticien. Des bibliothèques plus nombreuse peut-être.

          Pour un automaticien qui est satisfait de ses matériels, outils et méthodes, je ne sais pas.
          Peut-être le coût de la solution ? L'ouverture ?

          Les bibliothèques disponibles en Ada permettent de faire une interface graphique, une connexion à une base de données, une interface web… ça offre des possibilités d'intégration fantastiques avec cependant la nécessité de monter en compétence.

          Et si l'on reste dans le basique, "Ada for Automation" permet de se former à toutes les techniques et tous les paradigmes du génie logiciel avec à la clef une bien meilleure maîtrise des outils usuels.

          Je reconnais A4A est causant. Il manipule de nombreux protocoles de communication, dont ceux que je pense indispensable.

          Yes, c'est un des points forts du projet. En permettant l'utilisation des cartes de communication Hilscher, et ce sans restriction, "Ada for Automation" bénéficie à plein de l'ouverture qu'offrent ces cartes tant du point de vue des technologies de bus supportées - tous les standards du marché, que des formats disponibles, des pilotes, dont celui pour Linux qui fonctionne également avec le noyau temps réel (PREMPT_RT).

          D’ailleurs, pour PowerLink et EtherCat, un contrôleur Ethernet quelconque suffit pour avoir un maître ou il faut impérativement du matos Hilscher?

          Il faut dissocier les cas POWERLINK et EtherCAT.

          Pour POWERLINK il y a une pile de protocole libre, openPOWERLINK, qui tourne d'ailleurs nativement sous Linux et qui ne nécessite qu'une carte Ethernet standard. C'est utilisable sans restriction et quelqu'un pourrait se dévouer pour en faire un binding Ada pour une utilisation avec "Ada for Automation". openPOWERLINK permet de faire un nœud esclave (Controlled Node - CN) ou maître (Managing Node - MN). Hilscher fournit un esclave mais pas de maître pour l'instant.

          Le cas EtherCAT est plus litigieux. Il y a eu une implémentation maître open source mais elle a été retirée à cause des brevets et de la licence nécessaire. Pour les esclaves il est nécessaire d'utiliser des chips dédiés et la licence est payée en achetant le chip.

          A4A permet-il aussi de programmer des esclaves sur ces protocoles?
          Oui, avec les cartes, les modules ou les "Systems on Chip" Hilscher donc.

          Bon week-end !

          Cordialement,
          Stéphane

    • [^] # Re: ça va être dur

      Posté par . Évalué à 1. Dernière modification le 25/10/14 à 21:31.

      La généralisation est quand même bien facile …

      C'est sans doute vrai pour la plupart des automaticiens mais pas pour tous ! Et je pense faire parti de ceux là …
      J'ai récemment sauvé un de nos projet en utilisant un iPC et développant une appli en python + openOPC donc l'affirmation « Un automaticien utilise un automate. Il ne lui viendra pas à l'esprit d'utiliser une autre plateforme pour voire autre chose, surtout si il n'y a pas de ladder. » est totalement fausse.

      D'ailleurs, quand je developpe une application sur un automate, c'est assez rare que j'utilise un seul langage. Sur la dernière en date, j'en utilise 3 : SFC, LD et ST. Simplement parce que je trouve que chaque langage est plus approprié dans certains cas.

      Après, je suis assez jeune et autodidacte. Je pense que tes affirmations visent surtout les automaticiens qui sont en fin de carrière mais d'un autre coté, ils ont leurs petites habitudes donc ça peut se comprendre …

      En tout cas, l'article attire ma curiosité et je pense que je m'intéresserais à Ada à l'avenir bien qu'à force ça commence à faire quelques langages à maitriser …

      Par contre, puisqu'on est dans l'automatisme et donc dans l'industrie, il faut aussi voir le coût de ces solutions.

      • [^] # Re: ça va être dur

        Posté par (page perso) . Évalué à 2.

        La généralisation est quand même bien facile …

        oh bah oui, mais à force de rencontrer ce type de profil ;-)

        bien qu'à force ça commence à faire quelques langages à maitriser …

        vala…

        là où Ada pourrait bien fonctionner pour l'autom' (j'ai eu un projet en école sur ce sujet au siècle dernier).

        j'en utilise 3 : SFC, LD et ST.

        pour quelqu'un n'étant pas du milieu, c'est quoi ? quels sont les avantages de chacun ? c'est en libre ?

  • # Ah Ada

    Posté par . Évalué à 1.

    L'unique langage appris pendant mes etudes. Compare aux langages "mainstream", clairement manque de docs, de libs … dommage car le langage en lui meme est bon (bien qu'assez verbeux), avec de la vrai genericite (si mes souvenirs sont bons :-)) une vraie separation fonction/procedure (ca me plaisait a l'epoque…) …

    • [^] # Re: Ah Ada

      Posté par (page perso) . Évalué à 2. Dernière modification le 17/10/14 à 22:37.

      L'unique langage appris pendant mes études.

      sérieux ?

      Ada permet d'appeler facilement de l'assembleur ou du C pourtant, c'est dommage de s'en être privé :/ Cela reste un bien meilleur langage que Pascal, félicitations si tu as réussi à dépasser les 2-3 premiers jours.

      clairement manque de docs, de libs …

      en 93 peut-être et encore, pas en 2014 (cf. plus haut)

      Malencontreusement, il n'est que peu utilisé, hormis chez Dassault et dans le militaire :/

      • [^] # Re: Ah Ada

        Posté par . Évalué à 1.

        sérieux

        Et si :-) mon prof de l époque était freelance dans le domaine de l'aéronautique et défense, d'ou l'Ada :-) quand j'osais évoquer le C et cie il me faisait les gros yeux :-D

        j imagine bien que maintenant c'est mieux qu'avant mais toujours loin derriere les autres (malheureusement … il mériterait un peu plus de visibilite).

        • [^] # Re: Ah Ada

          Posté par (page perso) . Évalué à 2.

          mon prof de l'époque

          avant 1993 ?

          bon moi j'avais appris le basic, l'assembleur 6502 puis le C par moi-même (à l'époque il y avait de la doc'). Pour le Pascal, je l'ai subi (je préférais largement convertir l'algo ressorti du Pascal pour l'utiliser en C que d'écrire du Pascal… ça tombe bien en 2è A ils nous ont redemandé les mêmes exos qu'en 1è A, en C au lieu de Pascal : je les avais déjà fait !).

          L'Ada passé la 1ère demi-journée pour coder un hello world et mettre les ; au bon endroit et trouver les bon include^use^with ça allait… En plus, c'est cohérent et bien plus puissant que du pascal. J'imagine qu'Ada ne perce que peu du fait de sa finalité… Effectivement, dans un domaine connexe comme l'autom' il est très bien et correspond à la logique de boucle de rétro-action, permet de faire l'interaction avec le matériel…

          • [^] # Re: Ah Ada

            Posté par . Évalué à 3.

            C'est vrai qu'avec Ada tu te bats avec le compilateur … mais il a été conçu je crois à la base
            dans un but d'uniformisation et de maintenabilité.
            D'ailleurs si je me souviens bien essayes un truc du style (ce n'est pas de l'Ada)
            A est un entier sur 1 octet

            switch(A)
            case 1 :
            case 2 :
            case 3 :
            end

            comme A peut prendre 256 valeurs le compilateur va couiner parce que tu ne gères pas les cas de 4 à 255 :)
            De plus le compilateur à une option par défaut pour ignorer les insultes des dev :)

            • [^] # Re: Ah Ada

              Posté par . Évalué à 0.

              Je crois que Haskell et Rust aussi (à vérifier). Il me semble que Ada ne possède ni GC ni borrow checker par contre :-/

              Envoyé depuis ma Debian avec Firefox

              • [^] # Re: Ah Ada

                Posté par (page perso) . Évalué à 1.

                Il me semble que Ada ne possède ni GC ni borrow checker

                Certes mais vu qu'on n'utilise pas forcément beaucoup les pointeurs et que quand on les utilise, c'est très contrôlé par le compilateur, c'est pas aussi grave que ça.
                Après, on peut faire deux ou trois trucs si vraiment on veut se faciliter la vie.
                Perso, j'en ai pas encore eu besoin :D

Suivre le flux des commentaires

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