Journal Ada, langage et ressources

Posté par (page perso) . Licence CC by-sa
Tags :
36
24
juin
2013

Récemment j'ai commencé à regarder un peu le langage Ada. C'est un langage que je trouve vraiment intéressant, à plusieurs titres.

Bon, un point négatif pour commencer : la syntaxe. C'est vrai que j'ai plus été habitué aux syntaxes type c, c++, c#, java, javascript que pascal ou basic par exemple, même si je fais du ruby. Au premier abord on peut trouver la syntaxe un peu lourde, le respect des majuscules, etc. Mais utiliser le mod ada pour emacs vous aidera mine de rien, entre autre en gérant tout seul comme un grand les majuscules des variables ! Et ça c'est juste génial !

Ensuite, le principe même du langage, son système de type essentiellement, est vraiment intéressant. Je ne vais pas vous le détailler, il y a pas mal de ressources sur le sujet (et c'est aussi une question au travers de ce billet) mais juste prendre un exemple.

Lorsque vous voulez travailler avec des heures dans un langage quelconque, vous allez utiliser en général un entier. Ok, ça marche, pourquoi pas. Le problème initial est qu'il est possible de mélanger des choux et des carottes. Par exemple, vous pouvez affecter la variable heure avec une valeur d'incrément d'une boucle. Ben oui, pourquoi pas puisque c'est un entier aussi ? (oui ce n'est pas souhaitable, mais les bugs existent souvent parce que des choses non souhaitables arrivent)

Bon, on peut faire mieux, en déclarant une nouvelle classe heure par exemple. Cette classe va stocker la valeur dans un entier et ça va quand même améliorer les choses puisqu'on ne pourra plus faire monheure = i; aussi facilement. Mais ça ne suffit pas. Comment gérer la plage de valeurs ? Il va falloir rajouter de tests un peu partout pour gérer les cas, les limites, l'égalité, etc.

Au final vous risquez de vous retrouver avec quelque chose du genre (oui c'est grossier, et en plus vous perdez, en java, les opérateurs + et -) :

public class Hour {
    private Integer value = 0;

    public Integer getInt() {
        return value;
    }

    public void fromInt(Integer hour) {
        value = hour % 24;
    }

    public void incr() {
        fromInt(value + 1);
    }

    public void decr() {
        fromInt(value - 1);
    }

    // [...]
}

Supaïr, non ?

Ha oui, pourquoi faire ça ? Ben juste pour écrire des logiciels un peu plus sûr, avec moins de possibilité de bugs, d'effets de bords, etc. Vous croyez pas que ce serait un peu mieux non ?

Bon ok, mais comment qu'on fait en Ada alors ?

Ben c'est plutôt facile :

type Hour is mod 24;

Alors, elle est pas belle la vie ?

De la même manière, on peut facilement faire des intervalles genre

type Day_Of_Year is range 1..366;

Bon tout ça pour dire que Ada m'intéresse de plus en plus. Il est peut-être moins fun que certains langages, mais je pense que la satisfaction de bien faire les choses l'emportera sans aucun doute ! Finalement ça donne un peu l'impression que Ada demande à ce qu'on réfléchisse avant de coder, alors que de plus en plus dans les autres langages on voit beaucoup de monde coder puis réfléchir lorsque cela ne fonctionne pas. Mais surtout, ces systèmes sont intégrés aux langage et ne nécessitent pas de lib externe supplémentaire (comme par exemple pour faire de la programmation par contrat).

Maintenant, à vous de travailler un peu : connaissez-vous, avez-vous des ressources intéressantes concernant Ada ?

Voici ce que j'ai pour le moment :

En avez-vous d'autres ? Ou des livres par exemple ?

  • # langage fonctionnel

    Posté par . Évalué à 8.

    Le système de type paramétrique de Ada semble pas mal, mais essaye un langage qui a du filtrage de type, c'est tellement simple à lire, que l'on se demande pourquoi les autres langages n'ont pas l'équivalent.

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

    • [^] # Re: langage fonctionnel

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

      Tu aurais juste un exemple histoire de voir vraiment ce que tu veux dire ?

      • [^] # Re: langage fonctionnel

        Posté par . Évalué à 4. Dernière modification le 24/06/13 à 16:53.

        L'exemple typique définit un arbre, il faut en gros que ta donné soit un poil complexe. Le genre de truc qui te prend un paquet de fichier en java, mais 10 lignes en ocaml. Par exemple, un moyen d'exprimer un paquet de donné binaire :

        type val_t =
          | I32 of Int64.t 
          | U32 of Int64.t 
          | I16 of int 
          | U16 of int 
          | U8 of int
          | Comment 
          | Padding of int 
        
         let get_size val =
           match val with
            | I32 _ -> 4
            | U32 _ -> 4
            | I16 _ -> 2
            | U16 _ -> 2
            | U8 _ -> 1
            | Comment -> 0
            | Padding i -> i
        
         let is_correct val = 
          match val with
            | I32(i) -> (Int64.compare (-2147483648L) i) <= 0) && ((Int64.compare i 2147483647L) <= 0
            | U32(u) -> (Int64.compare 0L u) <= 0) && ((Int64.compare u 4294967295L) <= 0
            | I16(i) -> (-32768 <= i) && (i <= 32767)     
            | U16(u) -> (0 <= u) && (u <= 65535)
            | U8(u) ->  (0 <= u) && (u <=255)
            | Padding(i) -> 0 <= i
        
        

        type mon_gros_tableau_binaire = (val_t * string) list; (*ici la string est un commentaire pour savoir d'ou vient la donné en question*)

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

        • [^] # Re: langage fonctionnel

          Posté par (page perso) . Évalué à 3. Dernière modification le 24/06/13 à 17:05.

          Bon, je ne connais pas vraiment l'ocaml (en fait pas ;-) alors peut-être que j'ai tout faux dans la suite !

          Je ne comprend pas bien en quoi c'est mieux.

          Si j'écris :

          type I is Integer;
          type N is Natural;
          type U16 is 0..65535:
          type U8 is 0..255;
          type Val is
             record
                My_Integer is I;
                My_Natural is N;
                My_U_16 is U16
                My_U_8 is U8;
                My_Padding is Natural;
             end record;
          

          Sachant que dans ce cas on ne peut pas affecter la valeur d'un Integer ni d'un Natural par exemple à My_Integer qui lui est de type I.
          Et côté lisibilité c'est quand même plutôt bien, non ?

          Après, comme indiqué, peut-être que je n'ai pas tout compris ;-)

          • [^] # Re: langage fonctionnel

            Posté par . Évalué à 2.

            Si un record est une structure, cela n'a en effet aucun rapport :)

            Les type sommes, sont une sorte d'union de type, avec un enum pour faire la différence, sauf que c'est typé (un switch ne peut pas être incomplet).

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

          • [^] # Re: langage fonctionnel

            Posté par (page perso) . Évalué à 1. Dernière modification le 24/06/13 à 17:34.

            En fait, dans son exemple c'est pas un record, mais une variante et ça sert à remplacer les switch...case mais en plus puissant.

            Edit : grillé, Nicolas m'a devancé, c'est la deuxième fois en peu de temps que ça m'arrive :)

            • [^] # Re: langage fonctionnel

              Posté par . Évalué à 3.

              C'est plus puissant, car le filtrage peut être emboité si nécessaire, et que "sa complétude" est vérifié (pas d'oublie possible, c'est génial en cas de modif).

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

              • [^] # Re: langage fonctionnel

                Posté par . Évalué à 3.

                Il me semble que la complétude est vérifié aussi en Ada: "In Ada, one advantage of the case statement is that the compiler will check the coverage of the choices, that is, all the values of the subtype of variable X must be present or a default branch when others must specify what to do in the remaining cases."

                Donc je pense que tu as répondu un peu vite..

                • [^] # Re: langage fonctionnel

                  Posté par . Évalué à 4.

                  il gère aussi l'emboitement ?

                  Genre

                  type t = Plop of integer | Plip of string

                  type t2 = Foo of t1 | Foo2 of (t*t)

                  let foo t2 =
                  match t2 with
                  | Foo (Plop i ) -> ..
                  | Foo (Plip s) ->…
                  | Foo2 (_, tt) -> toto (tt)

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

                  • [^] # Re: langage fonctionnel

                    Posté par . Évalué à 2.

                    Non, maintenant si c'est probablement un confort intéressant (jamais utilisé un langage qui a ça donc je ne peux pas parler en connaissance de cause), avoir le compilateur qui vérifie que je couvre bien tout les cas possible me parait beaucoup plus important pour faire évoluer un programme.

        • [^] # Re: langage fonctionnel

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

          Ce qui est génial aussi, c'est que si dans ta fonction get_size t'avais oublié un des cas possibles, le compilateur te le dis. C'est particulièrement utile quand tu t'aperçois que tu veux rajouter un type dans val_t, puis après tu laisses le compilateur te dire toutes les fonctions dans plusieurs fichiers où t'as oublié de rajouter une règle de filtrage pour ce type.

    • [^] # Re: langage fonctionnel

      Posté par (page perso) . Évalué à 6. Dernière modification le 24/06/13 à 16:37.

      Juste une question stupide, qu'appelles-tu « filtrage de type » ? Tu parles du filtrage par motif ( pattern matching ) ou bien est-ce autre chose ?

      • [^] # Re: langage fonctionnel

        Posté par . Évalué à 3.

        Je parle du truc de ocaml, dont chaque branche est plus ou moins définit par un constructeur qui permet de déconstruire la donnée et récupérer ce qu'il y a dedans de façon typé.

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

        • [^] # Re: langage fonctionnel

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

          Ok. Donc c'est bien ce qu'on appelle pattern matching (ou filtrage par motif pour ceux qui sont allergique au franglais). Et effectivement c'est génial !

        • [^] # Re: langage fonctionnel

          Posté par . Évalué à 1.

          Est-ce ce qu'on appelle "extractor" en Scala?
          Voici par exemple, comment construire un objet de type "pair" à partir d'un entier:

          object Twice {                              
            def apply(x: Int): Int = x * 2
            def unapply(z: Int): Option[Int] = if (z%2 == 0) Some(z/2) else None
          }
          
          
          • [^] # Re: langage fonctionnel

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

            Pas tout à fait, en OCaml, il n'y a pas d'extracteurs autres que ceux prévus par le langage. Si l'on veut comparer avec Scala, il faudrait comparer avec les case classes qui rajoutent un peu de lourdeur dans leur utilisation (on peut pas tout avoir…)

            • [^] # Re: langage fonctionnel

              Posté par . Évalué à 1.

              Je répondais à ceci:

              Je parle du truc de ocaml, dont chaque branche est plus ou moins définit par un constructeur qui permet de déconstruire la donnée et récupérer ce qu'il y a dedans de façon typé.

              …ce qui m'a l'air de correspondre aux extracteurs. Les "case classes" en Scala sont essentiellement pour le "pattern matching" (par exemple pouvoir mettre des objets dans les cas d'un "switch") ce qui est différent, malgré ce qui est dit plus haut.

              • [^] # Re: langage fonctionnel

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

                J'avais compris, et je répète qu'il n'y a pas d'extracteurs en OCaml, le seul moyen de déconstruire un type passe par le pattern matching.

                Maintenant, le pattern matching peut être présent dans un switch (l'usage le plus courant) comme présenté dans le commentaire ci-dessus , mais aussi lors du passage d'argument d'une fonction (moins courant), dont voici un exemple :

                # let hd_tl (hd::tl) = (hd, tl);;
                Warning 8: this pattern-matching is not exhaustive.
                Here is an example of a value that is not matched:
                []
                val hd_tl : 'a list -> 'a * 'a list = <fun>
                

                Mais cela reste encore limité aux motif d'extractions gérés en interne dans le langage, et il n'est pas possible d'en rajouter de nouveaux.

                • [^] # Re: langage fonctionnel

                  Posté par . Évalué à 2.

                  En général ce mécanisme s’appelle les view patterns et existe dans un grand nombre de langage fonctionnels par exemple en Haskell ou en F# (active patterns), vu que le concept a été introduit il y a quand même longtemps (en 1987 !). Le problème de OCaml est qu’une partie de ce qui aurait pu atterrir dans le langage a été relégué dans les outils, dans ce cas dans camlp4.

    • [^] # Re: langage fonctionnel

      Posté par . Évalué à 2. Dernière modification le 24/06/13 à 20:57.

      Le système de pattern matching de OCaml/Haskell/Scala/F# semble pas mal, mais essaye un langage qui a des types dépendants (ou des types homotopes !), c’est tellement simple à vérifier, que l’on se demande pourquoi les autres langages n’ont pas l’équivalent.

      • [^] # Re: langage fonctionnel

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

        As tu des exemples de langages ? Je ne me représente pas trop comment implémenter ça…

      • [^] # Re: langage fonctionnel

        Posté par . Évalué à 3.

        tu as un exemple ? :)

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

        • [^] # Re: langage fonctionnel

          Posté par . Évalué à 8. Dernière modification le 24/06/13 à 22:39.

          C’était principalement de l’humour pour dire qu’il y a toujours des systèmes de type plus puissant, c’est à dire permettant de détailler encore plus finement ce que fait un élément d’un programme (une fonction par exemple). L’exemple de l’OP avec un alias de type pour les heures par exemple, permet de définir des fonctions typées comme :

          -- Date de Pâques pour une année donnée
          easter : Int -> Day_of_year
          
          

          et le compilateur va se charger de vérifier qu’on ne retourne pas une erreur (un entier négatif, ou supérieur à 366).

          En Haskell et OCaml, par exemple, il y a tout un tas d’autres apports du système de type. Par exemple, avec les GADTs, on peut vérifier à la compilation que tous les arbres binaires que l’on va construire sont bien balancés, ou qu’une liste passée en paramètre est toujours non-vide. Ça permet d’avoir une sorte de pattern matching mais à la compilation plutôt qu’à l’exécution. On peut aussi utiliser le système de type pour faire des calculs à la compilation (un peu comme le template meta-programming en C++, mais de façon propre :p).

          Les GADTs viennent des systèmes de types dépendants, dans lesquels on peut par exemple typer le fait qu’un programme prenne en entrée une liste de n éléments, et sorte une liste de (n+1) éléments :

          -- Ajoute un élément à une liste de taille n contenant des a
          addElem : List n a -> L (n+1) a
          
          

          Et c’est le système de types du compilateur qui va se charger de vérifier ça à la compilation (en fait écrire un programme bien typé est la même chose qu’écrire une preuve, que le compilateur va vérifier). Les types dépendants sont classiquement utilisés dans les systèmes de vérification de programmes comme Coq ou Agda, mais les fonctionnalités commencent à arriver dans OCaml et Haskell. Il y a aussi des expériences de langages généralistes entièrement dépendants tels que Idris ou F*.

          Pour les systèmes de types homotopes, il va encore falloir attendre un moment avant d’avoir des jolies applications. En gros, en plus d’unifier de nouvelles branches des mathématiques, ça permet d’avoir des types beaucoup plus jolis, ou de transférer une preuve sur un algorithme naïf, à une preuve sur un algorithme optimisé.

          • [^] # Re: langage fonctionnel

            Posté par . Évalué à 2.

            Dans type "puissant", j'entends aussi utilisable. Le nouveau système de type de ocaml, j'ai beau avoir lu la doc et l'exemple, je n'ai rien compris. Si un ingé moyen ne comprends même pas l'outil, qui peut comprendre un code écrit avec ?

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

            • [^] # Re: langage fonctionnel

              Posté par . Évalué à 2.

              J’imagine que tu parles des GADTs dans OCaml décrits en 7.18 du manuel ? Juste parce que c’est plus facile pour moi, voilà la version Haskell :

              data Term t where
                Intg :: Int -> Term Int
                Add  :: Term (Int -> Int -> Int)
                App  :: (Term (b -> a), Term b) -> Term a
              
              eval :: Term a -> a
              eval (Intg n)    = n
              eval Add         = \x y -> x+y
              eval (App (f,x)) = (eval f) (eval x)
              
              

              On peut la charger dans l’interpréteur, et exécuter l’exemple du manuel OCaml :

               ghci> eval (App (App (Add, Intg 1), Intg 1))
               2
              
              

              L’exemple définit un AST fonctionnel dont les termes sont soit des entiers, soit des additions d’entiers, soit des applications d’une fonction à un argument. Les ASTs sont couramment utilisés comme représentation interne des compilateurs et autres interpréteurs.

              Dans ce cas, on considère l’addition comme un objet de première classe, c’est à dire qu’on peut le passer en argument, le retourner, etc, et on considère aussi qu’une fonction est curryfiée, c’est à dire qu’une fonction de deux arguments est en fait une fonction de un argument qui retourne une fonction de un argument. Ces deux concepts sont à la base de la programmation fonctionnelle. Un terme d’application fonctionne lui aussi de manière fonctionnelle, en prenant en paramètre une fonction (qui n’a qu’un argument, comme toute fonction :p), un argument, et retourne le résultat de cette fonction.

              Avec l’aide d’un interpréteur, on comprend facilement ce que fait chaque terme de l’expression :

              ghci> :t Intg 1
              Intg 1 :: Term Int
              -- La construction d’un terme entier est triviale
              
              ghci> :t App (Add, Intg 1)
              App (Add, Intg 1) :: Term (Int -> Int)
              -- On construit un terme qui représente l’addition avec 1, en Haskell ce serait (+1)
              -- On voit que le résultat est un terme-fonction qui prend un argument entier, et retourne un entier
              
              ghci> :t App (App (Add, Intg 1), Intg 1)
              App (App (Add, Intg 1), Intg 1) :: Term Int
              -- On utilise le résultat précédent (qui était un terme-fonction) en lui passant un entier
              
              

              Utiliser les GADTs va permettre de vérifier à la compilaition qu’on ne construise pas de terme erronés :

              ghci> :t Intg 1.0
              -- Erreur : on ne peut pas convertir implicitement 1.0 en Int
              ghci> :t App (Add, Add)
              -- Erreur : les paramètres de App doivent être de type b->a et b, ici ils sont identiques
              
              

              Il y a d’autres applications que cet usage trivial de vérification d’arbres bien formés, exemple qu’on ferait en POO avec des classes, et les design patterns adéquats pour l’évaluation.

              De façon générale, mais ce n’est que mon avis, les fonctions avancées des langages fonctionnels sont surtout intéressantes parce qu’elles permettent d’écrire rapidement et de façon très concise (surtout en Haskell) du code sûr et performant. Le cas d’utilisation typique est quand on travaille dans des startups, dans la recherche (scientifique ou R&D), dans lesquels on doit avoir rapidement un code qui marche pour montrer des nouveaux concepts (en gros des cas où l’important ce n’est pas le code mais ce qu’il permet de montrer). C’est mon cas, l’informatique n’est absolument pas mon domaine, juste un outil dont je me sert pour une partie de mon boulot (simulations numériques, affichages prouvables, visualisations, traitement de données). Je n’ai pas le temps de débugger, d’avoir des erreurs à l’exécution (ou du code lent de par les vérifications à l’exécution), et mon code ne sera lu ou utilisé que par un nombre nul ou très très réduit de gens, ce qui compte c’est de vérifier les idées.

              • [^] # Re: langage fonctionnel

                Posté par . Évalué à 1.

                Pour simplifier, dans un GADT par rapport au type somme classique, tu peux y mettre des fonctions en plus des type de donnés. Ok.

                L'exemple d'AST que tu donnes, je pense que cela peut se coder avec des variants en jouant sur des ensembles fermés.

                "De façon générale, mais ce n’est que mon avis, les fonctions avancées des langages fonctionnels sont surtout intéressantes parce qu’elles permettent d’écrire rapidement et de façon très concise (surtout en Haskell) du code sûr et performant."

                Tout le monde veut écrire du code rapidement et sans bug !

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

                • [^] # Re: langage fonctionnel

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

                  Tout le monde veut écrire du code rapidement et sans bug !

                  Malheureusement j'en suis moins en moins convaincu… il y a pas mal de monde qui finalement se satisfait de logiciels écris rapidement qui tombe en marche :/

                • [^] # Re: langage fonctionnel

                  Posté par . Évalué à 3.

                  Pour simplifier, dans un GADT par rapport au type somme classique, tu peux y mettre des fonctions en plus des type de donnés.

                  Non. Il n’y a pas de fonction « à l’intérieur » du type. Comme pour une somme classique, les fonctions sont indépendantes et à l’extérieur (ici c’est eval). Une somme classique s’écrirait sous la forme :

                  -- J’ai viré le tuple de App pour alléger
                  data Term = Intg Int | Add | App Term Term
                  
                  eval :: Term -> Int
                  eval (Intg n) = n
                  

                  Mais déjà là, on est bloqué aux définitions de eval Add et eval (App f x) qui retourne des fonctions de type différents. On pourrait s’en sortir en faisant retourner à eval soit un Int, soit une fonction (de deux types possibles), mais il faudrait alors tester qu’on a bien une fonction pour f dans eval (App f x) par exemple, et ça serait un test à l’exécution (avec du pattern matching développé ailleurs dans ce journal) et non pas à la compilation. Or c’est non seulement lent (exécution), inutile (le développeur ne veut jamais passer autre chose que des fonctions à App), verbeux et mal extensible (il faut rajouter tout le code de pattern matching), et sources de bugs (le compilateur aurait vu tout de suite à la compilation qu’il y avait un problème).

                  On peut vouloir dire au compilateur que chaque terme sera évalué à un type particulier, en lui associant un phantom type, sous la forme data Term a = ... | App (Term a) (Term a). Ainsi à chaque terme est associé un type à la compilation (il est viré à l’exécution). Mais ça ne résout pas nos problèmes, en ayant eval :: Term a -> a, il n’y a pas assez de contraintes sur a pour que le compilateur empêche un utilisateur d’écrire eval (Intg 123) :: String par exemple (en gros de convertir n’importe comment). La solution c’est d’utiliser les GADTs, qui vont apporter la flexibilité d’écriture nécessaire (le compilateur déduit que eval (Intg n) retourne un Int, et que eval Add retourne un Int->Int->Int), et la sécurité du système de types, en résumant (mal) le manuel d’OCaml :

                  Les GADTs sont un type somme avec des contraintes de type vérifiées à la compilation.

                  PS : On peut simplifier le code que j’ai donné au dessus, genre avec eval Add = (+).

  • # Bienvenue dans le merveilleux monde d'Ada !

    Posté par . Évalué à 9.

    Bonjour,
    Ada est un très beau langage malheureusement il garde une connotation vieillotte.
    Question ressources, il y en a pas mal, mais c'est dispersé…
    Tu peux commencer par regarder ada-france qui a quelques liens. Après, il y a adaic qui peut être intéressant.
    Bien sur, si tu veux l'info 'à la source', il y a le 'RM' qui décrit tout ce qu'il faut savoir, mais sa lecture est un peu aride.
    Question bouquins, la référence est le john barnes (Programming in Ada {95,2005}), il est bien écrit et couvre énormément de choses. La version 95 a été traduite en français, par contre de tête la version 2005 n'existe que en anglais.
    Pour des petits exemples intéressants, il y a une série de petits articles qui montre différents aspects du langages sur le site d'adacore : gems. (adacore étant éditeur d'un compilateur libre basé sur gcc et contributeur conséquent au support ada par gcc).
    Et sinon, si tu postes sur comp.lang.ada, il y a du monde qui devrait pouvoir donner plus de ressources et répondre à des questions si tu en as.
    Voili voulou, bonne lectures !

    • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

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

      il garde une connotation vieillotte

      Je pense que c'est, entre autre, parce qu'il a gardé une syntaxe type Pascal. Alors que petit à petit les syntaxes c-like ce sont imposée. Bon pas totalement si on regarde ruby (mais on peut quand même l'écrire à la c) ou python par exemple. Mais ce sont essentiellement des absences de parenthèses.

      Merci en tout cas pour les informations et line, gems semble plutôt cool pour apprendre petit à petit le langage.

      Et c'est vrai qu'il y a aussi, j'avais oublié de l'indiquer, http://libre.adacore.com à garder dans un coin.

      si tu postes sur comp.lang.ada

      Quoi, ada utilise toujours les newsgroup ? Ha ben ok pour la connotation vieillotte ;-)

      • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

        Posté par . Évalué à 3.

        Je pense que c'est, entre autre, parce qu'il a gardé une syntaxe type Pascal

        Ada est effectivement verbeux, et la syntaxe est héritée de pascal mais ce n'est pas toujours un mal… Qui n'a jamais eu de bug à cause d'une petite erreur de syntaxe (des = au lieu == et autres erreurs d'un caractère dans le source non détectables par le compilo) ? Au final, je trouve qu'on y gagne plus qu'on y perds.

        gems semble plutôt cool pour apprendre petit à petit le langage

        Je ne dirai pas que les gems aident à apprendre le langage, du moins pas dans un premier temps. Ils sont en revanche excellents pour approfondir et découvrir et approcher des aspects un peu plus poussés ou des trucs auxquels on n'avait pas pensé.

        Sinon, dans les ressources, il faut ajouter celles relatives à Ada 2012 (dernière standardisation en date) qui apporte des améliorations vraiment intéressantes au langage : https://www.adacore.com/uploads/technical-papers/Ada2012_Rational_Introducion.pdf , https://www.adacore.com/adaanswers/about/ada-2012/ ou http://www.ada2012.org/ .

        si tu postes sur comp.lang.ada

        Quoi, ada utilise toujours les newsgroup ? Ha ben ok pour la connotation vieillotte ;-)

        OK, je m'incline…

        • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

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

          mais ce n'est pas toujours un mal…

          C'est bien ce que je pense ;-)
          Mais la syntaxe le rend juste moins "conventionnel" que pas mal de langages, ce qui peu expliquer que pas mal de personne ne s'y intéressent pas.

          Merci pour les autres ressources

          OK, je m'incline…

          Nan mais c'est pas sérieux hein. C'est surprenant car de moins en moins de monde utilise de newsgroup mais ce n'est pas un problème pour autant.

      • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

        Posté par . Évalué à 2.

        Alors que petit à petit les syntaxes c-like ce sont imposée.

        Pas vraiment imposée: pour ajouter à Ruby/Python: Scala, Go, Rust, Nimrod (etc) ont pas vraiment avec une syntaxe C-like.

        • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

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

          En fait j'aurais mis rust et go dans le même sac. Ce que je voulais dire par là (mais c'était peut-être pas assez clair) c'est surtout le fait de délimiter des blocs par des accolades en comparaison à du begin/end et par exemple := (même si c'est utilisé, différemment, en go)

          • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

            Posté par . Évalué à 3.

            Si pour toi C-like c'est les accolades OK, mais bon ils ont quand même une grosse différence avec les syntaxe que je qualifie de C-like: leur déclaration des types est dans l'ordre 'Pascalien' donc lisible..
            Rust: let monster_size: int = 50;
            Scala: val arr = Array[Int]

            • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

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

              Oui, tu as raison, "c-like" n'était peut-être pas le meilleur descriptif.
              Disons alors qu'il y a quand même assez peu de langages orienté Pascal :-)

              Question bête : quelqu'un sait pourquoi en c et autres, les déclarations de type sont dans cet ordre ?

              Après c'est sur que, alors qu'on essai d'aller dans des choses plutôt minimalistes (rust et go en sont de bons exemples), la verbosité de Ada peut choquer au premier abord.
              Mais je prend ça plus comme un point positif qu'autre chose.

              • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

                Posté par . Évalué à 2.

                quelqu'un sait pourquoi en c et autres, les déclarations de type sont dans cet ordre ?

                Je pense que c'est parce qu'en mettant les noms des types d'abords tu évite un mot clef: 'int x' suffit par rapport à
                'var x: int'.

                Après avoir du code 'postfix' f(x) t[i] etc et des déclarations 'préfix', j'ai toujours trouvé ça peu lisible..

                • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

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

                  Oui mais justement, en Ada (par exemple) tu écris :

                  Flashing : Boolean;
                  

                  Et si tu veux l'affecter en même temps :

                  Flashing : Boolean := True;
                  

                  Donc il n'y a pas de var ou autre.

                  • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

                    Posté par . Évalué à 2.

                    En ocaml, tu peux ajouter aussi les types avec des ":", quand tu le fais, le code est beaucoup moins lisible qu'en C. Ce qui est amusant, car ocaml est beaucoup plus compact que le C, dans le cas général.

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

              • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

                Posté par . Évalué à 2.

                Question bête : quelqu'un sait pourquoi en c et autres, les déclarations de type sont dans cet ordre ?

                Et pourquoi les autres le font dans l'autre ordre&#8239;?

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

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

                  Sans vouloir m'avancer pour les autres langages, dans un entretien Martin Odersky expliquait son choix pour Scala en disant ça permettait (entre autres) de rendre la déclaration de type optionnelle (lorsque celui-ci est inféré).
                  Ainsi si tu écris

                  val toto: Int = 1

                  ou

                  val toto = 1

                  c'est jamais ambigu. on comprend dans les deux cas que c'est la variable toto qui est déclarée et initialisée à 1. Si l'on n'avait pas ce val il serait ambigu dans le cas du type inféré

                  toto = 1

                  Je déclare toto ou je l'assigne ?
                  De plus scala possède des val (immuable) et var (muable) donc ça permet de vérifier statiquement qu'une variable immuable n'est pas réassignée.
                  Ce qui serait acceptable dans un langage dynamique (ambiguïté entre assignation et déclaration) ne l'est pas pour une langage statiquement typé.

                  • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

                    Posté par . Évalué à 2.

                    Tu n'assignes jamais en fonctionnel :) Cela parait dingue quand on vient du C, mais on s'y fait très bien.

                    D'ailleurs, j’attends un langage avec un type (linéaire) qui empêche qu'un bloc de mémoire soit pointé par plus d'un pointeur. Cela rend hyper simple le multi-tache.

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

                    • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

                      Posté par . Évalué à -10.

                      --- " Tu n'assignes jamais en fonctionnel :) Cela parait dingue quand on vient du C, mais on s'y fait très bien " (…)

                      Vous faites de la programmation fonctionnelle ?
                      Si c'est le cas, Ocaml est fait pour ça ?
                      Et par rapport à Haskell c'est comment ?

                      Merci pour votre contribution sur cette page concernant ADA

                    • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

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

                      Merci de présumer de mes connaissances, mais je crois que je bosse en OCaml toute la journée (sur un projet que tu dois sûrement connaître vu que tu en parles souvent ici) et en Scala pour mes projets personnels (après avoir bossé dessus dans le cadre de recherches).
                      Donc reprenons, maintenant que j'ai fixé ça : en Scala (seul langage dont je parle ici, cf le début de mon message) on assigne très bien une valeur à une variable muable.

                      Pour le multi-tâche je travaille par passage de messages immuables via des acteurs généralement, ce qui évite la mémoire partagée, et ça change la vie.

                      • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

                        Posté par . Évalué à 2.

                        Je n'ai rien présumé du tout, je répondais juste à : "Je déclare toto ou je l'assigne ?"

                        "(sur un projet que tu dois sûrement connaître vu que tu en parles souvent ici)"

                        Je parle beaucoup ici, tu parles de quoi exactement ?

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

                        • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

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

                          Oui mais je persiste "je déclare toto ou je l'assigne" dans le cadre de Scala (encore une fois, j'ai bien précisé dès le début que je parlais uniquement de Scala) est tout à fait une phrase valide ;)

                          var toto = 4
                          toto = 3

                          la deuxième ligne est une assignation (même la spec le dit ;))
                          Bref… Ne traumatisons pas plus les drosophiles qu'elles ne le sont déjà à ce point.

                          Allez un indice : c'est un générateur de code écrit en OCaml. Mais je suis pas ici pour me vanter donc on s'en tape.

                          • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

                            Posté par . Évalué à 2.

                            Ok, tu parles de KCG :)

                            Mais ce qui me désole le plus, c'est qu'il y a mon nom écrit en gros au dessus, et qu'on bosse dans la même boite, sans que tu es l'air de t'en apercevoir. Tu es sans doute à Toulouse, mais bon, la boite fait moins de 100 personnes…

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

                    • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

                      Posté par . Évalué à 3.

                      Si je ne me trompe pas en Scala les valeurs (val) sont immuables mais les variables sont muables.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                      • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

                        Posté par . Évalué à 0.

                        Je crois que Lucas c'est mal exprimer au sujet des val, var, mutable et immutable.

                        val a = scala.collection.mutable.ArrayBuffer(1,2)
                        a += 12
                        ArrayBuffer(1, 2, 12)

                        "a" est mutable.
                        La différence c'est que "a" ne peux pas être réaffecté dans le même scope(enfin je crois).

                        • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

                          Posté par (page perso) . Évalué à 2. Dernière modification le 26/06/13 à 22:26.

                          Ne confonds pas référence (im)muable et objet (im)muable

                          Dans ton exemple a est une référence immuable vers un objet muable. C'est-à-dire (si on descend assez bas sur comment ça marche) que tu ne pourras pas changer l'adresse mémoire pointée par a (référence immuable), mais tu pourras changer le contenu à cette adresse (objet muable).

                          utiliser le mot-clef val en Scala est environ comme utiliser une variable final en Java (pour les variables locales uniquement, pas pour les attributs d'une classe), donc oui ne peut pas la réassigner (pour la simple et bonne raison que justement cette référence n'est pas muable justement…)

                          Mon raccourci muable/immuable sans préciser ce à quoi ça s'appliquait peut prêter à confusion il est vrai…

    • [^] # Re: Bienvenue dans le merveilleux monde d'Ada !

      Posté par . Évalué à 4. Dernière modification le 25/06/13 à 08:25.

      Bonne découverte d'Ada !

      En terme de ressources, pas mieux que toutes celles déjà citées.

      Son typage fort n'est pas l'élément qui m'a le plus marqué, pour ma part, c'est surtout ses primitives pour décrire du multi-tâche (notion de taches, de rendez vous, de protection de ressource…) qui m'ont le plus impressionné.

  • # Proust alors.

    Posté par . Évalué à -10.

    Alors, elle est pas belle la vie ?

    Gaspard Proust c'est quand même autre chose hein. Ce n'est pas du Raymond Devos mais il est excellent.
    Bon, ce n'est que mon avis.

    --- " Ha oui, pourquoi faire ça ? Ben juste pour écrire des logiciels un peu plus sûr, avec moins de possibilité de bugs, d'effets de bords, etc. " (…)

    Avec du C c'est tout aussi sur si bien sur on respecte certaines règle.
    Je crois même que lorsque OpenBSD se targue d'être sur c'est grâce à sa rigeur dans le codage.
    Non?

    PS: Oui, d'accord parler d'openBSD sur un site où la horde de linuxien est la norme c'est pas bien.
    Parler de GNU/linux c'est bien.

    • [^] # Re: Proust alors.

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

      Hein ?

    • [^] # Re: Proust alors.

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

      Avec du C c'est tout aussi sur si bien sur on respecte certaines règle.

      Avec de l'assembleur aussi c'est tout aussi sûr si on respecte certaines règles.

      PS: Oui, d'accord parler d'openBSD sur un site où la horde de linuxien est la norme c'est pas bien.
      Parler de GNU/linux c'est bien.

      Et après tu vas encore venir te plaindre comme un pauv' petit calimero que les gens te moinsent. Ben finalement faut pas s'étonner. Et en plus, tu es un contre exemple à ta propre théorie des extrêmes. Si cette théorie était vraie tu serais parti d'ici depuis longtemps.

      • [^] # Re: Proust alors.

        Posté par . Évalué à -9.

        --- " Et après tu vas encore venir te plaindre comme un pauv' petit calimero que les gens te moinsent. Ben finalement faut pas s'étonner. Et en plus, tu es un contre exemple à ta propre théorie des extrêmes. Si cette théorie était vraie tu serais parti d'ici depuis longtemps " (…)

        Me plaindre à titre personnel? non. Pour les autres: oui.
        Ma théorie se tient.
        Il y a toujours des exceptions, et j'en suis un, il paraît même le seul puisque les autres ne se montrent pas trop.
        Dans ma dépêche, j'ai ajouté une remarque sur ce que j'ai vécu une fois dans le monde réel…
        J'ai transposé ça au monde internet.

        Sinon j'ai une question: qu'est-ce qui est faux dans ce que j'ai écrit ?
        OpenBSD ne se targuait-il pas de la qualité de son OS par rapport à tous les autres ?
        (Perso je n'aime pas trop la personnalité de De Raadt, surtout qu'il a été virulent avec linux, mais bon)

        • [^] # Re: Proust alors.

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

          Me plaindre à titre personnel? non. Pour les autres: oui

          Super pratique pour se planquer ça.
          Bon et sinon, on les a entendu les autres ? Ils ont demandé quelque chose ? Ils t'ont soutenu ?

          Il y a toujours des exceptions, et j'en suis un

          Oui tu fais partie des exceptions.
          Avec 20 comptes avec un karma <= 0 sur les 3900 comptes actifs tu fais donc partie d'un ensemble comportant 0.5% des utilisateurs actifs. En ce sens tu es une exception. Pour le reste tu es malheureusement plus une pollution.

          qu'est-ce qui est faux dans ce que j'ai écrit ?

          Et qu'est ce qui est faux dans le fait de dire que l'assembleur aussi c'est sûr ?
          On peut écrire des logiciels sûr dans, je pense, à peu près tous les langages, même en brainfuck ou whitespace. Mais ça ne veut pas dire que brainfuck ou whitespace est forcément un bon choix.

          Et, entre autre, les exemples cités dans le journal montrent qu'il y a quand même une sacré différence en terme d'investissement nécessaire pour avoir quelque chose de sûr suivant les langages.

          Ha oui, et sinon (et ça peut intéresser tout le monde) il y a aussi spark qui est basé sur ada : http://www.spark-2014.org/ pour la version 2014, utilisant la programmation par contrat de Ada 2012.

          • [^] # Re: Proust alors.

            Posté par . Évalué à 2.

            Ou SCADE, mais c'est pas du tout libre.
            http://www.esterel-technologies.com/products/scade-suite/prototype-design/scade-suite-modeler/#editor

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

          • [^] # Re: Proust alors.

            Posté par . Évalué à -9. Dernière modification le 25/06/13 à 12:21.

            --- " Bon et sinon, on les a entendu les autres ? Ils ont demandé quelque chose ? Ils t'ont soutenu ? " (…)

            1) J'aimerais bien qu'on ne discute pas de ça ici.
            2) Les autres, je leur donnerais un très bon conseil: ne dites rien.
            3) Pour les soutiens, je n'en cherche pas, mais s'ils soutiennent ils ne te le diront pas en tout cas.
            4) Pour la pollution, laisses les visiteurs qui ne connaissent pas LinuxFR décider par eux-mêmes.

            ADA

            1) Ma remarque sur le C ne sous entend pas qu'ada est mauvais, c'est votre vision des choses qui est fausse sur ce point.
            2) Le C est difficile parce qu'il n'est pas un langage objet dans le sens d'ADA.
            3) Le C#/Mono/qu-importe-le-nom ont été inventé pour pallier à certains problèmes du C.
            Vala me paraît être ce qu'il y a d'intéressant pour régler certains problèmes lié au C.
            4) Le langage assembleur est très lié au matériel, donc votre remarque n'est pas pertinent sur le sujet.
            5) J'aurais aimé lire des remarques sur Java vs ADA, ça aurait été intéressant.
            6) Spark ? Bof.
            7) On m'a dit du bien de LISP pourquoi ne pas plutôt le comparer à LISP ?

            • [^] # Re: Proust alors.

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

              Sur la première partie je rigole, ça suffira bien comme réponse !

              c'est votre vision des choses qui est fausse sur ce point

              Quelle vision ?

              le C est difficile parce qu'il n'est pas un langage objet dans le sens d'ADA.

              Nope. Et je ne parle même pas de l'orientation objet ici, juste du typage.
              D'ailleurs ce n'est pas une histoire d'être difficile ou non, c'est une histoire de savoir si le langage offre des possibilité pour éviter des problèmes / erreurs / bugs ou non. Et pouvoir mettre la valeur 5 (poires) dans une variable (pomme) en est un, qui peut facilement être éliminé en Ada, beaucoup moins en C.

              Le C#/Mono/qu-importe-le-nom ont été inventé pour pallier à certains problèmes du C

              C# est plutôt là pour concurrencer Java (avec un bytecode portable), à la rigueur pour concurrencer C++ mais pas C.

              Le langage assembleur est très lié au matériel, donc votre remarque n'est pas pertinent sur le sujet.

              Bien sur que si c'est pertinent.
              C'est pertinent parce que ça permet de coder un logiciel.
              C'est pertinent parce que Ada cible (entre autre) l'embarqué, là où on peut trouver de l'assembleur.
              Et ton programme C, une fois compilé, quel est la différence entre ça et de l'assembleur ?

              J'aurais aimé lire des remarques sur Java vs ADA, ça aurait été intéressant.

              Ben j'ai montré un exemple côté typage entre Ada et Java justement.

              Spark ? Bof

              C'est à dire ?

              On m'a dit du bien de LISP pourquoi ne pas plutôt le comparer à LISP ?

              Parce que mes connaissances en lisp sont limitées pour faire une comparaison et que je présentais rapidement ada et non ada vs the world.

            • [^] # Re: Proust alors.

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

              Le C est difficile parce qu'il n'est pas un langage objet dans le sens d'ADA.

              Non, le C est difficile parce qu'il est plus proche de l'assembleur et que les abstractions sont faites à la main. On peut tout à fait écrire du code Ada qui n'est pas objet et le langage n'est pas objet à l'origine mais a évolué en 95 pour fournir un support objet Mais encore une fois, programmer objet (i.e avec polymorphisme, dynamic dispatching…) n'est pas obligatoire.

              J'aurais aimé lire des remarques sur Java vs ADA, ça aurait été intéressant.

              En voilà une parmi d'autres.

              Spark ? Bof.

              C'est sûr qu'il faut avoir déjà la culture Ada pour "apprécier" Spark. Celui-ci est un langage de niche créé pour éviter les écueils de la programmation Ada et faciliter l'analyse statique du code donc tant que l'on a pas à programmer un système dont les défauts ont des impacts en termes de vies humaines, oui, bof

              On m'a dit du bien de LISP pourquoi ne pas plutôt le comparer à LISP ?

              Parce qu'ils ne sont pas de la même famille à savoir procédural contre impératif/fonctionnel ? D'ailleurs, quel LISP ? Common LISP, Le LISP, e LISP ?

              • [^] # Re: Proust alors.

                Posté par . Évalué à -9.

                1) Déjà merci pour votre contribution enrichissante.

                2) " On peut tout à fait écrire du code Ada qui n'est pas objet " (…)

                Tout à fait, d'ailleurs la majorité des langages de programmation modernes n'exigent pas l'objet.
                Ma remarque concernait le fait que le C est difficile dès lors qu'on veut faire de l'objet.
                Pour faire cela simplement, il vaut mieux passer par vala.

                3) Merci pour les deux liens: je n'en demandais pas plusieurs et vous avez fait l'effort de m'en donner.

                Celui-ci est un langage de niche créé pour éviter les écueils de la programmation Ada

                Une "surcouche" genre vala pour le langage C ? Là ce serait intéressant.

                LISP

                J'avais lu il y a déjà longtemps que LISP est un langage qui en gros est supérieur à java en tous points.
                Je me suis donc demandé si ADA comparé à du LISP n'est pas intéressant dans une discussion ici, mais l'auteur de ce journal ne connaissant rien au sujet de LISP, je dois accepter de passer mon tour.
                Ce qui serait intéressant c'est l'aspect programmation concurrente et fonctionnelle de ADA et d'avoir des infos de comparaison avec LISP.
                Si personne ne peut en parler ce n'est pas grave.

                • [^] # Re: Proust alors.

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

                  il vaut mieux passer par vala

                  Mouai. Quelqu'un utilise vala en dehors de linux/gtk par exemple ?
                  J'aurais plutôt dit de passer à c++ (mouai), obj-c, voir D par exemple. Vala étant bien le dernier me venant à l'esprit.

                  Au fait, je n'ai pas dit que je ne connaissais rien à lisp… faut arrêter de déformer les propos hein.
                  Par contre oui, mes connaissances en lisp (enfin elisp pour moi) ne me suffisent pas pour comparer, ni d'ailleurs mes connaissances en ada.
                  Mais je dirais surtout que c'est pas du tout le même type de langage (fonctionnel pour lisp) et c'est un peu comme si tu demandes de comparer haskell et c, ça risque d'être compliqué car une grosse partie de la comparaison va venir du paradigme différent.

                • [^] # Re: Proust alors.

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

                  c'est l'aspect programmation concurrente et fonctionnelle de ADA

                  Autant pour concurrente, on est bien d'accord, c'est un point intéressant, autant pour fonctionnel, j'ai bien l'impression que l'on ne parle pas de la même chose. Ada n'est pas un langage fonctionnel et ne le sera jamais, il s'agit d'un langage impératif.
                  En ayant l'esprit très ouvert, on pourrait peut-être assimiler les dernières avancées en termes de prédicat pour la vérification statique de code de programmation pseudo-fonctionnelle mais faut vraiment être très ouvert.

                  Si personne ne peut en parler ce n'est pas grave.

                  Ben, on peut toujours parler de LISP mais franchement, si je peux comprendre à peu près qu'on compare avec Ocaml qui est multi-paradigme, la comparaison avec LISP peut s'arrêter à : "Il y a plus de parenthèses en LISP".

                • [^] # Re: Proust alors.

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

                  Une "surcouche" genre vala pour le langage C ? Là ce serait intéressant.

                  Justement, il s'agit non pas d'une surcouche mais d'un sous-ensemble avec annotation. En clair, Ada est un langage généraliste et possède donc des fonctionnalités qui ne sont pas utilisables en l'état pour des applications critiques d'où l'existence de Spark.
                  C'est justement cela qui rend Spark intéressant pour ce domaine.

            • [^] # Re: Proust alors.

              Posté par . Évalué à 6.

              Tu numérote tes lignes maintenant ?

              Le C ne t'aide absolument pas à avoir un programme sûr. S'appuyer sur des règles de codage c'est bien, mais ce n'est pas suffisant, il faut aussi faire de l'audit et avoir une batterie de tests de qualité (déterminer la qualité des tests et avoir des tests qui eux-même ne contiennent pas de bug est encore une autre histoire). C'est vrai dans tous les langages, mais il y a des langages qui apportent une sécurité supplémentaire qui soit n'est pas désactivable soit l'est manuellement donc tu sais que par défaut, tu a une meilleure fiabilité, quelque soit la personne qui a écris le programme.

              Donc je vois pas en quoi arriver et dire ceci est pertinent :

              Avec du C c'est tout aussi sur si bien sur on respecte certaines règle.
              Je crois même que lorsque OpenBSD se targue d'être sur c'est grâce à sa rigeur dans le codage.
              Non?

              Sans rien de technique ou quoi que ce soit d'un peu factuel, mis à part un « on dit ». Si tu veut nous dire que le processus de développement est plus important que le langage et que celui de ceux qui font OpenBSD est au top. Ok mais faut le dire.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Proust alors.

              Posté par . Évalué à 6.

              2) Le C est difficile parce qu'il n'est pas un langage objet dans le sens d'ADA.

              4) Le langage assembleur est très lié au matériel, donc votre remarque n'est pas pertinent sur le sujet.

              C'est parce qu'il a une vocation différente qu'il est toujours délicat de le comparer à ADA. C est pensé comme un assembleur portable. De son côté, Ada est un langage de haut niveau permettant énormément d'abstractions impossibles en C (les enums sont plus que des entiers, les tableaux sont plus qu'un pointeur vers le premier élément, la sémantique du multi-tache construite dans le langage et bien d'autres encore…).

              Le choix du C peut donc se montrer pertinent pour développer des couches bas niveau (même s'il n'est pas nécessairement le seul choix possible), mais il atteint ses limites dans des applications de plus haut niveaux.

              Quoi qu'il en soit, par philosophie le C est permissif et pré-suppose que le développeur sait exactement ce qu'il fait. Il laisse faire même si parfois c'est une erreur évidente. C'est d'ailleurs (en partie) source de failles de sécurités en tout type (genre cela). De son côté Ada empêche tant que faire se peu que le développeur fasse des choses «risquées» (genre écrire en dehors des bornes d'un tableau), est parfois verbeux pour éviter tout ambiguïté, et dispose de compilateurs pointilleux.

              Bien sur, une discipline importante permet de faire du C très propre et fiable, et bon nombre de systèmes extrêmement robustes en sont la preuve indiscutable. Cependant, il peut être intéressant de placer des garde fous au niveau du langage en plus de ceux permettant de faire du bon C.

              En ce qui me concerne je considère que c'est un atout significatif.

              5) J'aurais aimé lire des remarques sur Java vs ADA, ça aurait été intéressant.

              Dans les grandes lignes : Ada est compilé nativement alors que Java nécessite un VM. Il est ainsi plus aisé de faire du bas niveau en Ada qu'en Java (constructions permettant d'être très précis sur la représentation machine des objets utilisés, on peu faire comme en C et accéder directement à la mémoire si vraiment on en a besoin, …). Après Java a d'autres avantages, dont notamment la capacité de faire de l'introspection ce qui n'est pas envisageable en Ada.

              Il est en général plus intéressant de comparer Ada à C++ car ils se ressemblent plus sur ces aspects (et bien d'autres).

              Bon, j'avoue que je prêche un peu pour ma paroisse, mais sachez que je ne dénigre pas le reste pour autant ! L'ensemble des langages disponibles offrent une diversité très profitable, surtout si on regarde ce qui se fait chez les voisins. Ça donne de bonnes idées et permet d’acquérir de bonnes pratiques parfois.

              • [^] # Re: Proust alors.

                Posté par . Évalué à 3.

                Le choix du C peut donc se montrer pertinent pour développer des couches bas niveau (même s'il n'est pas nécessairement le seul choix possible), mais il atteint ses limites dans des applications de plus haut niveaux.

                L'omnipresence (la capacité qu'on (presque&#8239;?) tous les langages à s'interfacer avec lui et la disponibilité de celui-ci sur (presque&#8239;?) toutes les plateformes) du C en fait un langage de choix pour un tas d'autres application (comme les bibliothèque par exemple.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Proust alors.

                  Posté par . Évalué à 1.

                  Oui.

                  C'est une façon de répondre à la contrainte. C a cet avantage que les concepts qu'il manipule (proches de la machine) forment un bon «dénominateur commun» à bon nombre de langages. Si on cherche à développer quelque chose de facilement réutilisable dans de nombreux langages, il semble assez pertinent de se limiter à ces concepts.

                  Ceci étant dit, et étant donné que beaucoup de langages s'interfacent facilement avec le C, je suppose qu'il est également possible de faire le contraire. Écrire la librairie dans son langage qu'on aime bien et qui est trop fort de la mort qui tue, prévoir une interface se limitant aux concepts simplement manipulables en C et ensuite écrire un binding en C.

                  Je cherche un exemple percutant où ça aurait été fait, mais je n'en ai pas qui me vienne à l'esprit :( Est-ce que quelqu'un a un exemple qui ait utilisé ce genre d'artifice ?

                  • [^] # Re: Proust alors.

                    Posté par . Évalué à 2.

                    Qt doit avoir un binding en C. Sinon il y aussi les OS écris en autre chose que du C et qui exposent des appels systèmes en C.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Proust alors.

                Posté par . Évalué à -9.

                --- " Le choix du C peut donc se montrer pertinent pour développer des couches bas niveau (même s'il n'est pas nécessairement le seul choix possible), mais il atteint ses limites dans des applications de plus haut niveaux " (…)

                Exactement d'où l'existence de langages comme vala, qui permet d'écrire du C. C'est un genre de préprocesseur C.
                On peut compiler directement du vala d'ailleurs.
                Mais il me semble que vala ne peut pas se passer de GObject… (Je n'ai pas encore essayé donc je ne peux pas dire que c'est cela)

                Donc je résume vos propos :
                1) Ada c'est mieux que le C pour l'aspect langage de haut niveau
                2) Ada permet quand même de faire du bas niveau.
                3) Le compilateur est plus exigeant
                4) On ne peut pas dépasser les bornes d'un tableau par exemple (pas de dépassement de tampon possible?)
                5) Les gardes fous d'ADA sont un atout significatifs dans le sens où un développeur un peu distrait n'aura pas de soucis

                JAVA

                Je parlais de java parce qu'on dit tant de bien de lui, alors que personnellement je n'ai jamais été convaincu par ce langage dès l'instant où python est arrivé.
                1) Java ne peut pas se passer de JVM, mais on peut compiler du Python (Cython) et de l'ADA.
                2) Le codage de python est plus propre que celle de java (pas de problèmes de parenthèses oubliées)

                Ma question étant sur java, le code compilé peut-il fonctionner en multitâche sans problème ?
                Par exemple, intel a créé un compilateur pour la programmation parallèle pour le langage C/C++.
                Comparativement à java ce serait comment ADA et si vous pouvez y répondre comparativement aux possibilités du compilateur d'intel, ca s'en rapproche ?

                --- " Bon, j'avoue que je prêche un peu pour ma paroisse, mais sachez que je ne dénigre pas le reste pour autant ! " (…)

                A titre personnel, cela ne me gène nullement, mais il faut toujours être prudent sur LinuxFR.
                Lorsque je défends debian contre Red Hat c'est toujours un moinsage en règle qui m'attend.

                En tout cas, j'ai aimé votre contribution… Revenez plus souvent.

                • [^] # Re: Proust alors.

                  Posté par . Évalué à 2.

                  Je parlais de java parce qu'on dit tant de bien de lui, alors que personnellement je n'ai jamais été convaincu par ce langage dès l'instant où python est arrivé.

                  Tu viens de démontrer une grande ignorance avec cette phrase. Python est arrivé en 1991. Java, bien qu'existant plus ou moins en interne chez Sun à ce moment, n'était même pas encore disponible pour le grand public (et puis, histoire d'être complet, Perl existe depuis 1987).

                  De plus tu ne connais visiblement pas bien les limites de chacun de ces langages. Java permet de faire du vrai multi-threading, pas Python.

                  • [^] # Re: Proust alors.

                    Posté par . Évalué à 1.

                    Java permet de faire du vrai multi-threading, pas Python.

                    Le langage Python en lui-même permet tout à fait de faire du vrai multithreading (Jython et IronPython en sont la preuve).
                    Il est vrai que l‘implémentation la plus répandu (CPython) ne le permet pas (à cause du GIL, Ruby est d’ailleurs logé à la même enseigne).
                    Mais c’est un détail, non négligeable certes, d‘implémentation. Le langage en lui-même en est tout à fait capable.

                    • [^] # Re: Proust alors.

                      Posté par . Évalué à 2.

                      Je parle des implémentations de référence de Python (et oui, Ruby et Perl ont le même problème). IronRuby, IronPython ou Jython sont des exceptions, et quelque part c'est triste à dire, mais ils introduisent une incompatibilité si tu fais du « vrai » multithreading avec (techniquement, Python permet le multithreading pour le multiplexage des E/S). Donc je maintiens ce que je dis : Python, celui utilisé à peu près partout, ne supporte pas un multithreading « général ».

                  • [^] # Re: Proust alors.

                    Posté par . Évalué à -9.

                    J'utilisais Java avant python…
                    (c'est ce que je voulais dire)

                    Pourriez vous nous expliquez ce qu'est pour vous le vrai multithreading ?
                    Quelle version de Python utilisez vous ? (Ou devrais je dire, avez vous vu) pour affirmer qu'il ne fait pas du vrai multithreading ?

                    • [^] # Re: Proust alors.

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

                      Python ne fait pas du vrai multithreading parce qu'il ne permet pas que deux threads s'exécutent en parallèle.

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Proust alors.

                  Posté par . Évalué à 2.

                  Donc je résume vos propos :
                  1) Ada c'est mieux que le C pour l'aspect langage de haut niveau

                  Ada est plus adapté que le C pour faire du haut niveau (il est d'ailleurs fait pour ça). «Mieux» est un mot un peu fort, c'est très subjectif…

                  2) Ada permet quand même de faire du bas niveau.
                  3) Le compilateur est plus exigeant

                  C'est un doux euphémisme

                  4) On ne peut pas dépasser les bornes d'un tableau par exemple (pas de dépassement de tampon possible?)

                  Non. Tout comme en Java d'ailleurs (c.f. le procès entre google et oracle sur la vérification du fait qu'un indice est dans les bornes)

                  5) Les gardes fous d'ADA sont un atout significatifs dans le sens où un développeur un peu distrait n'aura pas de soucis

                  Oh si il en aura, mais avec le compilo ;) Le grand intérêt est que (hormis cas vraiment extrême), si le programme passe les vérifications du compilateur et ne fait pas ce qu'on attend de lui, c'est que l'erreur est dans la logique du code et pas dans sa traduction dans le langage.

                  Ma question étant sur java, le code compilé peut-il fonctionner en multitâche sans problème ?

                  Le code ada compilé fonctionne en multitache sans problème, c'est même un prérequis. Bien sur, ça demande un minimum «glue», qui a pour mission de faire le lien entre les abstractions du langage et les primitives fournies par le système cible. Mais ça c'est le taf du compilo, pas celui du développeur.

                  Par exemple, intel a créé un compilateur pour la programmation parallèle pour le langage C/C++.
                  Comparativement à java ce serait comment ADA et si vous pouvez y répondre comparativement aux possibilités du compilateur d'intel, ca s'en rapproche ?

                  Ne connaissant pas ce compilateur ni ses possibilités, je ne peux pas répondre.

                  • [^] # Re: Proust alors.

                    Posté par . Évalué à 2.

                    Je ne sais pas ce que « compilateur parallèle » signifie. Intel a une option de parallélisation « automatique » qui n'est mise en œuvre que lorsque les boucles sont triviales à paralléliser (pas de dépendance portée sur plus d'une itération, etc.). Sinon, icc comme gcc implémentent OpenMP, qui nécessite une parallélisation explicite d'un programme écrit en C/C++ (ou Fortran avec ifort/gfortran).

        • [^] # Re: Proust alors.

          Posté par . Évalué à 5.

          Me plaindre à titre personnel? non. Pour les autres: oui.

          Dans les deux cas ça revient au même, tu te plains.

          Par ailleurs, Internet fait partie du monde réel.

          Sinon j'ai une question: qu'est-ce qui est faux dans ce que j'ai écrit ?

          Ça :

          parler d'openBSD sur un site où la horde de linuxien est la norme c'est pas bien.

          « horde de linuxiens » c'est déjà un peu insultant et vu que beaucoup d'articles (dépêches, journaux) sur *BSD ont de bons scores tu es clairement à coté de la plaque.

          Sinon oui c'est vrai, OpenBSD fait particulièrement attention à la qualité de son code. Mais comme on te l'a dit, on sait bien que l'on peut faire du code propre, élégant dans n'importe quel langage, c'est juste que c'est plus facile avec certains langages.

          Le passage sur Gaspard Proust c'est un bel exemple de propos inutile. Il n'a pas le monopole de la phrase : « Alors, elle est pas belle la vie ? » ! De plus, personnellement, je ne pense pas que l'on puisse comparer son humour avec celui de Raymond Devos, c'est pas le même genre d'humour. Il y avait beaucoup de poésie chez Devos, ce n'est pas le cas chez Gaspard Proust.

          • [^] # Re: Proust alors.

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

            Le passage sur Gaspard Proust c'est un bel exemple de propos inutile. Il n'a pas le monopole de la phrase : « Alors, elle est pas belle la vie ? » !

            Surtout que je ne sais même pas qui c'est…
            Moi je pensais plutôt à une pub avec un gosse qui dirait un truc dans le genre (même si ce n'est pas la phrase exacte).

            Ho et puis on s'en fout en fait !

            • [^] # Re: Proust alors.

              Posté par . Évalué à 2.

              Et c'est pas comme si tu pouvais faire Ctrl+T, taper "gaspard proust" et te renseigner un peu ?

              C'est un comique de la taïlaÿ (il doit faire de la scène aussi), pas forcément toujours très drôle je trouve, mais qui en sort de bonnes de temps en temps.

              • [^] # Re: Proust alors.

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

                Ola calmos.
                Ce que je voulais dire c'est que je n'avais surtout pas écris cette phrase en pensant à Gaspard Proust, d'où le côté totalement hors sujet de Kadalka.

                • [^] # Re: Proust alors.

                  Posté par . Évalué à 2. Dernière modification le 26/06/13 à 08:32.

                  OK :)

                  Je n'ai jamais cru que tu faisait référence à cet artiste, je n'y ai même pas pensé à la lecture de la phrase « alors elle est pas belle la vie ? », mais tu as écrit :

                  Surtout que je ne sais même pas qui c'est…

                  C'est pour ça. Tu aurais dû écrire : « Surtout que je ne savais pas qui c'était. » ;)

    • [^] # Re: Proust alors.

      Posté par . Évalué à 10.

      [à propos de la sûreté des langages de programmation] Avec du C c'est tout aussi sur si bien sur on respecte certaines règle.

      Je code en C et C++ très régulièrement. En fait, ce sont presque les deux seuls langages que j'utilise. J'écris et j'utilise du code multithreadé à longueur de journée. En fait, une partie de mon boulot consiste à maintenir une bibliothèque pour l'expression de programmes parallèles.

      Le C, par définition, n'est pas sûr pour le multi-tâche. Plus exactement, C89 et C99 ne le sont pas, car ils ne savent pas ce qu'est une tâche. C11 a repris le même concept de tâche que C++11, et ça copie plus ou moins les threads POSIX. Bon ben autant dire qu'on est toujours pas dans le « sûr » par défaut.

      En fait, l'un des créateurs du modèle mémoire de C++, J.Boehm (quand on suppose un processus séquentiel, pas besoin de modèle mémoire, mais une fois qu'on parle d'un modèle multi-tâches, alors il faut pouvoir décrire les règles de visibilité de lectures/écritures) a même écrit un papier qui s'intitule Threads Cannot Be Implemented as a Library. Un autre, grand expert des modèles d'exécution parallèles, a écrit un excellent article intitulé The Problem With Threads. Dans son papier, il décrit toutes les jolies propriétés liées aux machines séquentielles de Turing. Il explique en quoi c'est extrêmement important pour garantir que les programmes séquentiels sont corrects. Puis il explique comment, dès qu'on a des threads de type PThreads, toutes ces garanties s'envolent par la fenêtre, et qu'il est impossible de prouver qu'un programme multi-threadé est dépourvu de bogues et de race conditions (ou data races). Il propose ensuite un modèle où tout est déterministe par défaut, et seules des régions précises de code sont marquées comme « non-déterministes ». Bref, l'inverse de ce que proposent les threads classiques.

      Tout ça pour dire quoi ?

      1. Oui, il est possible d'écrire des programmes concurrents en C/C++ qui font ce qu'on veut
      2. Si on veut faire quelque chose de complexe, il faut un programmeur expert pour le faire correctement
      3. Si un langage de programmation intègre la concurrence directement (Java, Ada par ex), alors il est possible de simplifier la gestion de la concurrence car un ensemble de règles (liées à la mémoire, aux opérations autorisées au sein du programme, etc.) rendront la gestion de la concurrence mieux encadrée.
      4. En règle générale, si quelque chose requiert un expert pour être correctement programmée, alors il faut sans doute qu'elle soit intégrée au langage.
      5. Seule exception à la règle précédente : lorsque le contrôle sur le matériel est un critère dominant dans les pré-requis du projet (et encore, Ada et d'autres langages ont prouvé qu'on pouvait faire du bas-niveau sans sacrifier nécessairement en perfs ou en structures pour le langage…)
  • # Majuscule ?

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

    le respect des majuscules

    Ben justement, contrairement aux autres langages, Ada est insensible à la casse. Les variables CrEv, CReV, CREV etc représentent toutes la même chose.
    C'est assez contre-intuitif quand on vient d'un autre langage mais finalement, ça évite d'avoir à retenir le nom d'une variable ET sa casse.
    Sinon, je suis d'accord qu'au premier abord, c'est pas folichon et pas franchement à la mode mais une fois qu'on a compris que le compilo n'est pas notre ennemi, ça va beaucoup mieux :D
    Bienvenue alors :)

    Ah oui, pour les ressources, en voici quelques-unes :
    - Les gemmes d'Adacore
    - Le newsgroup en anglais dont le niveau est élevé puisqu'on y trouve plusieurs participants à la norme
    - Le newsgroup en français à plus faible débit vu qu'on doit être une vingtaine dessus mais dont la qualité est tout aussi bonne que la version anglaise :D
    - le topic Reddit

    • [^] # Re: Majuscule ?

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

      Bon, vu que je m'étais largement fait griller sur les liens précédents, je vais en donner de nouveaux :)
      - Pour faire joujou avec un Arduino, rien ne vaut le blog de Tero
      - Pour s'amuser à faire du temps réel sur bare metal, MarteOS
      - Pour les programmeurs C++ et bien qu'il traite de la version 95, ce document reste pas mal

      Voilà

    • [^] # Re: Majuscule ?

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

      En fait pour le côté casse, finalement que le langage soit sensible ou non n'est pas très important, c'est surtout que emacs force une convention de codage sans qu'on ait besoin d'y réfléchir. Et ça je trouve ça vraiment cool :-)

      • [^] # Re: Majuscule ?

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

        En outre, si je me rappelle bien, il te permet de respecter la norme de codage conseillée par l'Ada Quality and Style Guide mais c'est à vérifier.
        D'ailleurs, tu peux vérifier tout ça avec le compilateur ou des outils externes comme AdaControl.

        • [^] # Re: Majuscule ?

          Posté par . Évalué à 3.

          C'est dommage que ce ne soit pas forcé je trouve. J'aime bien l'idée dans ruby de donner une signification à la casse.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Majuscule ?

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

            Sémantiquement parlant, c'est quoi la différence entre Michel, michel et MICHEL ?
            Ok, on pourrait dire que :
            - Michel, c'est le prénom
            - michel, un objet ?
            - MICHEL, un sigle ?

            C'est un peu subjectif, non ?
            En plus, il ne faut pas oublier qu'en Ada, un identifiant n'existe que dans un contexte comme une fonction, une procédure ou un package.

            • [^] # Re: Majuscule ?

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

              C'est un peu subjectif, non ?

              Oui, ce n'est pas pour ça que ce n'est pas utile.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Majuscule ?

              Posté par . Évalué à 2.

              C'est un peu subjectif, non ?

              Non. Plus à partir du moment où tu as des standards qui sont admis par la majorité (ce que semble indiquer ton commentaire au dessus).

              Ça crée bien moins de pièges potentiels dans le code (si tout le monde suit une même règle sauf une minorité). Après il faut que ce soit bien fait bien évidement.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Mmmh

    Posté par . Évalué à 7.

    Ben c'est plutôt facile :

    C'est plutot facile, mais c'est malheureusement completement faux.
    Bon, pour l'heure mod 24, ok, mais pour les annees, 366 ca le fait pas du tout (le compilo ne t'empechera pas de creer une annee bisextile invalide), et pour les secondes, ca le fait jusqu'a ce que tu tombes sur une leap second, et j'abordes meme pas le sujet des heures d'ete/hiver ou des timezones, et autres trucs joyeux omme les divers calendriers.
    Si ya un truc qui se represente pas avec un simple type tout con, c'est bien les dates et la mesure du temps en general.

    Bon, ca veut pas dire que ce genre de typage est pas pratique, mais t'aurais pu prendre un exemple un peu moins casse gueule.

    Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: Mmmh

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

      Surtout qu'il y a grosso modo ce qu'il faut dans la norme mais dans le principe, c'est quand même ça.

    • [^] # Re: Mmmh

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

      Attends, que je comprenne bien :

      • je parle de stocker une heure
      • « Ben c'est plutôt facile »
      • type Hour is mod 24;

      Et là

      C'est plutot facile, mais c'est malheureusement completement faux.

      Ha oui mais non

      Bon, pour l'heure mod 24, ok

      Bon alors, c'est bon ou c'est pas bon ?

      Pour les jours ok, j'aurais du prendre l'exemple dans le commentaire juste en dessous, qui contient donc

      subtype Day_Number   is Integer range 1 .. 31;
      

      Et pourtant, tous les mois n'ont pas 31 jours…

      Et pour l'explication de texte :

      De la même manière

      -> en reprenant le principe de typer plus finement

      on peut facilement faire des intervalles genre

      -> ce qui suit est un exemple d'intervalle

      mais t'aurais pu prendre un exemple un peu moins casse gueule

      Ou alors mon exemple portait surtout sur l'heure, le reste n'étant qu'un exemple d'intervalle et toi tu as juste pris la mouche ;-)

      Après je suis d'accord sur le fait que c'était simpliste, que les dates, les leap secondes et autre c'est casse gueule. Mais c'était juste un exemple pour présenter d'autres façon de typer.

      • [^] # Re: Mmmh

        Posté par . Évalué à 2.

        Ou alors mon exemple portait surtout sur l'heure,

        Tu as tout de même donné l'exemple des jours dans l'année.

        Je trouve ça remarque pertinente car oui ce principe est assez génial. Tu peut créer 2 types d'entiers qui sont identiques (représente le même ensemble d'entier), mais ne sont pas utilisables les uns avec les autres (il paraît que c'est l'un des grands cas d'usage qui a poussé ce langage : ne pas mélanger les unités).

        Mais il y a assez souvent des types plus complexe qu'un sous ensemble d'un type de base (qui possèdent des règles métier plus ou moins complexes) et à ce moment là c'est trucs là ne te servent à rien et trop s'appuyer (croire qu'on a codé les règles métier alors que ce n'est pas complètement le cas) est un piège à éviter.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Mmmh

          Posté par . Évalué à 4.

          Alors j'ai une remarque et une question.

          Ma remarque d'abord :

          Je trouve ça remarque pertinente

          "sa" (désolé mais ça me piquait les n'œils).

          La question ensuite :

          Bien que je sois d'accord sur l'utilité évidente d'établir des plages de valeurs pour un « même type » directement dans le langage, au final ça revient malgré tout à créer deux types différents et laisser le système de typage (fort) faire son boulot. En C++ on ferait sans doute ça en créant une interface avec template, quelque chose qui aurait une interface du genre:

          typedef Range<unsigned,0U,65535U> u16; // on pourrait sans doute faire sans le unsigned

          … Avec toutes les opérations de surcharges d'opérateurs qui vont bien œuf corse (qui peut être facilité grâce à l'utilisation de Boost). Au final le système de typage ferait aussi son boulot.

          Certes la syntaxe est peut-être moins sexy, mais le résultat (et surtout l'utilisation !) serait la même (une exception serait lancée si on tente d'affecter un nombre trop grand à un entier de type u16 par ex). Mon exemple montre même un cas qui serait sans doute résolu à la compil, comme en Ada.

          • [^] # Re: Mmmh

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

            Sauf que tu vas devoir te le faire ton template ainsi que les opérations qui vont bien avec, c'est justement tout ça que tu n'as pas à faire en Ada et c'est le compilateur qui te génère les opérations de base et des assert qui vont bien dans ton code que tu peux retirer une fois le code en prod si tu es vraiment sûr de toi.

            Certes la syntaxe est peut-être moins sexy, mais le résultat (et surtout l'utilisation !) serait la même (une exception serait lancée si on tente d'affecter un nombre trop grand à un entier de type u16 par ex). Mon exemple montre même un cas qui serait sans doute résolu à la compil, comme en Ada.

            La syntaxe n'est pas moins sexy, elle s'arrête à la définition du type, c'est tout !!
            D'ailleurs, il n'a jamais été dit qu'on ne pouvait pas faire la même chose dans les autres langages. La différence réside dans le fait qu'il faut les faire :)

            • [^] # Re: Mmmh

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

              Sauf que tu vas devoir te le faire ton template ainsi que les opérations qui vont bien avec

              Mais tu ne dois le faire qu'une fois. Ça ne me semble pas énorme comme boulot.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Mmmh

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

                C'est vrai, c'est pas énorme mais il ne faudra pas oublier de gérer le wrap around et tous les problèmes qui vont avec.
                Mais sinon, pour ceux-là, ça marchera aussi ?

                type Proportion is digits 4 range 0.0 .. 1.0;
                type day is Lundi, Mardi, Mercredi, Jeudi, Vendredi, Samedi, Dimanche;
                subtype jour_de_la_semaine is day range Lundi..Vendredi

                Sans compter que sur les types énumérés, on peut maintenant faire des prédicats pour constituer des ensembles disjoints (voir cette gemme)

                • [^] # Re: Mmmh

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

                  Je ne connais pas du tout Ada, alors je ne suis pas sûr mais les deux premiers me semble faisable. La troisième demande plus de connaissance des templates que ce que j'ai pour répondre.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Mmmh

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

                    Bon, j'ai trouvé ça et tu seras d'accord pour dire que c'est moins sexy :D
                    En tout cas, ça marche en C++ et ça ne me choque pas du tout.
                    La seule différence est que ce ne sera détecté qu'au runtime.

                    • [^] # Re: Mmmh

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

                      Je suis tout à fait d'accord pour dire que c'est moins sexy (mais il suffirait d'un peu de sucre syntaxique pour corriger ça).

                      La seule différence est que ce ne sera détecté qu'au runtime.

                      Oui, je pensais qu'il y avait moyen de le faire à la compilation mais je ne retrouve rien de tel, j'ai dû confondre.

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: Mmmh

                      Posté par . Évalué à 1.

                      Je ne comprends pas bien.

                      Soit je peux déterminer, à la compilation, la valeur d'une variable dont je veux limiter la plage de valeurs. Dans ce cas, je ne vois pas bien où est le souci (un peu de méta-programmation avec les templates permettra de régler le problème, un peu comme avec la solution d'utiliser les « static asserts » de Boost, Loki ou autres bibliothèques). Soit on ne connaît pas la valeur de la variable à la compilation, et oui bien entendu il faudra évaluer à l'exécution. Mais je ne vois pas en quoi ce serait différent avec Ada.

                      • [^] # Re: Mmmh

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

                        un peu de méta-programmation avec les templates permettra de régler le problème, un peu comme avec la solution d'utiliser les « static asserts » de Boost, Loki ou autres bibliothèques

                        Et bien, il est là le problème. On part d'une solution à base d'un template et on continue en rajoutant un soupçon de meta-programming pour obtenir les mêmes résultats.
                        Donc la déclaration d'un type en une ligne en Ada demande nettement plus de code en C++ mais encore une fois, je n'ai dit nulle part que c'était infaisable en C++.

                        Soit on ne connaît pas la valeur de la variable à la compilation, et oui bien entendu il faudra évaluer à l'exécution

                        Exact et le compilateur Ada ne dira effectivement rien.

                        • [^] # Re: Mmmh

                          Posté par . Évalué à 0.

                          Et bien, il est là le problème. On part d'une solution à base d'un template et on continue en rajoutant un soupçon de meta-programming pour obtenir les mêmes résultats.

                          Les concepts manipulés en ADA pour faire la même chose sont surtout nettement plus simples (et moins puissant).

                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                          • [^] # Re: Mmmh

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

                            Les concepts manipulés en ADA pour faire la même chose sont surtout nettement plus simples (et moins puissant).

                            Certes mais restons raisonnables. Là, on est en train de comparer la déclaration de type avec les templates. Si on parle de généricité alors parlons des generics en Ada.
                            Et effectivement, les generics Ada ne permettent pas la méta-programmation (voir wikipedia) et possèdent d'autres limitations que le C++ n'a pas.

                            Voilà, on n'aura donc pas réussi à éviter le troll des langages :-/

                            • [^] # Re: Mmmh

                              Posté par . Évalué à 2.

                              Pour moi c'était pas tant un troll, que d'essayer de pousser la logique et comprendre jusqu'où cette feature est utile. Mes questions, aussi enquiquinantes soient-elles, sont de vraies questions, et ne sont pas là pour faire de la provoc' pure et dure. :-)

                            • [^] # Re: Mmmh

                              Posté par . Évalué à 5.

                              Voilà, on n'aura donc pas réussi à éviter le troll des langages :-/

                              Ce n'est pas parce qu'on compare la manière d'implémenter quelque chose dans 2 langages différents que c'est du troll.

                              ADA possède des mécanismes pour répondre à ce besoin précis.
                              C++ possède des mécanismes qui entre autre permettent de faire ça (mais les template étant turing complet tu peut faire des tas d'autres choses avec comme faire planter ton compilateur¹).

                              ¹ : là c'est du troll :)

                              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                              • [^] # Re: Mmmh

                                Posté par (page perso) . Évalué à 6. Dernière modification le 27/06/13 à 10:43.

                                Ce n'est pas parce qu'on compare la manière d'implémenter quelque chose dans 2 langages différents que c'est du troll.

                                Sauf que dans un cas, c'est à toi de faire l'implémentation et dans l'autre pas.

                                C++ possède des mécanismes qui entre autre permettent de faire ça

                                Non, C++ possède des mécanismes qui permettent de l'implémenter soi-même, ce n'est pas la même chose.
                                Si on va dans ce sens, l'assembleur possède aussi les mécanismes qui permettent, entre autres, de le faire.

                        • [^] # Re: Mmmh

                          Posté par . Évalué à 3.

                          Et bien, il est là le problème. On part d'une solution à base d'un template et on continue en rajoutant un soupçon de meta-programming pour obtenir les mêmes résultats.

                          Oui, mais une fois que tu as codé ton truc avec des milliards de templates affreux, tu as sans doute une interface simple à utiliser (du genre de ce que je proposais). Et c'est écrit une fois pour toutes, et fonctionnera pour toutes les classes qui ont un comportement « prévisible » (i.e. qui implémentent les opérateurs de comparaison, affectation, etc., selon un mode de fonctionnement similaire aux opérations utilisables sur les types primitifs).

                          Note que je ne nie pas que le fait que ce soit intégré au langage soit une excellente chose; juste que à partir du moment où tu voudras utiliser des objets plus complexes, je ne suis pas certain que tu ne finiras pas, même en Ada, avec une solution usine à gaz potentiellement plus compliquée à mettre en œuvre que ma bête solution en C++.

                          Pour info, je me considère comme « moyen » en C++ pour le langage lui-même, et j'ai mis moins d'une heure¹ pour créer un template de classe qui vérifie dynamiquement les bornes; je sais comment faire la même chose statiquement en théorie, mais comme je pratique peu la méta-programmation, il est évident que ça me prendrait beaucoup plus de temps à correctement programmer. Ceci étant dit, programmer la fonctionnalité des plages dans un compilateur Ada n'est pas nécessairement moins compliquée, et dans les deux cas, l'utilisateur final n'a pas à regarder l'implémentation. ;-)

                          [1] Évidemment, l'implémentation est sans doute ultra trouée dès qu'on utilisera un type non primitif. Heureusement, le compilo gueulera très certainement… ;-)²
                          [2] Et aussi, je tends à réduire l'utilisation des templates au minimum vital. Je n'y ai recours que lorsque les gains vont clairement outrepasser la chiantitude à implémenter et déboguer l'implém.

                          • [^] # Re: Mmmh

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

                            Note que je ne nie pas que le fait que ce soit intégré au langage soit une excellente chose; juste que à partir du moment où tu voudras utiliser des objets plus complexes, je ne suis pas certain que tu ne finiras pas, même en Ada, avec une solution usine à gaz potentiellement plus compliquée à mettre en œuvre que ma bête solution en C++.

                            On est bien d'accord. Si le problème est compliqué, il y a peu de chances que sa solution soit très simple :)

                            Et aussi, je tends à réduire l'utilisation des templates au minimum vital. Je n'y ai recours que lorsque les gains vont clairement outrepasser la chiantitude à implémenter et déboguer l'implém.

                            Là aussi, je ne peux qu'aller dans ton sens parce que je ne garde pas que de bons souvenirs de mes templates C++ notamment sur le débogage :D
                            Mais comme le disait Michel, c'est ultra-puissant donc il n'y a pas de mystère, ça peut devenir compliqué.

                  • [^] # Re: Mmmh

                    Posté par . Évalué à 2.

                    Si je fais

                    typedef enum { Lundi, Mardi, Mercredi, Jeudi, Vendredi, Samedi, Dimanche } day;
                    Range<day,Lundi,Vendredi> work_week;

                    Je ne vois pas trop ce qui est gênant (contrairement au C, C++ n'acceptera pas qu'on substitue un int à un enum n'importe comment).

              • [^] # Re: Mmmh

                Posté par . Évalué à 2.

                Oui, j'aurais dû être plus précis, car c'était bien là que je voulais en venir.

  • # Exemple grâce à un ordinateur de vote ES&S iVotronic

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

    Pour illustrer l'intérêt de ce genre de vérifications, voici un cas réel vu sur un ordinateur de vote/machine à voter de type ES&S iVotronic, correspondant à l'heure et la date d'ouverture du scrutin : « Ouvert 65516:65525:65502 64800/01/1994 » (cf présentation à PSES2013).

  • # Que du bonheur (pour toi)

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

    Si tu as autant apprecié la déclaration des nouveaux types je pense que quand tu vas découvrir la gestion de la généricité, la gestion de variable partagée dans les threads (ainsi que les rendez-vous, …) et le reste, tu vas mouiller ton caleçon ;)

    • [^] # Re: Que du bonheur (pour toi)

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

      tu vas mouiller ton caleçon ;)

      J'en suis tout chose rien qu'à l'idée ;-)

      Ce qui est pas mal c'est que les personnes qui parlent d'Ada semblent tout de même plutôt contentes du langage et de ces possibilités.

      Mais par contre, pour vous, c'est quoi les points négatifs si on prend du ada 2005 ou 2012 ?

      • [^] # Re: Que du bonheur (pour toi)

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

        Alors la aucune idée… Pour moi l'ada ça reste juste le langage très chiant que je me suis tapé pendant presque 2 ans en école d'ingé ;)

        Sauf pour la programmation concurrente, la, ça dépote (et qu'on vienne pas me dire que en C ou en Java c'est mieux (de toute façon le Java, c'est pour les bisounours ))!

        • [^] # Re: Que du bonheur (pour toi)

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

          En quoi c'était très chiant ? (histoire de comprendre un peu)

          • [^] # Re: Que du bonheur (pour toi)

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

            Parce qu'on peut pas le hacker facilement :D
            En école d'ingé, on code et on voit après et du coup, c'est très lourd parce que le compilo n'arrête pas de brider la créativité du développeur.
            En vieillissant, on en a marre de corriger sans cesse les mêmes bugs cons et on préfère se poser pour réfléchir. L'impulsivité de la jeunesse contre la Sagesse quoi :D

  • # où faire de l'ada

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

    Une question un poil annexe, mais vu qu'il y a du monde qui semble en faire : où faire de l'ada (professionnellement j'entends) ? Une transition depuis du web/js/java ça se fait facilement ?

    (ben quoi, c'est que ça me semble intéressant, aussi bien le langage que, j'ai l'impression, l'envie de programmer proprement)

    • [^] # Re: où faire de l'ada

      Posté par . Évalué à 1.

      où faire de l'ada (professionnellement j'entends) ? Une transition depuis du web/js/java ça se fait facilement ?

      Il me semble que de manière générale, Ada est quand même pas mal cantonné à l’informatique embarquée.
      Ça risque de faire un sacré gap par rapport à Web/JS/Java.

      • [^] # Re: où faire de l'ada

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

        Ada est quand même pas mal cantonné à l’informatique embarquée.

        A part l'embarqué et le temps réel on ne l'utilise pas / peu ? Pourtant le langage pourrait vraiment être intéressant pour aider a faire de meilleurs softs, non ?

        Ça risque de faire un sacré gap par rapport à Web/JS/Java

        C'est probable… bon pendant un temps je faisais aussi du C++, c'était pas de l'embarqué non plus. (et après faut pas croire mais en java on peut aussi faire des gros trucs sympa, genre basé sur hadoop, du distribué, etc)

        • [^] # Re: où faire de l'ada

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

          A part l'embarqué et le temps réel on ne l'utilise pas / peu ? Pourtant le langage pourrait vraiment être intéressant pour aider a faire de meilleurs softs, non ?

          Ben ouais mais vas faire comprendre ça autour de toi et tu verras que c'est vraiment pas la mode.
          Pourtant on sait même faire du Web avec Ada, la preuve :D

          et après faut pas croire mais en java on peut aussi faire des gros trucs sympa, genre basé sur hadoop, du distribué, etc

          Oui mais ça non plus, c'est plus la mode. J'ai même entendu dire par un collègue :

          S'ils veulent se faire chier à faire un client en Swing, ça les regarde mais un portail avec des portlets, c'est quand même mieux

          • [^] # Re: où faire de l'ada

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

            Oui j'ai vu qu'il y avait AWS par exemple.

            Mais même pour le web, dans pas mal de cas il pourrait très bien y avoir des serveurs (de traitement) en Ada et les frontaux en ckonveut (java, ruby, js, etc)

            Mais c'est quand même triste de voir que "les gens" ne veulent pas vraiment la qualité, que ce n'est pas à la mode.
            Je me souviens un jour où j'ai proposé qu'on envisage la programmation par contrat dans du java (avec par exemple cofoja). La tête des autres développeurs, et surtout le « ça ne sert à rien » -_-'

            • [^] # Re: où faire de l'ada

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

              Mais c'est quand même triste de voir que "les gens" ne veulent pas vraiment la qualité, que ce n'est pas à la mode.

              La qualité, ça coûte toujours trop et on préfère privilégier le time to market à la qualité quitte à passer des lustres à fournir des patchs.
              Le probèleme en Ada, c'est que le développement est nécessairement plus long car il faut d'emblée se poser les bonnes questions plutôt que de hacker un truc vite fait.

        • [^] # Re: où faire de l'ada

          Posté par . Évalué à 1.

          A part l'embarqué et le temps réel on ne l'utilise pas / peu ?

          Bah disons que je l’ai très rarement vu ailleurs (pas jamais, mais très rarement). Mais bon ça ne reste que mon expérience personnelle.

          Pourtant le langage pourrait vraiment être intéressant pour aider a faire de meilleurs softs, non ?

          En théorie oui (bien que je ne pense pas que ça soit le langage miracle qui peut s’utiliser partout, mais dans un certain nombres de cas oui clairement).
          Mais bon, entre ce qui est très bien théoriquement et ce qui est très utilisé réellement, il y a un gouffre en général…

          (et après faut pas croire mais en java on peut aussi faire des gros trucs sympa, genre basé sur hadoop, du distribué, etc)

          Oui, je me doute.
          Ma remarque ne sous-entendais pas que ceux qui font du dev’ web/JS/Java sont des sous-dev et qu’ils font uniquement des trucs simples.
          Je voulais juste dire que les contraintes, exigences et problématiques rencontrées sont vraiment très différente.

    • [^] # Re: où faire de l'ada

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

      Une question un poil annexe, mais vu qu'il y a du monde qui semble en faire : où faire de l'ada (professionnellement j'entends) ?

      Dans le spatial, l'aéronautique, la défense, le transport majoritairement que ce soit chez l'éditeur de logiciels ou en SSII.
      Par exemple :
      - Sur LinkedIn en étant connecté :)
      - Directement sur les sites concernés comme MBDA ou Sagem Défense (certes, sur celle-là, on demande de l'expérience compte tenu du domaine mais si tu as de l'expérience en C, tu peux déjà postuler)

      Mais bon, il ne faut pas se leurrer, le langage n'est pas à la mode (cf. ce post) donc les offres de boulot ne sont pas légion.

      Une transition depuis du web/js/java ça se fait facilement ?

      Le gros problème risque d'être lié au fait que dans beaucoup de cas, on trouve Ada dans des systèmes temps réel et/ou critiques où les problématiques sont assez éloignées du développement Web. Dans ce cas, ce n'est pas le langage qui risque de poser problème mais plutôt son environnement.
      Par contre, la transition vers Ada en tant qu'apprentissage d'une nouvelle techno ne pose pas de problème.

      • [^] # Re: où faire de l'ada

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

        le langage n'est pas à la mode

        Ce qui peut aussi être un avantage pour ceux voulant en faire, non ?

        Dans ce cas, ce n'est pas le langage qui risque de poser problème mais plutôt son environnement.

        Ce qui s'apprend, non ? Sachant que j'ai une formation initiale plutôt orienté industrie que web (et en fait pas spécifiquement info)

        Par contre, la transition vers Ada en tant qu'apprentissage d'une nouvelle techno ne pose pas de problème.

        C'est déjà ça :-) Au pire ça me fera juste un langage de plus

    • [^] # Re: où faire de l'ada

      Posté par . Évalué à 2.

      l'anssi ils développent un kernel en ada

    • [^] # Re: où faire de l'ada

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

      Pas mal d'application qui nécessite une certaine robustesse (les trucs qui font bio-bip dans les hopitaux, les distributeurs de monnaie (j'ai vu une "raised PROGRAM_ERROR" sur un distributer de la poste (suisse)),…).

    • [^] # Re: où faire de l'ada

      Posté par . Évalué à 1.

      Je ne sais pas encore, mais dès que j'ai réussi à trouver pour moi je te dis ;)

      Comme ça a été mentionné, Ada est assez cantonné à des domaines particuliers (embarqué / temps réel / critique) qui peuvent demander de justifier du bon «background» et d'une expérience différente de celle nécessaire à du web.

Suivre le flux des commentaires

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