Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    février 2017
    Messages
    650
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 650
    Points : 22 654
    Points
    22 654

    Par défaut Programmation : un « Pony » peut cacher un langage

    Programmation : un « Pony » peut cacher un langage
    L’outil adéquat, d’avis d’utilisateurs, pour le développement d’applications concurrentes


    Décidément, les concepteurs de langages de programmation sont bien inspirés (ou pas du tout) lorsqu’il s’agit de les nommer. Quand ce n’est pas un nom inspiré de celui d'une troupe d'humouristes (Python), on pense à des objets précieux (Ruby). C’est connu, cet aspect est l’un de ceux où l’on voit de tout dans cette sphère. Les inspirations émanent de sources diverses et celle du langage Pony (rendu en français par poney – une espèce de cheval de petite taille) est pour le moins amusante.

    Nom : poney.jpg
Affichages : 5043
Taille : 176,4 Ko

    Dans la foire aux questions du projet, Sylvan Clebsch – le créateur du langage – explique qu’il tient le nom d’un banal échange avec un contributeur du projet. « Oui, moi je veux un poney », lui a envoyé ce dernier. Le créateur du langage venait de lui tendre une énième liste de fonctionnalités à implémenter. La formule était donc probablement destinée à faire entendre à Sylvan Clebsch qu’on ne peut pas toujours obtenir ce que l’on désire.

    Passé ce premier motif de commentaires à propos de ce langage de programmation, il faut souligner que Pony c’est aussi un choix de design qui divise. Généralement, les cas de division par zéro génèrent des exceptions, mais l’équipe derrière le langage de programmation a décidé qu’une variable reçoit zéro comme résultat lorsque cette situation se présente. La manœuvre est destinée à contourner une limitation du compilateur de l’actuelle version du langage (ponyc v0.2).

    Qu’a donc ce poney dans le ventre ?

    Pony est le principal langage utilisé par les créateurs du framework Wallaroo – un moteur de traitement de données « élastique » et rapide pour emprunter au vocabulaire des têtes derrière l’outil. Dans un billet de blog paru au mois de mai, l’un des auteurs du framework (par ailleurs contributeur du projet Pony) explique ce choix. « Développer des applications concurrentes rapides, efficientes et sécurisées n’est pas évident avec les outils existants. Rapide, efficient et hautement concurrent est un objectif atteignable, mais ajoutez-y la contrainte sécurité et les choses se compliquent. Avec Wallaroo, nous avions besoin de réunir ces quatre aspects et Pony a grandement facilité l’atteinte de cet objectif », a-t-il souligné.

    « Pony pourrait être la solution adéquate si vous avez un difficile problème de concurrence à résoudre. Les applications concurrentes sont la raison d’être de ce langage. Si vous êtes capable d’atteindre votre objectif à l’aide d’un script python monothread alors vous n’avez pas besoin de Pony. […] En faisant usage de Pony, vous bénéficiez d’un compilateur qui vous évite d’introduire des bogues d’accès concurrent et d’un environnement d’exécution qui contribue à l’obtention d’excellentes performances », a-t-il ajouté.

    Les développeurs qui ont flirté avec Rust et Erlang retomberont très certainement sur leurs pattes avec célérité puisque les concepteurs du langage le décrivent comme une rencontre des deux mondes. Illustration avec une portion de code dédiée à l’analyse de paramètres passés par le biais de la ligne de commande.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    use "cli"
    
    actor Main
      new create(env: Env) =>
        let command_spec = 
          try
            CommandSpec.leaf(
              "pony-embed",
              "sample program", 
              [ OptionSpec.string("output", "output filename", 'o') ],
              [ ArgSpec.string("input", "source of input" where default' = "-") ]
            )? .> add_help()?
          else
            env.exitcode(1)
            return
          end
        let command = 
          match CommandParser(command_spec).parse(env.args, env.vars())
          | let c: Command => c
          | let ch: CommandHelp =>
            ch.print_help(env.out)
            env.exitcode(0)
            return
          | let se: SyntaxError =>
            env.err.print(se.string())
            env.exitcode(1)
            return
          end
        let input_source = command.arg("input").string()
        let output_filename = command.option("output").string()
        env.out.print("Loading data from " + input_source + ". Writing output to " + output_filename)
        // ...
    Le développement du langage se fait dans la sphère de l’ouvert. Les contenus du projet sont publiés sous licence BSD. Plus de détails sur la page du projet pour les développeurs désireux d’aller plus en avant.

    Sources : page du projet, opensource.com

    Et vous ?

    Que pensez-vous du choix du nom de ce langage ?

    Dans l’histoire des langages de programmation quels sont ceux dont les noms vous ont le plus marqué ? Pour quelles raisons ?

    Êtes-vous sur un projet de langage de programmation ? Si oui, quel nom avez-vous retenu ? Pour quelle raison ?

    Quel commentaire faites-vous du choix de design relatif à la gestion des cas de division par zéro ? Quel autre langage fonctionne sur le même schéma ? En quoi un tel choix peut-il être utile ?

    Avez-vous testé ce langage ? Si oui, quel retour pouvez- vous en termes de comparaison par rapport à l'existant dans le cadre de la programmation concurrente ?

    Voir aussi :

    C2 : un langage qui se présente comme une évolution de C, plus rapide, sans fichiers d'en-tête, avec système de build intégré et d'autres changements

    Microsoft crée un nouveau langage de programmation dédié aux ordinateurs quantiques qui devrait être officialisé d'ici la fin d'année

    Quel langage de programmation pour le calcul scientifique en 2018 ? Quelles caractéristiques vous paraissent-elles les plus importantes ?

    Quelle est la probabilité de passer d'un langage de programmation donné à un autre ? Des prédictions basées sur une étude empirique

    Ritchie : un nouveau langage de programmation dérivé de C qui veut combiner la facilité de Python et la vitesse de C
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 801
    Points : 3 513
    Points
    3 513

    Par défaut

    Dans la page Pony Tutorial, je viens de lire les pages Exceptions et Divide by Zero et j'en ai conclu que la conception du langage était fondamentalement foireuse concernant la gestion des erreurs.

    Rappel théorique :
    Dans un langage statiquement typé, parmi les fonctions, on distingue les fonctions totales qui peuvent être appelées avec n'importe quels arguments, tant qu'ils sont du bon type, et les fonctions partielles dont les arguments en entrée ont des restrictions plus fortes que leurs types. Par exemple, une fonction qui prend en paramètre un vecteur et qui retourne le nombre d'éléments est une fonction totale, parce qu'on peut l'appeler avec n'importe quel vecteur. Par contre, une fonction qui retourne le premier élément d'un vecteur est une fonction partielle, parce qu'elle n'a pas de sens pour un vecteur vide.

    Pour résumer ce que dit la page Exception, en Pony, on a une structure de contrôle try-else telle que, dans la partie try, si on appelle une fonction partielle avec un argument qu'elle ne devrait pas recevoir, alors le flot de contrôle continue dans le else. En outre, en Pony, les fonctions partielles doivent être marquées d'un point d'interrogation. Jusque là, tout va bien.

    Là où ça devient problématique, c'est que, en Pony, pour qu'on ait le droit de définir une fonction comme totale (en ne la marquant pas d'un point d'interrogation), il faut que le compilateur puisse prouver qu'elle est totale. Mais, quand le compilateur n'arrive pas à le prouver, visiblement, la solution choisie par Pony, c'est de cacher la poussière sous le tapis. Par exemple, quand on divise un nombre par un autre avec l'assurance que le diviseur est non nul, que faire si le compilateur n'arrive pas à vérifier que le diviseur est non nul ? Eh bien on va dire que, quand le diviseur est nul, on retourne zéro. Comme ça, le jour où l'on divisera par zéro par mégarde dans un bout de code pas assez couvert par des tests unitaires, au lieu d'avoir un message d'erreur, le programme fera semblant de marcher et, le jour où l'utilisateur se rendra compte qu'il y a un problème, on perdra un maximum de temps en maintenance pour trouver d'où venait le problème.

    De manière générale, pour écrire rapidement du code robuste, on a besoin à la fois du typage statique et de la programmation par contrats (présence de préconditions, postconditions et invariants). Essayer de prouver que les contrats sont respectés lors d'une analyse statique de code, c'est très bien. Mais, quand les outils ne sont pas assez puissants pour vérifier le respect de tous les contrats, la bonne solution n'est pas de retirer les contrats pour lesquels les outils n'arrivent pas encore à prouver qu'ils sont respectés. Étendre n'importe comment des fonctions partielles en fonctions totales diminue la robustesse du code.

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    169
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 169
    Points : 408
    Points
    408

    Par défaut

    La gestion d'erreur n'est pas foireuse, elle est assez différente de ce qui se fait ailleurs. Je ne sais pas pourquoi les gens se focalise sur la division par 0. De mon expérience ce n'est pas qui arrive souvent (les overflows/underflow non voulues sont souvent plus fréquent, bien que pas géré non plus par Pony). Pour le cas de la division par zéro ce n'est pas difficile de créer une alternative qui prend en compte le cas par du 0 au dénominateur. Ce choix a été fait en étant conscient du fait que devoir gérer les cas problématique à chaque division diminue fortement l'ergonomie du langage. Ensuite pour les propriétés qui ne peuvent pas être prouvés à la compilation Pony dispose d' assert et de fact. Et pour finir, tu pas être plus dans le faux en disant que la philosophie de Pony est de faire des "hacks" pour les propriétés qui ne peuvent pas être prouvés lors de la compilation. Le système de type de Pony (qui n'est pas trivial à comprendre) vient du monde académique suite à des recherches de chercheur en informatique. De plus, il permet de garantir des propriétés concernant la mutabilité, l'aliasing et l'accès concurrent des structures de données rien qu'a la compilation, ce qui n'est clairement pas le cas de la plupart des langages.

  4. #4
    Membre averti
    Homme Profil pro
    Programmeur du dimanche
    Inscrit en
    août 2017
    Messages
    136
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Programmeur du dimanche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2017
    Messages : 136
    Points : 449
    Points
    449

    Par défaut

    Par contre faut changer le nom du langage...

  5. #5
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 801
    Points : 3 513
    Points
    3 513

    Par défaut

    Citation Envoyé par codec_abc Voir le message
    Pour le cas de la division par zéro ce n'est pas difficile de créer une alternative qui prend en compte le cas par du 0 au dénominateur. Ce choix a été fait en étant conscient du fait que devoir gérer les cas problématique à chaque division diminue fortement l'ergonomie du langage.
    C'est justement le problème. Idéalement, cela n'aurait pas dû diminuer fortement l'ergonomie du langage.

    Citation Envoyé par codec_abc Voir le message
    Ensuite pour les propriétés qui ne peuvent pas être prouvés à la compilation Pony dispose d' assert et de fact.
    Je vois qu'il s'agit de fonctions partielles qui écrivent dans la sortie d'erreur quand la condition est fausse. On peut s'en contenter lors de la phase de test, mais ce n'est pas satisfaisant en production.

    Dans beaucoup d'autres langages, le code appelé propage au code appelant une erreur et c'est le code de haut niveau qui décide quoi faire de cette erreur, par exemple écrire dans un fichier de log dans un format déterminé, avertir l'utilisateur qu'un problème s'est produit et, dans le cas où l'erreur détectée est une erreur de programmation, demander à l'utilisateur d'envoyer le fichier de log à l'équipe de développeurs pour les aider à corriger le bogue.

    De manière générale, pour la réutilisabilité du code, il faudrait découpler la détection de l'erreur du traitement de l'erreur.

    Citation Envoyé par codec_abc Voir le message
    De plus, il permet de garantir des propriétés concernant la mutabilité, l'aliasing et l'accès concurrent des structures de données rien qu'a la compilation, ce qui n'est clairement pas le cas de la plupart des langages.
    Tant mieux pour lui. Plus il empêche d'erreurs de programmation à la compilation, mieux c'est.

  6. #6
    Membre averti
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    169
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 169
    Points : 408
    Points
    408

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    C'est justement le problème. Idéalement, cela n'aurait pas dû diminuer fortement l'ergonomie du langage.
    Ca n'a pas de sens. Soit tu tiens compte des potentiels erreur et tu forces le développeur a dire ce qui doit se passer quand on divise par 0, soit tu choisis une alternative pour lui pour. Aussi tu peux faire plusieurs opérateurs: des exactes qui te forcent à gérer les erreurs et d'autres qui "trichent" un peu dans les cas limites. Après en C# par exemple on a des exceptions, mais niveau robustesse c'est pas nécessairement mieux car on ne sait pas dans quelle situations elles sont levées (Faut lire la doc pour ça et des fois on n'y pense pas) et rien ne force à les gérer. De plus, en C# on n'a pas de séparation claire entre les bugs et les problèmes qui peuvent survenir au runtime que le développeur aurait pu gérer (les 2 se traduisent par des exceptions).

    Toujours en C# (J'insiste sur le C# car c'est le langage que j'utilise au boulot, mais j'ai rien contre lui)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    uint x = 150;
    uint y = 300;       
    uint z = x - y;   
    Console.WriteLine("z = " + z);
    Ce code affiche "z = 4294967146" alors que ce n'est clairement pas correct d'un point de vue mathématique. Paradoxalement, une division par 0 lance une exception. On pourrait crier au scandale en disant que ça manque de cohérence. Bref, l'exactitude des fonctions mathématiques de base dans un langage de programmation n'est pas un sujet simple, ni binaire. Et la plupart des langages font l'impasse sur l'exactitude mathématique dans une certaine mesure au profit d'une meilleure ergonomie (et productivité par la même occasion) et Pony n'échappe pas à la règle.

  7. #7
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    801
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 801
    Points : 3 513
    Points
    3 513

    Par défaut

    En ce moment, j'étudie le langage D, dont toutes les exceptions dérivent de Throwable. Cette classe possède deux classes dérivées directes :
    • Error, qui représente une erreur de programmation ou un manque de mémoire et
    • Exception, qui représente une erreur « récupérable ».


    Les échecs d'assertion représentent des erreurs de programmation. Le comportement dépend alors du compilateur et des options de compilation. Si on décide de lancer une exception en cas d'échec d'assertion, alors c'est AssertError qui dérive de Error.

    Parmi les attributs des fonctions du langage D, nothrow indique que la fonction ne peut lancer que des exceptions qui dérivent de Error. Cette propriété est vérifiée à la compilation.
    De mon point de vue, c'est une bonne chose qu'on puisse lancer un AssertError depuis une fonction nothrow. Sinon, on ne pourrait utiliser nothrow presque nulle part sans saboter la gestion des erreurs, car le compilateur n'arrivera pas à prouver que toutes les assertions réussiront.

    Je pense que Poney aurait dû mettre en place un contrôle similaire. Sinon, de ce que j'ai compris, en Poney, un simple changement d'implémentation peut transformer une fonction totale en une fonction jugée à tort comme partielle par le compilateur, ce qui oblige soit à détériorer localement la gestion des erreurs, soit à transformer récursivement toutes les fonctions appelantes totales en fonctions partielles en leur ajoutant un point d'interrogation chacune.

    En C++, on est supposé pouvoir distinguer les erreurs de programmation des autres erreurs. En effet, les exceptions qui représentent des erreurs de programmation sont supposées dériver de std::logic_error, mais certaines bibliothèques ne respectent pas cette règle et inventent leurs propres hiérarchies d'exceptions sans qu'elles ne dérivent des exceptions de la bibliothèque standard.
    En C++, pour les exceptions, il n'y a malheureusement pas de contrôle à la compilation comme l'attribut nothrow du langage D. Il existe bien un mot-clef nothrow en C++, mais avec un sens différent.

    Je n'ai pas étudié C#.
    Pour ton exemple avec la soustraction d'entiers non signés, on a le même problème en C++.
    En D, dans la bibliothèque standard, il existe un module std.experimental.checkedint qui permet, entre autres, de personnaliser le comportement en cas d'underflow et d'overflow, mais je ne l'ai pas encore testé.

  8. #8
    Membre averti
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    169
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 169
    Points : 408
    Points
    408

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    Je pense que Poney aurait dû mettre en place un contrôle similaire. Sinon, de ce que j'ai compris, en Poney, un simple changement d'implémentation peut transformer une fonction totale en une fonction jugée à tort comme partielle par le compilateur, ce qui oblige soit à détériorer localement la gestion des erreurs, soit à transformer récursivement toutes les fonctions appelantes totales en fonctions partielles en leur ajoutant un point d'interrogation chacune.
    Oui c'est voulu. En Pony (et pas Poney) le fait qu'une fonction puisse échouer fait partie de sa signature. En pratique je trouve ça mieux. Déjà ça permet de savoir dès le début les fonctions qui peuvent échouer et donc de réfléchir en amont à la gestion d'erreur, la ou dans d'autre langage on s'en rend compte assez tard alors que ça peut remettre l'architecture en cause. Aussi, c'est rare qu'une fonction totale devienne une fonction partielle si elle garde les mêmes fonctionnalité.

  9. #9
    Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    novembre 2017
    Messages
    22
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 21
    Localisation : France, Charente (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2017
    Messages : 22
    Points : 66
    Points
    66

    Par défaut

    Moi ce que j'aimerais savoir c'est :

    Pourquoi est-ce que quand on présente un langage de programmation on montre un code aussi mal formaté ? Sérieusement, quand je vois du code écris de cette manière j'ai juste envie d'éviter le langage, alors que je ne le connais même pas. Heureusement que je fais abstraction de ces choses la maintenant, mais il y a un minimum. Toutes les lignes sont collés et très courtes, sa en devient presque illisible...

    Sinon personnellement je ne m'avancerais sur rien, on a mis en avant pleins de langages ces dernières années, qui étaient censé être des révolutions, bien qu'utilisé ils ne sont qu'une réponse de plus à d'ancien et/ou nouveaux problème. Attendons de voir la suite.

Discussions similaires

  1. Réponses: 33
    Dernier message: 12/10/2017, 18h24
  2. Réponses: 18
    Dernier message: 20/10/2011, 13h41
  3. Réponses: 3
    Dernier message: 23/05/2011, 15h05
  4. Programme qui ne peut pas s'installer
    Par JeanMarc_T2k dans le forum Windows XP
    Réponses: 6
    Dernier message: 03/12/2009, 19h45
  5. Réponses: 4
    Dernier message: 16/01/2003, 15h42

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo