IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Patrick Ruiz

134PARTAGES

10  0 
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.


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
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 02/06/2018 à 15:19
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.
5  1 
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 02/06/2018 à 22:37
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.
1  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 03/06/2018 à 0:25
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.
1  0 
Avatar de Jamatronic
Membre éprouvé https://www.developpez.com
Le 03/06/2018 à 0:09
Par contre faut changer le nom du langage...
2  2 
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 03/06/2018 à 1:07
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
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.
0  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 03/06/2018 à 2:09
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é.
0  0 
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 03/06/2018 à 13:45
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é.
0  0 
Avatar de KnifeOnlyI
Membre régulier https://www.developpez.com
Le 04/06/2018 à 8:47
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.
2  2