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
euh... je confirme ce que j'ai dit....
Je suis allé sur le site d'anubis, consulter "la" référence du site, www.crp-patrimoine.com, le site web issu d'Anubis avec soit disant 1 000 000 de lignes de code....
Allez-y, la plupart des pages ne fonctionnent pas... et en plus, on a l'impression que le site date de 10 ans...
CA ne fait vraiment pas très sérieux comme référence pour un produit qui veut convaincre
Nemerle, mathématicopilier de bars, membre du triumvirat du CSTM, 3/4 centre
Bonjour Nemerle,
Je réponds sur la remarque concernant le cite crp-patrimoine.com (je suis celui qui a développé ce projet). Il y a du vrai, mais il y a surtout une vision très partielle de ce qu'est en fait ce travail.
Le vrai, c'est ce qui est dit sur l'aspect graphique : je ne suis pas graphiste. La conception date d'un peu plus de 6 ans, et n'a guère été retouchée depuis. Ce qui explique les impasses rencontrées. Mais je pense quand même que la plupart des pages sont encore accessibles.
De toute façon, ces 2 points ne concernent pas vraiment Anubis : l'aspect graphique relève plus d'une compétence "artistique"; quant aux liens menant nulle part, c'est plutôt la conséquence d'un choix de priorités au sein de l'entreprise où le développement du système est ailleurs (cf ci-dessous). Merci quand même pour l'info : je corrigerai cela la semaine prochaine.
La vision partielle est que ce que tu as vu (plus généralement ce que nous appelons le "site publique") n'est que la partie visible d'un ensemble beaucoup plus vaste. Et cette partie visible ne fait plus l'objet d'un développement et est seulement maintenue tant bien que mal en l'état.
Désormais, l'essentiel du travail (depuis au moins 3 ans) n'est pas accessible par le public, mais seulement via 2 sites privés sécurisés selon la qualité de la personne qui se connecte. Ce sont ces 2 parties du système informatique qui sont l'objet de toute notre attention et qui sont toujours développés.
Par exemple, l'une de ces parties privées est, en autres, consacrée à la gestion de l'ensemble des tables utilisées dans le système, à la facturation (toutes les factures émises sont enregistrées dans le système avec sortie PDF via LateX), ....
J'admets donc volontiers qu'à la seule vue de la partie publique, le doute s'installe à lire que ce projet contient 1 000 000 (environ 750 000 pour mon seul travail, le solde en diverses librairies publiques) de lignes de code Anubis. Mais c'est bien la réalité d'aujourd'hui, pour l'ensemble du système informatique développé.
Enfin, quelques considérations quant à ma pratique d'Anubis. Si désormais je fais de la programmation à temps plein (en Anubis), je ne suis pas du tout informaticien de formation. Je suis venu à la programmation avec la décision de mettre ce projet crp-patrimoine en place. Ce qui a fait de moi le premier utilisateur d'Anubis (après son créateur, bien entendu). Aurais-je pu écrire ces 750 000 de lignes de code en un autre système qu'Anubis ? Pas sûr. Anubis est très structurant, paliant au début mon inexpérience de la programmation, et la très grande qualité du compilateur qui en évitant les bugs formels (pas ceux d'intention) m'ont permis d'amener ce projet là où il en aujourd'hui.
Un exemple. J'ai pu avoir besoin, parce que les optiques changent, de modifier l'enregistrement de données d'un type ayant 2 alternatives, avec 16 composants pour l'une, 21 pour l'autre, pour passer un nouveau type d'un seule alternative, avec 25 composants (avec reprise partielle ou transformation des types des composants). Si ce genre de modification nécessite du temps, je les ai toujours faite dans la plus grande confiance et sans aucun doute sur le résultat final, à savoir qu'une fois les corrections apportées là où ce type modifié était utilisé, du premier coups, tout le système informatique restait cohérent, et sans perte de données. J'ai fait ce genre de manipulation bien des fois.
Ne connaissant comme langage de programmation uniquement Anubis, je ne suis pas qualifié pour effectuer des comparaisons avec d'autres langages. Je retiens quand même qu'il a permis au néophyte que j'étais en matière de programmation de mener ce projet à bien et de continuer à le développer (et grand merci à A. Prouté - le créateur d'Anubis- pour les très nombreuses explications et enseignements qu'il m'a apporté). J'ajoute que je travaille aujourd'hui, à mes heures perdues (?), sur un autre projet également en Anubis à vocation industrielle dont l'un des commanditaires (non informaticien de profession) s'est très bien mis à programmer en Anubis, retrouvant les qualités et la sûreté nécessaire pour mener cet autre projet (en très bonne voie) à sa phase de commercialisation.
J'espère que ces quelques éclaircissements te permettront de nuancer ton premier jugement.
Envoyé par foulques
Au moins Anubis fait preuve d'un certaine cohérence. Il a été conçu par quelqu'un qui ne connait pas les autres langages de programmation, et ne convainc que les gens n'ayant jamais programmé. Et dans les deux cas, ils arrivent à vanter les gains du langage par rapport à ce qu'ils ne connaissent pas. Je cite par exemple le site d'anubis :
Pour se lancer dans un projet "à vocation industrielle", en se basant sur un langage développé par une seule personne, entre le fromage et le dessert, et n'étant utilisé par personne, il faut soit en avoir une paire grosse comme ça, soit avoir oublié de faire un minimum d'évaluation des risques.
Et finalement, pour le million de lignes de code, j'aimerais bien savoir comment elles ont été compté. Parce que si c'est av un "wc -l", vu que la déclaration "classique" d'une fonction c'est
contre un
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7define List($U) map ( $T -> $U f, List($T) l ) =
dans d'autres langage, on se dit que ce n'est pas forcément bien difficile de faire tourner le compteur à ligne...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
1.000.000 LOC ???
Le Kernel Linux actuel n'en a même pas 2 fois plus et en avait 5 fois moins à sa version 2.0...
Et précisons que le Kernel comprend des milliers de pilotes en plus de son coeur lui-même. D'autant qu'il a été écrit en C (et du C sans fantaisie en plus (on est en espace noyau), bien que de qualité), pas en un quelconque langage de haut-niveau ! Et par des centaines (milliers occasionnels) de contributeurs.
Sachant qu'en Haskell, un gestionnaire de fenêtre complet et puissant comme xmonad ne prend pas plus de 500 LOC, je me pose la question, qu'est-ce que ces 1.000.000 LOC (dont 750.000 écrites par le seul foulques) représente ? Pour l'instant je préfère penser qu'il s'agit d'un chiffre "en l'air" lancé pour nous impressionner et c'est tout, sinon il me faudrait envisager que :
- soit foulques a écrit une IA forte sous couvert d'activité industrielle légitime, j'avertis la DGSE.
- soit foulques est vraiment mauvais et écris une quantité de code parfaitement inutile.
- soit Anubis est encore plus verbeux que Java bien qu'il soit fonctionnel.
(évidemment il y a aussi la possibilité que les 9/10e de ce compte soit de la ressource et pas du vrai code et que le reste soit du copier-coller-modifier de 1000 LOC)
--
Jedaï
Anubis est très verbeux. Rien que la déclaration d'une fonction prend plusieurs lignes en général (si on suit la coding-style que j'ai vue le plus souvent). Pour un langage fonctionnel, c'est vraiment dommage ! La gestion des erreurs et l'absence d'exceptions alourdissent probablement le code. De ce que j'ai vu, c'est encore plus verbeux que Java (c'est dire !).
De plus, Anubis étant jeune et n'ayant que peu d'utilisateurs, j'imagine que le nombre de bibliothèque est très restreint. Pour rapport à Java, ça doit jouer beaucoup.
En effet. En utilisant Haskell, Ruby, Caml, F#, Python... je suis persuadé que tu aurais eu beaucoup moins de lignes à écrire. Par exemple, je ne serais pas surpris si ça divisait le nombre de lignes par au moins 5 ou 10.Aurais-je pu écrire ces 750 000 de lignes de code en un autre système qu'Anubis ? Pas sûr.
Et 750 000 lignes de code en 3 ans, pour une personne, ça fait beaucoup... Du copier-coller ?
Il serait intéressant de voir du code Anubis dans les défis fonctionnels (à quand le prochain défi, d'ailleurs ?). Ca permettrait de mieux comparer le langage (vu que les utilisateurs d'Anubis ne connaissent pas ou peu les autres langages fonctionnels).
Bonjour à tous.
@jedai et LLB: je précise, car effectivement, ça n'a pas été dit, que les 700 000 lignes écrites par Foulques sont mesurées à la louche. Elle comprennent tout y compris les commentaires et les lignes blanches. Pour évaluer le volume du code, il vaudait mieux mesurer la taille du fichier .adm produit par le compilateur. Foulques, nous la donnera sans doute.
Ensuite, ne comparons pas ce qui n'est pas comparable, c'est à dire un système d'exploitation et un logiciel de gestion de patrimoine. Quant à savoir si c'est de l'IA forte, je rassure jedai tout de suite: on en est très loin, ce n'est même pas de l'IA faible. C'est juste des routines en lien avec le métier, mais il y en a un très grand nombre, dû au fait qu'il existe un très grand nombre de contrats d'assurance, d'OPCVM, etc... Par ailleurs, je précise que Foulques ne fait que coder, la conception étant faite par son patron.
Effectivement, Anubis est verbeux (plus ou moins à vrai dire, mais on m'a déjà fait la remarque). Mais je précise que c'est intentionnel, car mon but était de rendre les textes facilement lisibles. Un texte moins verbeux oblige tout simplement à deviner ce qui n'est pas écrit. Mon expérience de l'écriture des maths et de l'enseignement (plus de 30 ans maintenant) m'a appris qu'il valait mieux pour être compris être explicite, quitte effectivement à être parfois 'verbeux'. C'est donc délibéré, et ça ne changera pas. Lisez une démonstration mathématique dans un livre, vous verrez que c'est plus verbeux que du Haskell, et à mon avis heureusement (pauvres étudiants !).
Maintenant, pour ce qui est de lancer un défi fonctionnel, j'y pensais justement ce matin (télépathie ? ), et je m'apprêtais à envoyer à jedai un mp pour lui demander l'autorisation. Je propose de révéler sous forme d'une série d'exercices, l'extension du système de type d'un langage fonctionel qui permet l'écriture des énoncés et des preuves, que j'ai imaginée d'après mon étude des topos, et que j'ai prévu d'inclure dans Anubis 2. Autant que je sache c'est plutôt original comme approche, et cela devait vous intéresser. Jusqu'à présent, je suis resté très vague sur ces question. Ce sera donc la première fois que les détails seront donnés. Je pense qu'il est temps tout simplement.
Comprenez aussi une chose. Je suis parfaitement conscient des faiblesses d'Anubis 1. Je travaille depuis longtemps maintenant sur Anubis 2, qui s'avère être assez différent d'Anubis 1 à cause des contraintes imposées par la théorie. J'en ai un peu assez d'entendre parler d'Anubis 1, qu'on aura vite oublié quand Anubis 2 sera connu. Aussi, ce défi sera aussi pour moi l'occasion de mettre les points sur les i, et de montrer que les problèmes évoqués à propos d'Anubis 1 sont déjà loin de mes préoccupations.
Cordialement, et merci à tous pour l'intérêt que vous portez à mon travail, et aussi pour les critiques que je reçois le plus souvent comme très constructives.
Je crois que vous (alex_pi, jedai, LLB) passez à côté de la question, ce qui est dit c'est que l'on peut débuter la programmation avec Anubis et s'en sortir avec relativement peu d'assistance. Est-ce que c'est dû au nombre restreint des constructions disponibles ? À une introduction relativement douce à la programmation fonctionnelle ? À une syntaxe plus proche de C et Java que de Lisp et ML ?
Qu'importe, le fait est que des débutants sont entrés seuls dans le monde de la programmation fonctionnelle. Si on compare aux langages plus établis qui bénéficient du soutien académique, d'une large documentation en français et en anglais, qui font l'objet de cours dans l'enseignement supérieur, qui ont le soutien direct ou indirect de Microsoft, et qui rapporté à tous ces avantages connaissent encore trop peu de succès industriels, alors on peu dire qu'Anubis débute plutôt bien.
La verbosité n'est pas un vrai critère, Eiffel est un très bon langage de programmation par classes qui a connu un énorme succès d'estime, hé bien Eiffel est beaucoup plus verbeux qu'Anubis, d'ailleurs ses qualités résident dans ce que l'on écrit en "plus" (ou en "trop" selon le point de vue).
C'est enthousiasmant, enfin un exercice avec un véritable enjeu
J'ai moi-même fais une proposition de défi fonctionnel mais je vous cèderais bien volontiers la priorité si la vôtre était acceptée (il serait vraiment dommageable pour developpez.net qu'elle ne le soit pas).
Du même auteur: mon projet, le dernier article publié, le blog dvp et le jeu vidéo.
Avant de poser une question je lis les règles du forum.
Ce point-là mériterait un débat à lui seul. Par opposition, Sed et Perl ont bâti leur succès sur leur concision. La concision, c'est l'expressivité. Et presque tous les langages cherchent à être plus expressifs. Le principal intérêt des langages de programmation est de réduire le temps de travail (temps d'écriture, temps de lecture) pour arriver au résultat. Des études ont d'ailleurs montré que le nombre de lignes par heure était le même, indépendamment de la brièveté du langage. Elles se sont reposées sur des exemples, et même si tu peux facilement imaginer quelques contre-exemples, elles montrent la tendance générale, sur des cas concrets.
Je vais éviter de faire une réponse trop longue, et je vous renvoie à l'argumentation de Paul Graham.
Pour le défi, je suis aussi très intéressé. Il faut faire attention lors de l'écriture de l'énoncé ; l'idéal étant de demander un programme (plutôt qu'une fonction) et de comparer les sorties (stdout) en jouant juste sur l'entrée (stdin / argv / fichier).
La comparaison me semble mal interprétée : dans une démonstration mathématique normale (pas désigné à l'enseignement), une grande part de la démonstration tient dans les passages symboliques, analogue du code, les explications qui entourent ces passages me semble plutôt l'analogue de commentaires(/documentation, l'idéal étant un système qui couple les deux comme tous les langages modernes en ont, est-ce le cas d'Anubis ?).
Je préfère un langage qui m'offre une expressivité maximale que je peux commenter à un langage qui m'oblige à en étaler des tartines même si la fonction est parfaitement triviale
Pour le reste de mes commentaires, voir l'argumentaire de Graham (un point important me semble être que la brièveté offre une meilleure vision générale de la structure d'un programme et favorise donc les refactorisations et les abstractions).
--
Jedaï
Je reviens sur une question: qu'est-ce qui me ferait pencher pour Anubis plutôt que les dernieres évolutions de la plateforme .net (par exemple Linq)? Sur des projets "couteux" il y a à convaincre la DSI de l'intérêt, et surtout du confinement des risques...
Nemerle, mathématicopilier de bars, membre du triumvirat du CSTM, 3/4 centre
Effectivement, dans une démonstration mathématique, il y a ce mélange entre le texte (verbeux par essence) et les formules (concises par nécessité). Et donc on a les deux: le verbeux et le non verbeux. J'ai ma théorie (elle n'est pas qu'à moi, bien sûr) sur la cause de cette dualité. Elle est une conséquence du principe d'indiscernabilité des preuves. Ce principe est patent dans toutes les mathématiques (je me suis longuement exprimé sur ce sujet ici). Il dit que deux preuves d'un même énoncé sont égales. Du coup, quand on écrit une preuve, qui est une sorte de programme, ce n'est pas la preuve qui compte, mais seulement le fait qu'on se soit bien assuré qu'on pouvait en écrire une, peu importe laquelle. Dès lors, l'écriture des preuves peut se permettre d'être largement imprécise, et même incomplète, du moment que le lecteur peut réconstituer au moins une preuve. La langue naturelle est mieux à même de supporter cette façon d'écrire que les formules mathématiques. Par contre, de temps en temps, on a besoin de parler d'objets mathématiques autres que des preuves, et là, on a besoin d'être complètement explicite. Les formules concises sont alors, bien évidemment mieux adaptées que les périphrases qui peuvent noyer le poisson. (Note: les démonstrations destinées à l'enseignement sont en général des démonstrations 'normales'. Je ne vois pas très bien ce que tu as voulu dire avec cette remarque.)
Maintenant, le fait de savoir si les preuves sont des commentaires est encore autre chose. D'une certaine façon, oui. J'espère avoir l'occasion de reparler de cela.
Pour ce qui est d'Anubis 2, et surtout d'une surcouche au dessus d'Anubis 2, destinée à donner un aspect plus mathématique au texte, qui est également prévue, la réponse est oui. Ce sera surtout un mélange de texte plus ou moins verbeux (là ou il faut démontrer) et de formules plus concises (là où il faut calculer), en fait comme en maths, puisque je cherche à les imiter autant que possible.
Je suis d'accord, mais... l'exemple qui a été donné en forme de comparaison entre une déclaration de fonction en Anubis 1 et Caml ne me convainc pas. En effet, en Caml comme semble-t-il en Haskell, on peut définir des fonctions sans préciser les types des arguments (qui seront bien sûr inférés par le compilateur). En Anubis, on doit au contraire, préciser tous ces types avant de commencer à écrire le corps de la fonction (ce n'est pas un problème technique, puisque le compilateur Anubis infère les types par unification, mais une politique délibérée). Evidemment, ça prend de la place. Toutefois, quand je demande à un étudiant de me citer l'énoncé d'un théorème et qu'il me sort une formule parlant de x et y sans avoir déclaré ni x ni y, je râle, et je crois que c'est normal. Je pense qu'on doit déclarer tous les symboles qu'on utilise avant de les utiliser. Bien sûr, on peut deviner leurs types après coup en les inférant soi-même. Mais sincèrement, je crois que c'est une mauvaise pratique (en tout cas, pour les maths, j'en suis sûr). Tout cela rend la relecture d'une fonction en Haskell ou Caml plus difficile que la relecture de la même fonction en Anubis (6 mois après, quand on a tout oublié).
Oui, c'est vrai. C'est d'ailleurs ce qu'on a envie de faire quand on a lu un texte verbeux et qu'on veut saisir l'essentiel de ce qui est dit. On se fait un résumé, voire un graphique, pour avoir tout sous les yeux. L'exemple qui a été pris pour montrer la verbosité d'Anubis est d'ailleurs peu représentatif, car si Anubis est verbeux (j'aimerais mieux dire: impose de tout dire) pour les déclarations de fonctions, il n'est guère plus verbeux que Caml dans le corps de définition. Il utilise plus de parenthèses, mais là encore, je trouve que ça simplifie la détermination visuelle des portées, qui est bien plus difficile en Haskell par exemple, où il n'y a pratiquement pas de parenthèse.
Bonsoir.
Étant donné que le sujet de base est "Que pensez-vous du Langage Anubis ?", et qu'a priori, la seule définition du langage Anubis est son unique implémentation par M. Prouté, j'aurais aimé avoir une réponse concernant la sus-dite implémentation :
Qu'en est-il de la limitation empéchant d'implémenter des listes doublement chaîné et des graphes cycliques (entre autre).
Merci
Alex_pi
L'inférence de types a énormément d'avantages.
1/ Le code est plus concis, plus rapide à taper. Et bien souvent, je parle par expérience, la lisibilité s'en trouve accrue. Si on est dans un cas où le code n'est pas assez clair, il y a toujours la possibilité de typer à la main (l'inférence est une fonctionnalité, elle n'enlève *absolument* rien).
2/ Le système d'inférence généralise le code tout seul, ce qui favorise la réutilisation du code. Imagine que tu aies besoin d'une fonction qui renvoie le maximum d'un tableau d'entiers. En C, une fois que tu as écrit cette fonction, elle ne fait rien de plus. En Caml, le système généralise le code ; cette fonction marche alors sur tout type de tableau. Par exemple, une tableau de flottants. En F#, et en Haskell j'imagine, la fonction sera généralisée à l'ensemble des conteneurs, et pour tous les types de contenus. La fonction pourra être utilisée sur une liste de flottants, un tableau de caractères, etc. Quand on type à la main, on ne pense pas forcément à toutes les utilisations dès le départ (et j'insiste sur le fait que toutes les utilisations sont parfaitement cohérentes et naturelles).
3/ Le fait d'avoir l'inférence permet d'utiliser des types bien plus complexes qu'autrement. Par exemple, je viens d'écrire la fonction (en F#) ayant le prototype suivant :
Elle prend 2 arguments et renvoie un type 'd. Le premier argument doit être un conteneur (implémentant l'interface seq) paramétré par un type 'b. Le deuxième argument a un type 'c. Cette a deux contraintes sur ses types :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4val inline f : #seq< ^b> -> ^c -> ^d when ^c : (static member ( + ) : ^c * ^b -> ^c) and ^c : (static member ( * ) : ^c * ^c -> ^d)
1) il faut qu'il existe un opérateur + prenant les types 'b et 'c et renvoyant du d ; 2) il faut qu'il existe un opérateur * prenant deux arguments de type 'c et renvoyant un type 'd.
Croyez-moi, si j'avais dû typer ma fonction à la main, j'aurais été triste. Ou plutôt, j'aurais écrit une autre fonction, beaucoup moins générale et marchant juste sur un cas particulier.
Je pense que les gens de ce forum ont compris l'utilité d'un bon système de typage. Je crois que plus le système de typage est fin, plus le langage est expressif et sûr.
4/ Je ne crois pas que le typage manuel soit la solution. Je ne pense pas que ce soit au langage d'imposer cette restriction (qui me fait penser au Java où il faut indiquer les exceptions non rattrapées). L'intérêt de typer à la main quand on écrit du code me semble nul (on sait les types que l'on utilise et si on se plante, le compilateur nous reprend). L'intérêt pour le relecteur existe certes. Mais plutôt que de demander au programmeur d'indiquer les types, pourquoi le langage ne les donnerait-il pas lui même ? En Caml, il est possible de générer le fichier interface (qui contient donc les types). En F#, avec certains éditeurs, le type est affiché dans l'éditeur, sans que le programmeur ne l'ait écrit lui-même. Je tape juste ma fonction et l'éditeur m'affiche aussitôt son type.
5/ De nombreux cas sont triviaux. Par exemple, let s = "test" n'a pas besoin d'être typé à la main. C'est lourd, ça ralentit à la fois la lecture et l'écriture de code.
6/ Quelle est la syntaxe pour les fonctions anonymes en Anubis ? Les fonctions anonymes me semblent être un cas où l'absence d'inférence détruit quasiment la fonctionnalité. Quand un langage a une syntaxe lourde pour les fonctions anonymes, cette fonctionnalité tend à être très peu utilisée. Regardez C# 2. Et d'ailleurs, l'inférence de types (très restreinte, certes, mais fonctionnant sur les fonctions anonymes) a été ajouté dans C# 3, malgré le lourd héritage du C.
Ajouter l'inférence de types n'enlève rien et apporte tellement...
@LLB: Je crois qu'on est dans un malentendu total. On s'est mal compris. Il y a de l'inférence types en Anubis, et elles est aussi puissante qu'en Caml autant que je sache, puisqu'elle utilise le même algorithme basé sur l'unification des types.
En Anubis il y a des paramètres de type, par exemple $T, analogues au 'a de Caml. On peut donc écrire des schéma de fonctions valables pour toute valeurs de ces paramètres. Maintenant rien n'empèche de définir un type avec des composants fonctionnels (dans le style OO) et de faire une fonction prenant une donnée de ce type (donc un objet) comme premier argument et d'autres arguments. La fonction ira chercher les opérations + et * dans l'objet en question.
Le fait de devoir indiquer explicitement le type des arguments d'une fonction ne veut pas dire que ces types ne peuvent pas contenir de paramètres de type.
Je ne peux pas t'en dire plus pour le moment, parce que je ne comprends pas tout dans ton message. Je ne vois pas exactement ce que fait l'exemple que tu as donné (par méconnaissance de OCaml/F# très certainement). Par ailleurs, qu'entends-tu par fonction anonyme ?
À partir du moment où on doit (on est obligé) faire les types à la main, je considère qu'il n'y a pas d'inférence : le système de types (plus ou moins complexe) a "juste" à vérifier que tout est valide. C'est le type donné par l'utilisateur qui sera utilisé.
Si je reprends mes arguments, en essayant de mieux expliquer :
. C'est un effort supplémentaire pour le programmeur.
. Le type utilisé sera potentiellement moins général que s'il est calculé par inférence. L'inférence de types utilise toujours le type le plus générique. Un programmeur peut ne pas penser au type le plus générique.
. L'exemple en F# (on a des choses semblables dans Caml avec les objets ou dans Haskell) sert juste à montrer : un type peut être très long ou complexe à écrire. Si on doit l'écrire à chaque fois à la main, on peut être ennuyé et choisir un autre type, plus simple mais pas forcément aussi "bien". Est-il possible d'avoir des contraintes sur les types en Anubis ? Par exemple, au lieu de dire "l'argument a un type T", dire "l'argument peut être de n'importe quel type qui vérifie telle propriété". Une "propriété", ça peut être que le type possède la méthode M ; ou que le type est un type numérique (short int, long int, float...) ; ou que le type est un "conteneur" (liste, tableau...).
. Une fonction anonyme est une juste fonction qui n'a pas de nom. Par exemple, "fun x -> x + 1" est une fonction anonyme (je ne lui ai pas donné de nom) qui à x associe x + 1. L'intérêt est par exemple d'écrire : "List.map (fun x -> x + 1) li". Cela transforme la liste [1; 2; 3; 4] en [2; 3; 4; 5]. La fonction est très courte (une dizaine de caractères en tout) et ajouter les informations de types ici alourdit considérablement le code. Et par expérience on se rend compte qu'une fonctionnalité qui est trop verbeuse sera souvent sous-utilisée.
Tu peux montrer le type (en Anubis) d'un tel objet ?Maintenant rien n'empèche de définir un type avec des composants fonctionnels (dans le style OO) et de faire une fonction prenant une donnée de ce type (donc un objet) comme premier argument et d'autres arguments. La fonction ira chercher les opérations + et * dans l'objet en question.
J'espère que ce message est plus clair. Désolé si je me suis mal exprimé dans le précédent.
@LLB: Je ne suis pas d'accord avec ton analyse concernant l'inférence de types. L'inférence de types est rendue nécessaire par la présence de paramètres de types. Quand on fait appel à une définition comportant des paramètres, le compilateur instancie ces paramètres avec des inconnues fraîches dont les valeurs sont ensuite déterminées par unification.
Maintenant le fait de typer explicitement des arguments des fonctions, est certes une contrainte pour le programmeur, mais ne diminue en rien la généralité du processus, car on ne fait qu'indiquer ce que le compilateur aurait pu deviner. C'est seulement une contrainte d'écriture, mais ça n'oblige pas à écrire plusieurs fonctions là où une aurait suffi.
Cependant, il y a un point sur lequel tu as raison, et effectivement Anubis est moins efficace que Haskell sur ce point (pour Caml, je ne sais pas). C'est le fait qu'il n'y effectivement pas de notion de contrainte sur les types. C'est plus ou moins du tout ou rien: paramètre ou pas paramètre. Je me suis aperçu de cela il y a déjà longtemps, mais jusqu'à présent je n'ai pas jugé utile d'implémenter un tel mécanisme. mais ma position n'est pas définitive et je continue à y réfléchir. Le problème pour moi est de savoir si l'avantage qu'on en tirera vaut la peine d'imposer un concept supplémentaire. Tu sais que les matheux aiment bien les systèmes minimalistes.
Pour ce qui est des fonctions anonymes, il y a des fonctions anonymes en Anubis. Ton exemple peut s'écrire:
et il transformera effectivement la liste [1,2,3,4] en la liste [2,3,4,5]. Bien entendu, il y a encore cette obligation de déclarer le type de l'argument de la fonction anonyme (par contre, on n'a pas beoin de mettre List., même s'il y a 45 fonctions qui s'appellent map), mais comme je l'ai expliqué dans un post plus haut, comme je suis persuadé qu'en maths c'est ce qu'il faut faire, je n'ai pas hésité une seconde à l'imposer en Anubis. Là je vais te gronder un peu, car des exemples de ce type se trouvent dans le manuel d'Anubis et dans la bibliothèque, et je suis très etonné que tu n'ais pas su qu'il y avait des fonctions anonymes en Anubis.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Maintenant, ce qui est important avec les fonctions anonymes, est surtout le fait qu'elles se souviennent du contexte de leur creation. C'est cela la chose fondamentale (qui d'ailleurs nécessite l'utilisation de fermetures). Et bien entendu c'est le cas en Anubis, comme bien entendu de Caml et d'Haskell, faute de quoi ces langages ne seraient pas de vrais langages fonctionnels. S'il n'y avait pas de fonctions anonymes en Anubis, je n'aurai jamais osé dire que c'est un langage fonctionnel.
Maintenant, une chose encore pour bien faire comprendre la philosophie d'Anubis. Le programmeur est payé par son patron pour faire le travail qu'on lui demande avec les outils qu'on lui donne. Par contre, le problème du patron me préoccupe. Son problème est surtout de s'assurer que son équipe de programmeurs va faire un logiciel sans faute. Qu'il faille une rallonge de temps de 20 pour cent pour taper les programmes lui est bien égal. Par contre, il endosse la responsabilité des bugs qui pourraient survenir ensuite. Son problème c'est donc la sûreté. Il y gagne de toute façon, car 20 pour cent de temps passé à taper du code n'est rien en façe de longs mois de débogage qui en plus ne donnent jamais la certitude que le programme est correct. Les trois patrons qui ont choisi Anubis pour le développement de leurs softs, l'ont choisi pour cette raison, sans demander l'avis d'aucun progammeur, et je crois qu'ils ont bien fait, car depuis 7 ans qu'on fait marcher Anubis, ils ont tout lieu d'être satisfait.
Pour ce qui est de l'exemple, je n'ai pas bien compris où sont les paramètres. Est-ce que ^c, ^b et ^d sont trois paramètres ?
D'accord. Je pense que c'est juste une question de vocabulaire. Juste pour mieux expliquer mon point de vue : en C++ aussi, il y a des paramètres (avec les templates), et en général, on ne considère pas le C++ comme ayant de l'inférence de types. Mais ça peut tout à fait se discuter. C'est juste une question de mots.
J'avais détaillé plus haut : le compilateur peut déterminer avec certitude le type le plus générique, le programmeur peut ne pas penser à tout. Eventuellement, on peut modifier le code plus tard et le rendre plus générique, mais quand la fonction est dans une bibliothèque, on ne souhaite pas forcément modifier le code fourni.
OCaml a une forme de contraintes sur les objets (typage structurel), mais c'est limité aux objets, il me semble.
Si on prend l'exemple de la fonction qui calcule le maximum (cf le 2/ un peu plus haut), à quel niveau se place Anubis ?
L'intérêt des contraintes (il y a de nombreuses de les implémenter) est d'avoir un système de typage plus fin et d'avoir un langage plus expressif (les fonctions pouvant alors être plus facilement réutilisées).
Je comprends. Pour l'utilisateur, quand il n'a pas à écrire les types lui-même, c'est un mécanisme qui peut être complètement transparent. Par exemple, si on écrit une fonction qui à x associe x + x, Haskell déduira que la fonction peut avoir n'importe quel type numérique. C'est une contrainte, mais elle est générée par le système d'inférence. L'utilisateur n'a pas à s'en occuper.
Mais je comprends que tu te poses la question. Comme tu exiges les annotations de type, l'intérêt des contraintes est plus limité.
Oui, et ce que rend Lisp merveilleux.
Mais dans notre monde, où tout est bien typé et vérifié soigneusement, il me semble nécessaire d'avoir un système de typage poussé, pour avoir une grande expressivité. C'est un avis assez personnel, et j'apprécie aussi les systèmes minimalistes, mais je pense que le système de typage est le seul point qui n'a pas besoin du minimalisme. Dans l'idéal, il accepte tout ce qui a un sens et refuse tout ce qui n'en a pas.
Pour ce qui est des fonctions anonymes, il y a des fonctions anonymes en Anubis. Ton exemple peut s'écrire:
OK. Avec des types plus "complexes", ça peut donner quelque chose d'assez "moche". Mais je suppose qu'en général, ce n'est pas grave.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Oui, j'avais vu ça et je trouve ça bien. Mais l'absence de contraintes empêche (j'imagine) de généraliser la fonction : (?? x) |-> map x). (remplacer "??" par la contrainte appropriée)
Je me rappelais qu'il y avait des fonctions anonymes, mais je ne me rappelais plus de la syntaxe. C'est vrai, j'aurais dû chercher. Désolé.
Je ne suis pas convaincu que les annotations de types réduisent le nombre d'erreurs ou le temps de débogage. Alors que je suis certain que ça augmente le temps de développement.
Les trois patrons qui ont choisi Anubis pour le développement de leurs softs, l'ont choisi pour cette raison, sans demander l'avis d'aucun progammeur, et je crois qu'ils ont bien fait, car depuis 7 ans qu'on fait marcher Anubis, ils ont tout lieu d'être satisfait.
La fonction a 2 arguments (le premier de type "#seq< ^b>" et le deuxième de type "^c"). ^c, ^b et ^d correspondent à $T, $U, $V d'Anubis.
C'est peut-être un peu plus que cela. Je ne sais pas précisément comment fonctionne un compilateur C++. Quand on utilise un template, doit-on préciser les instances des types, ou le compilateur les devine-t-il lui-même ? Si on doit les préciser, il n'y a en effet pas d'inférence. S'il les détermine lui-même, alors il les infère il me semble car il va bien falloir qu'il unifie.
Si tu écris une fonction en Anubis avec des paramètres, comme par exemple map:
Le compilateur détermine les valeurs les plus générales lors de l'instanciation de ce schéma. C'est à dire en particulier, que si tu utilises map dans une fonction qui a elle même des paramètres ces derniers ne sont pas instanciés par cet usage de map. Il me semble donc que les valeurs trouvées pour $T et $U sont les plus générales possible. De toute façon, c'est bien connu en unification, c'est le fameux ``most general unifier''. Anubis ne fait pas exception à cette règle.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7define List($U) map ( $T -> $U f, List($T) l ) = ...
Le terme 'typage structurel' est encore mystérieux pour moi dans ce contexte. Il faudrait savoir aussi ce qu'on entend par là. Je vais jeter un oeil dans le manuel OCaml.
Je vais le faire pour une liste de choses pour lesquelles il y a une operation binaire 'max_of_two'
Je crois que c'est parfaitement clair, et j'ai du mal à imaginer ce qu'on peut faire de plus général, à moins évidemment d'admettre un mécanisme qui rendrait l'argument fonctionnel max_of_two implicite (de même que max_of_nothing). Je reviens sur cette question plus loin.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13define List($T) -> $T max ( ($T,$T) -> $T max_of_two, $T max_of_nothing ) = (List($T) l) |-> if l is { [ ] then max_of_nothing, [h . t] then max_of_two(h,max(t)) }.
Il faudrait qu'on éclaircisse cette notion de 'contrainte'. Sinon, on risque encore de mal se comprendre.
Justement, là il y a quelque chose qui ne me plait pas. D'abord cette notion de 'type numérique'. Je ne vois pas pourquoi il devrait y avoir une telle notion. C'est une notion qui ne peut prétendre à aucune généralité, les nombres étant une sorte particulière de données parmi des milliers d'autres. Si on commence à faire cela, on va finir par avoir un catalogue de milliers de sortes de types qui n'ont aucun caractère structurel. Pour moi les nombres n'ont rien de particulier, ce sont des données 'ordinaires' si j'ose dire. Ce n'est pas le cas des fonctions qui ont un rôle structurel.
Alors, de fait, il y a une chose qu'Anubis n'a pas et qu'il pourrait avoir éventellement. Ce que je vais dire est sans doute une autre façon de reparler de ces contraintes. Imaginons qu'on définisse une fonction comme j'ai fait ci-dessus avec 'max', mais sans déclarer 'max_of_two' ni 'max_of_nothing'. Le compilateur pourrait inférer ces déclarations lui même. Bon. Lors de l'utilsation de 'max' les opérandes 'max_of_two' et 'max_of_nothing' ne seront donc pas fournis. Le compilateur aura alors à rechercher dans sa base de connaissances des fonctions ayant ces noms et des types qui pourraient être des instances des paramètres. Est-ce de ce mécanisme que sont capables Caml et Haskell ?
Techniquement, je crois qu'il est facile de modifier le comilateur Anubis pour qu'il le fasse. Maintenant, est-ce vraiment une bonne idée, et en particulier cela pose-t-il un problème de sûreté ? Il faut que j'y réfléchisse.
Je suis d'accord, et on doit tendre vers un système de type qui combine la plus grande expressivité possible avec la meilleure sûreté possible. C'est tout le défi de la conception des systèmes de type. Perso, je privilégie la sûreté, mais on peut avoir d'autres objectifs.
Je ne suis pas non plus complètement d'accord sur le fait que le système de types n'a pas besoin de minimalisme, car il doit quand même éviter autant que possible les constructions redondantes.
En tout cas, cela réduit les temps et les efforts de relecture. J'en suis bien convaincu. C'est quand même plus facile de lire un texte où il y a moins de choses à deviner. De toute façon, pour cette histoire de temps passé à développer, la seule chose qui a un sens est le bilan global: developpement + debogage + évolution du programme. Ce qu'on perd sur un tableau, on peut le récupérer sur un autre. C'est le total qu'il faut mesurer. Je crois que la principale des raisons pour lesquelles Foulques a écrit un programme si long tout seul est justement que le temps de débogage est presque nul.
Je peux proposer quelque chose comme:
ensuite on peut faire par exemple:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4type MonObjet($T,$U,$V): mon_objet( ($T,$U) -> $V plus, ($U,$U) -> $V times).
mais ce n'est peut-être pas à cela que tu pensais.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8define $U -> $V exemple ( MonObjet m ) = if m is mon_objet(plus,times) then ($U u) |-> ... utiliser plus et times ici ...
L'utilisation des templates (en C++) ne fonctionne pas tout à fait comme ça (et fonctionne encore différemment des generics de Java).
En C++, Il est nécessaire de fournir le fichier source pour pouvoir compiler. En effet, si par exemple on définie la fonction max comme suit :
Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
Le code source en soit n'est pas compilé. Si quelqu'un l'utilise, on va écrire par exemple :
Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
A ce moment, le compilateur resout le type de i et de j et regarde si cela correspond avec la définition de la fonction que l'on a fait avant. Si c'est le cas, il y a génération d'un nouveau code objet juste pour le type "int". (il y a autant de code objet que de type différent utilisé).
En Java, il y a quelque chose qui s'appelle les generics et qui ressemble également. Par exemple si l'on définie une liste de String.
Dans ce cas ci, il n'y a en fait qu'un seul code compilé (qu'un seul bytecode). Le compilateur ne fait que vérifier les types passés en paramètres (c'est en fait une surcouche à l'ancienne version de java sans generics qui fonctionnait comme cela :
Code java : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
Et qui était rendu possible car tous les objets (non primitifs) héritent de Object (la méthode add était donc du genre : void add(Object object)
Code java : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
Enfin, ceci est une explication simplifiée.
Je ne répondrai à aucune question technique en privé
Merci à millie pour les explications.
L'exemple du template 'max' me laisse un peu perplexe, en ce sens qu'il me semble impossible que le paramètre soit implicitement universellement quantifié. En effet, s'il l'était, et pour que le template ait un sens, il faudrait qu'on ait une fonction de comparaison nommée < pour tous les types, ce qui ne peut être le cas. La quantification implicite doit donc être existentielle, ce qui n'est pas très clair non plus d'ailleurs.
En Anubis, dans les schémas de fonctions (analogues des templates) les paramètres sont clairement quantifés universellement, puisque le compilateur les utilise par particularisation, qui est le destructeur normal du quantificateur universel.
Par ailleurs, pour traiter la suite de l'exemple que tu donnes, il est clair que le compilateur C++ n'a pas besoin d'unifier, puisque les types de i et j sont déclarés (int) juste avant l'utilisation de 'max'. Aucune unification n'est nécessaire ici. Il suffit de substituer int à T. Il n'y a donc peut-être pas d'inférence de types en C++ (du moins, cet exemple ne l'implique pas). Cela n'empêche pas évidemment d'avoir génération d'un nouveau code pour chaque instance du template. C'est ce qu'il se passe aussi en Anubis. Le même schéma peut produire plusieurs instances avec des bytecodes différents suivant les types.
Ce que je comprends pour l'exemple Java est que le code du 'generic' ArrayList est prédéfini indépendamment des instance qu'on pourra créer. Sur le plan des performances et de l'occupation mémoire, ce n'est pas terrible. Tout cela ressemble plus à de l'interprété qu'à du compilé.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager