[Débat] Que pensez-vous du Langage Anubis ?

[SpiceGuid]

En fait l'élimination statique de la vérification des accès tableau est possible même en OCaml (au prix de quelques mécanismes assez tortueux), voici ladite source tortueuse à souhait:

http://okmij.org/ftp/ML/eliminating-...k-literally.ml

Cette vérification est beaucoup plus naturelle dans les langages fonctionnels équipés de types constructifs tels que:
* Dependent ML
* Agda
* Cayenne
* Epigram
* Qi

(mais il fallait cliquer sur le lien que j'avais donné pour s'en convaincre)

EDIT:

C'était un peu la même chose avec les listes, au début il y avait Lisp avec car et cdr qui peuvent déclencher une exception, avec ML il y a eu le filtrage exhaustif, et d'un coup on extrait la tête et la queue sans déclencher d'exception (parce que le cas de la liste vide est exclu et traité par ailleurs).

Envoyé par SpiceGuid

En fait l'élimination statique de la vérification des accès tableau est possible même en OCaml (au prix de quelques mécanismes assez tortueux):

Je rappelle que toute propriété sur le code sources d'un programe P(c) qui ne vérifie pas soit :
- pour tout c, P(c)
soit
- pour tout c, non-P(c)

est indécidable pour un langage turing-complet. Donc la propriété "il n'y a aucun accès hors borne" est indécidable, quelque soit le nombre de lien que tu donnes :-\ Après, il est évident qu'il existe des méthodes pour *limiter* considérablement le risque d'acces hors tableau et supprimer des vérification (typiquement quand le programmeur vérifie manuellement "if k >= 0 && k < l then...", il n'y a pas besoin de le refaire dans le bloc qui suit), et il est aussi possible de limiter l'expressivité du langage (qui n'est plus alors turing complet) pour arriver à ça. Mais pas de faire tout supprimer en restant turing complet, désolé

[SpiceGuid]

Epigram n'est pas Turing-complet, les autres je les connais moins bien mais probablement qu'ils troquent aussi quelque limitation théorique en échange de l'avantage pratique. En Epigram tu ne peux pas écrire:

Code :

let rec f x = f x;;

Il n'accepte que le code pour lequel il peut construire une preuve de terminaison.

Remarque: après êta-réduction OCaml ne compile pas non plus cette même expression

Code :

let rec f = f;;

[ricard33]

Envoyé par InOCamlWeTrust

Alors on revient aux bonnes vieilles méthodes du C (langage on ne peut plus robuste si il n'est pas entre les mains d'un cochon), à savoir tester la valeur de retour d'une fonction à chaque fois que l'on fait une opération et éventuellement, dans le cas des fonctions de la libC, positionner errno à 0 avant l'appel et tester la valeur de retour ! Moi ça ne me dérange pas trop de programmer comme ça, mais l'expérience montre que le programmeur moyen se lasse très vite de ce mécanisme et qu'à la fin, il ne teste plus rien du tout car 50% de son code passe dans la gestion des erreurs !

En effet, et c'est bien le problème du C : si on manque de rigueur, on finit par écrire du code potentiellement (voir même certainement) buggé car non correctement bordé.

Anubis apporte alors l'avantage d'imposer une bonne pratique au développeur : celle de devoir tester les valeurs retour.

Pour me présenter rapidement, je ne suis pas un spécialiste des langages fonctionnels (loin s'en faut d'ailleurs), j'ai plutôt une culture fortement orientée programmation objet, avec une grosse expérience du C/C++, et depuis 3 ans je développe aussi en python, C# et quelques technos Web.

L'apprentissage d'Anubis, entamé il y a 1 an pendant mes temps libres ne fut pas forcément facile car j'ai dû me former à la programmation fonctionnelle. Et la transition objet -> fonctionnelle n'étant pas simple, je vous garanti que j'ai "maudit" plus d'une fois Anubis , d'autant que le langage (et surtout son compilateur) possède quelques défauts de jeunesse.

Mais ayant depuis entamé un gros projet en Anubis, je suis aujourd'hui forcé d'en reconnaitre les qualité. Et notamment celle du temps de développement et de la qualité du résultat.
Une fois l'esprit fonctionnel acquis, je me suis rapidement mis à développer aussi rapidement qu'en C/C++, mes plus grosses pertes de temps étant dues à un manque de documentation globale des bibliothèques. En revanche, je dois reconnaitre que je ne fais presque plus aucun débuggage. Et mes programmes sont quasiment fonctionnels (comme le langage ) dès que la compilation est réussie.
C'est un vrai gain de temps !
Et aucun risque de retomber dans les défauts du développeur C/C++ (absence de test des erreurs), le compilateur ne nous le permet pas.

La gestion d'exception est un vrai plus pour des langage impératif ou objet car elle va permettre de factoriser le code de gestion des erreurs, et de rendre l'ensemble plus clair.
Mais son efficacité repose principalement là encore sur la rigueur du développeur.

Je trouve personnellement que Anubis, même si il ne fait pas de miracle (ce n'est pas ce qu'on lui demande), aide grandement à la mise en place de cette rigueur et cadre, dans le temps, le développeur en lui imposant de respecter les règles initiales.

[gorgonite]

et bienvenue sur le forum,

Envoyé par ricard33

Mais ayant depuis entamé un gros projet en Anubis, je suis aujourd'hui forcé d'en reconnaitre les qualité. Et notamment celle du temps de développement et de la qualité du résultat.

enfin un exemple pratique d'utilisation d'Anubis... ça devrait relancer un peu le débat


peut-on savoir :
+ de quel type de projet il s'agit
+ le nombre approximatif de lignes de code
+ le temps passé pour le développement
+ le temps que vous auriez passé à le faire en C/C++ (vu que vous avez souvent développé avec, ça devrait être évaluable )
+ les performances générales


de votre participation

[ricard33]

Envoyé par gorgonite

peut-on savoir :
+ de quel type de projet il s'agit
+ le nombre approximatif de lignes de code
+ le temps passé pour le développement
+ le temps que vous auriez passé à le faire en C/C++ (vu que vous avez souvent développé avec, ça devrait être évaluable )
+ les performances générales

Merci pour cet accueil.

Concernant notre projet (nous sommes plusieurs), nous préférons rester discrets pour le moment, tant que notre projet n'est pas en phase commerciale. Tout ce que je puis dire, c'est qu'il s'agira d'un mini serveur embarqué fournissant un ensemble de services destinés aux TPE & PME.
Ce projet verra le jour d'ici la fin de l'année (normalement début du 4ème trimestre). Des informations seront alors disponibles sur notre site : www.calexium.com

Pour la partie développement, nous dénombrons environ de 30000 lignes de code Anubis. Le temps passé est difficile à déterminer étant donné que le développement se fait pour grosse partie pendant nos temps libres (certains d'entre nous sont encore en poste dans d'autres sociétés) et ne rejoindront la société qu'à son démarrage commercial. Et aucune véritable métrique n'a été mise en place pour le moment.

Mais Anubis nous a beaucoup aidé dans ce contexte un peu particulier car même si il m'arrive souvent de ne travailler que par toute petites périodes (1 heures ou 2 de rang, parfois moins), j'ai pu conserver la même efficacité qu'une personne travaillant plusieurs heures d'affilées. Même lorsqu'on s'interrompt au beau milieu d'un gros développement, ou même d'un refactoring de code un peu délicat, de toute façon le compilateur ne vous lache pas (en clair ne compile pas votre code avec succès) tant que vous n'avez pas fini. Ce qui évite tout oubli, malgré un fractionnement du temps de travail.
Et le plus beau, c'est qu'en général, une fois qu'on a enfin réussi à compiler (donc que notre travail est totalement fini), ça marche . Et là on découvre la réelle efficacité du langage (malgré tout les noms d'oiseau que le compilateur a pu recevoir juste avant... )

En C/C++, je pense honnêtement qu'on aurait pu faire le même développement dans à peu près les mêmes temps. Seulement malgré toute l'attention qu'on peut apporter à la qualité du code, nous n'aurions très certainement pas eu la même fiabilité. Un programme en C/C++, ou même en C# ou Python, développé dans les mêmes conditions, n'aurait jamais eu le même niveau de qualité et nous aurions dû prévoir soit une phase de débuggage très conséquente, soit (j'aurai choisi cette option) intégrer dans nos développement l'écriture systématique de Tests Unitaires nous garantissant la fiabilité de notre code. Mais nous aurions mis beaucoup plus de temps.

J'entends par là qu'une partie du rôle des tests unitaire est assurée par le compilateur Anubis. En fait, la seule chose qu'il reste a tester est la partie fonctionnelle du produit (couverte généralement par les tests de recette).

Il faut bien voir qu'au jour d'aujourd'hui, nos produits ne connaissent aucun vrai bug. Toutes les fonctionnalité implémentées ont fonctionné quasiment du premier coup. Et c'est plutôt rassurant pour l'avenir.


Niveau performance, elle sont plutôt honorables. Certes, cela reste interprété par une machine virtuelle et cela serait ridicule de vouloir le comparer sur des calculs lourds à du code C optimisé.
Mais là encore, regardons simplement son utilisation (en tout cas pour nous) : si le serveur web n'est pas très véloce (il n'y a qu'à voir sur www.anubis-language.com), c'est essentiellement dû (après vérifications) au fait qu'aucune page ni image n'est mise en cache par le navigateur. Il manque simplement certains headers dans la réponse HTTP, ainsi qu'une gestion intelligente des fichiers modifiés coté serveur (simple erreur de jeunesse, qui sera corrigée rapidement).
Niveau réseau, pensez bien que nous avons réalisé des benchmarks avant de le choisir pour nos mini serveurs. Et là, rien à redire, Anubis est très rapide. Idem pour du traitement classique (genre utilisation d'une base de données, calcul des pages HTML sur le serveur, etc..), on ne sent aucune dégradation de performance, sur ce genre d'utilisation un programme en C n'augmenterait en rien la réactivité.

Allez, un dernier point fort (toujours de notre point de vue) : la VM d'Anubis est très peu gourmande, tant en terme de ressource CPU qu'en mémoire.
De plus, fonctionnant sous Windows et Linux, elle a été très facilement portée sur processeur MIPS. Et les modules Anubis compilés (les fichiers *.ADM) sont complètement portables (le même ADM peut être exécuté sous Windows, Linux X86 ou même Linux MIPS).
Ceci en fait un candidat idéal pour le développement de logiciels embarqués, dans des contextes où le débuggage est toujours délicat et acrobatique.

En tout cas, je vous garantis que personnellement, en quelques mois, j'ai largement changé d'avis sur Anubis. A l'origine, je n'étais pas très chaud pour l'utiliser (ce n'est pas moi qui ait pris cette décision), mais aujourd'hui j'en vois clairement les bénéfices.

Cordialement,
Cédric.

[gorgonite]

Envoyé par ricard33

Allez, un dernier point fort (toujours de notre point de vue) : la VM d'Anubis est très peu gourmande, tant en terme de ressource CPU qu'en mémoire.

je souhaiterais quelques précisions sur ce point... qu'en est-il du "contre-exemple" de alex_pi qui montre qu'une simple structure cyclique fait exploser la mémoire consommée ?
y a-t-il une autre façon de procédé qui permette d'éviter ce désagrément ?
ou, d'après ce que j'ai cru comprendre, comme anubis vise surtout à produire du code "sûr", ce qui interdit ce genre de structure, est-ce la raison pour laquelle le GC ne cherche pas à les gérer ?

[LLB]

Envoyé par ricard33

Et le plus beau, c'est qu'en général, une fois qu'on a enfin réussi à compiler (donc que notre travail est totalement fini), ça marche . Et là on découvre la réelle efficacité du langage (malgré tout les noms d'oiseau que le compilateur a pu recevoir juste avant... )

Et par rapport à d'autres langages fonctionnels à typage fort, genre Caml, Haskell ou F#, qu'apporte Anubis ?

Envoyé par ricard33

En C/C++, je pense honnêtement qu'on aurait pu faire le même développement dans à peu près les mêmes temps.

Ah ? Étant donnée la verbosité de C et de C++, ainsi que leur orientation plutôt bas-niveau, je suis un peu déçu. Quand je développe en Caml ou F#, je remarque une différence assez importante de productivité. Le code est généralement beaucoup plus court[1]. Donc, si tu dis qu'un développement en Anubis n'est pas significativement plus rapide qu'un développement en C ou C++, ça me donne une raison supplémentaire pour ne pas l'utiliser. Ça me conforte dans l'idée de langage verbeux que j'avais d'Anubis.

[1] J'ai été amené à traduire un code C++ en Caml, le nombre de lignes est passé de 4200 à tout juste 800 lignes -- ce n'est certes qu'en exemple et le rapport peut varier, mais le résultat est souvent bien plus court et plus lisible.

Envoyé par ricard33

Seulement malgré toute l'attention qu'on peut apporter à la qualité du code, nous n'aurions très certainement pas eu la même fiabilité.

Oui. C'est la magie du système de typage.

Envoyé par ricard33

Un programme en C/C++, ou même en C# ou Python, développé dans les mêmes conditions, n'aurait jamais eu le même niveau de qualité et nous aurions dû prévoir soit une phase de débuggage très conséquente, soit (j'aurai choisi cette option) intégrer dans nos développement l'écriture systématique de Tests Unitaires nous garantissant la fiabilité de notre code. Mais nous aurions mis beaucoup plus de temps.

OK. Pour Python, je peux comprendre que la phase de débuggage puisse être importante. Pour C#, j'ai quelques doutes : le langage est plutôt correct et il bénéficie d'un typage fort. Il reste toutefois le problème des pointeurs nuls, mais le temps de débuggage me semble beaucoup plus court que ce qu'on a en C.

Envoyé par ricard33

Et les modules Anubis compilés (les fichiers *.ADM) sont complètement portables

Oui, comme ce qu'on a avec Caml, Java, .NET... Et les langages interprétés (Python, Lua, Ruby, Perl...) sont tout aussi portables.

Envoyé par ricard33

En tout cas, je vous garantis que personnellement, en quelques mois, j'ai largement changé d'avis sur Anubis. A l'origine, je n'étais pas très chaud pour l'utiliser (ce n'est pas moi qui ait pris cette décision), mais aujourd'hui j'en vois clairement les bénéfices.

Ce que je remarque surtout, c'est qu'Anubis est souvent comparé au C. Je veux pas dire, mais c'est un peu facile. Avoir plus de sûreté et de vérifications statiques que le C n'est vraiment pas dur.

[SpiceGuid]

Bienvenue @ ricard33.

Pour faire un résumé de ce qui peut faire consensus:

• syntaxe: les débutants seront probablement moins rebutés que par la syntaxe de OCaml/Haskell, c'est un point qui peut faciliter le passage au fonctionnel
• syntaxe: un filtrage exhaustif serait plus confortable qu'une simple alternative
• syntaxe: une notation pour soulager le traitement des alternatives fautives serait appréciable (par exemple des clauses implicites ThisError -> ThisError | ThatError -> ThatError quand le filtrage est un endomorphisme)
• compilateur: le comptage de références est une mauvaise technique de ramasse-miettes
• langage: la récursion sur les données est délicate à exprimer (et en plus est découragée par le ramasse-miette à comptage de références)
• langage: il n'est pas acceptable d'autoriser un accès hors-bornes dans un tableau
• langage: il est encore jeune et sous sa forme actuelle, hormis quelques restrictions qui ont les défauts et les vertues de la simplicité, il n'apporte rien de bien neuf aux utilisateurs de Caml/Haskell/F#

Ce qui n'est pas encore clair pour moi c'est ce que pourrait apporter les topos par rapport aux extensions déjà existantes dans OCaml/Haskell, par exemple les "foncteurs" de OCaml qui sont des fonctions des modules paramétrés vers les modules paramétrés.

[LLB]

Bon, j'ai fait quelques tests, parce que le coup de la division par 0 m'intriguait (en fait, j'imagine qu'il y a des points communs avec ce qui se passe pour les accès des tableaux).

Après quelques essais, on se rend compte qu'une instruction comme :

Code :

with b = (Int32) (8 / 3),

est refusée par le compilateur. Hé oui, la division renvoie un type Maybe. Il faut gérer explicitement le cas de la division par 0... Comme ça, si un jour 3 devient égal à 0, le code marchera toujours.

Code :

with b = (2.1 + 3.2) + 1.3,

Par ailleurs, cette instruction aussi est refusée. Une addition entre deux flottants renvoie un type Maybe. Ah, il faut gérer le cas où il y aurait un overflow ?

Non, puisque :

Code :

with b = (Int32) 2 + 4,

est autorisé. Mais dans ce cas, comment détecte-t-on un int overflow quand on ajoute deux entiers ?

La solution que j'ai trouvée si on ne veut pas se prendre la tête est toute simple.

Code :

1
2
3
4
5
6
7
8
9
10
define $T
   force
     (
       Maybe($T) x,
     ) =
   if x is
     {
       failure then alert,
       success(n) then n
     }.

(Ensuite, il suffit d'écrire :

Code :

with b = (Int32) force(8 / 3),

On se retrouve donc dans le cas de figure habituel. Alert sert en effet à déclancher une exception... non rattrapable !

Un question : est-ce vraiment ce que le concepteur voulait qu'on fasse ? Ou préfère-t-il que l'on gère systématiquement à la main les divisions par 5, dans le cas où 5 vaudrait 0 ?



Bon, je viens de regarder rapidement dans la bibliothèque standard. D'une part, j'ai trouvé une variante de la division qui renvoie un Int32... et qui renvoie 0 en cas de division. Oui, c'est beaucoup plus simple comme ça. Le débuggage doit être beaucoup simple : au lieu d'une exception, on renvoie une valeur sans aucun rapport.

D'autre part, dans la bibliothèque, on trouve la fonction nth qui renvoie le Maybe(n-ième élément d'une liste). Et la fonction force_nth qui renvoie le n-ième élément. Ou fait un alert si la liste est trop courte. On retombe donc ici dans le schéma classique. Sauf que le alert n'est pas rattrapable.



Au final, je ne suis absolument pas convaincu de la sûreté d'Anubis. Je trouve certains choix exagérément contraignants. Et emplacer les exceptions par un plantage direct n'est pas une nouveauté : le C y a pensé avant. Caml (et d'autres langages !) me semble donc un meilleur choix. On peut d'ailleurs définir l'opérateur suivant pour se forcer à gérer les cas douteux :

Code :

1
2
3
let (/?) x y =
  if y = 0 then None
  else Some (x / y)

[SpiceGuid]

100% d'accord avec toi, on a le choix entre 'alert' qui est la faille du système, ou alors une sécurité absurde, parce que si 5/x déclenche une division par zéro celui qui effectue la division ne peut rien faire (à part 'alert' bien entendu!) puisque le fautif est celui qui a fournit la valeur 'x', et dans le cas général ça n'est pas la même fonction qui fournit le diviseur et qui fait la division. Le filtrage ne permet pas de retourner la responsabilité sur le vrai responsable.

Quoiqu'en disent les débutants, il va falloir que les contraintes qu'imposent Anubis soient payantes d'une façon ou d'une autre et pour l'instant on sait quand (when it's done) mais on ne se demande encore de quelle manière.

À ce stade où certains d'entre nous se sont familiarisés avec Anubis 1.7 le Dr Topos pourrait nous donner des exemples de pseudo code qui ressembleraient à ce dont Anubis 2.0 est censé être capable. Il y a beaucoup à gagner à bénéficier de commentaires anticipés plutôt que de commentaires à posteriori.
(je l'entends comme une simple proposition, bien entendu je respecte le libre choix de la confidentialité)

[ricard33]

Envoyé par gorgonite

je souhaiterais quelques précisions sur ce point... qu'en est-il du "contre-exemple" de alex_pi qui montre qu'une simple structure cyclique fait exploser la mémoire consommée ?
y a-t-il une autre façon de procédé qui permette d'éviter ce désagrément ?
ou, d'après ce que j'ai cru comprendre, comme anubis vise surtout à produire du code "sûr", ce qui interdit ce genre de structure, est-ce la raison pour laquelle le GC ne cherche pas à les gérer ?

Comme je l'ai indiqué, je ne suis qu'un débutant en Anubis, et surtout je n'en connais pas toutes les subtilités.
Pour ce cas particulier, je n'en sais rien. J'ai découvert les principe de récursivité terminale avec Anubis (j'ai une culture langage objet, pas fonctionnel). Alors forcément, j'ai encore ce vieux réflex de me dire : c'est normal que cela mange la mémoire. Mais bien entendu nous l'utilisons à différents endroit dans nos produits, et nous n'avons pas de surconsommation mémoire, et cela tourne non-stop depuis des mois.
Je pense qu'il vaut mieux laisser la réponse à l'auteur lui même...

Envoyé par LLB

Et par rapport à d'autres langages fonctionnels à typage fort, genre Caml, Haskell ou F#, qu'apporte Anubis ?

Je n'en sais rien, n'ayant jamais utilisé ces langages..

Envoyé par LLB

Ah ? Étant donnée la verbosité de C et de C++, ainsi que leur orientation plutôt bas-niveau, je suis un peu déçu. Quand je développe en Caml ou F#, je remarque une différence assez importante de productivité. Le code est généralement beaucoup plus court[1]. Donc, si tu dis qu'un développement en Anubis n'est pas significativement plus rapide qu'un développement en C ou C++, ça me donne une raison supplémentaire pour ne pas l'utiliser. Ça me conforte dans l'idée de langage verbeux que j'avais d'Anubis.

Non, Anubis est nettement moins verbeux que du C/C++ ou du C#. Je le rapprocherai du Python (mais avec nettement plus de parenthèses... ). Quand à ma vitesse de développement en Anubis, elle est loin d'être optimum puisque je dois passer encore aujourd'hui un certain temps à m'adapter au mode fonctionnel.
Ce qui pêche également, ce sont les bibliothèque fournies qui ne sont pas très bien organisées. Et surtout l'absence de documentation en bonne et due forme ralenti considérablement le développement. C'est l'un des point à corriger rapidement. La seule véritable doc se trouve directement dans les fichiers sources de la bibliothèque. C'est déjà mieux que rien, mais il manque de quoi l'extraire et produire un manuel de référence (problème de jeunesse du langage).

Aujourd'hui, je commence à être plus à l'aise et pour moi il n'y a aucun doute sur le gain par rapport au C# ou Python.

Envoyé par LLB

OK. Pour Python, je peux comprendre que la phase de débuggage puisse être importante. Pour C#, j'ai quelques doutes : le langage est plutôt correct et il bénéficie d'un typage fort. Il reste toutefois le problème des pointeurs nuls, mais le temps de débuggage me semble beaucoup plus court que ce qu'on a en C.

Exact, le C# apporte déjà beaucoup par rapport au C/C++. Mais il n'en reste pas moins que si on ne se borde pas de Test unitaire, on prend les mêmes risques qu'en C/C++, Python ou Java. Les contraintes apporté par le compilateur Anubis nous affranchi d'une bonne partie de ces tests.
Et encore une fois, je suis novice en langage fonctionnel, donc je ne peux pas comparer avec Caml, Haskell ou F#.

Envoyé par LLB

Oui, comme ce qu'on a avec Caml, Java, .NET... Et les langages interprétés (Python, Lua, Ruby, Perl...) sont tout aussi portables.

Oui, mais tout ceux que je connais (Java, .NET et Python) sont plus gourmands en ressources (et même beaucoup plus gourmand dans le cas de .NET et Java). Désirant travailler dans un environnement très minimaliste, Anubis devient une très bonne alternative au C. Et de cette façon, nous éliminons tout besoin de débuggage sur le hardware de destination.

Pour conclure mon témoignage, je dirais que je pense avoir une vision très pragmatique. Anubis nous prouve quotidiennement que nous avons fait le bon choix de langage pour notre projet. Mais la qualification de bon choix est très dépendant de la nature du projet.
Par exemple, je développe également un IDE pour Anubis (initialement, n'ayant pas de projet particulier à réaliser en Anubis, c'était une façon d'approcher ce langage), et cet IDE est en C#. Je ne me vois absolument pas le faire en Anubis.
Idem dès que j'ai un script rapide, efficace et portable à réaliser, j'ai une préférence pour Python.

Donc à chaque langage son utilisation.

Quand à Anubis, il a encore besoin évoluer et doit parcourir du chemin pour être bien mature. Mais dans sa forme actuelle, il est tout à fait exploitable, même dans un contexte industriel, avec certaines contraintes.

Envoyé par SpiceGuid

100% d'accord avec toi, on a le choix entre 'alert' qui est la faille du système, ou alors une sécurité absurde, parce que si 5/x déclenche une division par zéro celui qui effectue la division ne peut rien faire (à part 'alert' bien entendu!) puisque le fautif est celui qui a fournit la valeur 'x', et dans le cas général ça n'est pas la même fonction qui fournit le diviseur et qui fait la division. Le filtrage ne permet pas de retourner la responsabilité sur le vrai responsable.

Je pense personnellement que 'alert' est une instruction qui doit disparaitre du langage. C'est un artéfact juste utilisé à l'origine pour du Debug (à ce qu'on m'a expliqué). Mais cela va en totale contradiction avec l'esprit du langage.

Quand aux divisions, débordements et dépassement de tableau, nous n'utilisons que les versions retournant un 'Maybe(quelque chose)' pour que le compilateur nous oblige à gérer les différents cas d'erreur. Cela fait parti des chose un peu contraignante, mais c'est la seule manière de conserver un code parfaitement fiable. Et c'est un bien maigre prix à payer pour un code d'une fiabilité à toute épreuve.

[Woufeil]

Envoyé par ricard33

Pour conclure mon témoignage, je dirais que je pense avoir une vision très pragmatique. Anubis nous prouve quotidiennement que nous avons fait le bon choix de langage pour notre projet.

Je reprend juste ce petit point : je ne pense pas que tu puisses affirmer ça comme ça. Tant que tu n'as pas tout testé, tu ne peux pas savoir ce qui est le meilleur (si si ! Si il faut en basic ça aurait était mieux ). A la limite, et en ayant une connaissance des différents paradigmes de programmation, tu peux te dire que le choix du paradigme était bon. Mais rien ne te permet d'affirmer que Ocaml ou Haskell ne serait pas des meilleurs choix.

Par ailleurs, il me tarde de voir les réponses du DrTopos

[BigTotoro]

Envoyé par Woufeil

Je reprend juste ce petit point : je ne pense pas que tu puisses affirmer ça comme ça. Tant que tu n'as pas tout testé, tu ne peux pas savoir ce qui est le meilleur (si si ! Si il faut en basic ça aurait était mieux ). A la limite, et en ayant une connaissance des différents paradigmes de programmation, tu peux te dire que le choix du paradigme était bon. Mais rien ne te permet d'affirmer que Ocaml ou Haskell ne serait pas des meilleurs choix.

Bonjour, je suis la personne qui à décidé d'utiliser Anubis dans ce projet industriel. Effectivement, ce choix éminemment subjectif à votre point de vue. La raison en est simple je connaissais Anubis en premier et il faisait exactement tout ce que je voulais sans prendre de mémoire à une vitesse plus que correcte.
Effectivement j'aurai pu testé des langages que je ne connaissais pas.
Mais là, je ferais un peu l'analogie avec la vie courante.
Je parle français, anglais, japonais et presque le chinois. Mais je ne vais pas parlé l'espéranto qui est peut être le meilleur choix pour la communauté des linguistes (mais ici n'est pas le débat), car je ne le connais pas et je n'ai pas le temps de l'apprendre. Ce que je veux dire par là, c'est toute décision est complètement subjective et peut être violemment critiqué pour de bonnes ou de mauvaises raisons.
Je sais que mon choix est un peu lazy, mais je l'assume.

Je suppose qu'Ocaml, qu'Haskell, et les milliers d'autres langages de programmation font très bien leur travail. Mais Anubis nous va parfaitement. Nous faisons un projet industriel avec et nous n'avons pas le temps de voir ailleurs. Et cela nous va très bien pour le moment.

Mais de grâce ne vous prenez pas pour les inquisiteurs du langage fonctionnel. Il est vrai qu'en lisant ce forum on a parfois l'impression d'avoir à faire à des intégristes plutôt qu'à des personnes réfléchis ouvertes au débat (Je sais qu'ici je vais avoir le droit à une avalanche d'insulte). Mais c'est mon ressentiment. Je vous dit aussi tout de suite que je ne passerai pas mon temps à répondre à des attaques personnel ou autres si cela ne fait pas avancer les choses.

Dernière remarque:
Il se trouve que tout ceux qui critiques sur ce forum, je ne les ai jamais vu poster une critique sur le forum d'Anubis langage mis à part 2 personnes. La critique est constructive et permet de faire avancer les choses mais en aucun cas à les détruires.

Cordialement à tous

[ricard33]

Envoyé par Woufeil

Je reprend juste ce petit point : je ne pense pas que tu puisses affirmer ça comme ça. Tant que tu n'as pas tout testé, tu ne peux pas savoir ce qui est le meilleur (si si ! Si il faut en basic ça aurait était mieux ). A la limite, et en ayant une connaissance des différents paradigmes de programmation, tu peux te dire que le choix du paradigme était bon. Mais rien ne te permet d'affirmer que Ocaml ou Haskell ne serait pas des meilleurs choix.

Par ailleurs, il me tarde de voir les réponses du DrTopos

Petite précision : je n'ai pas dis "le meilleur choix", mais juste le bon choix, ce qui implique que ce choix n'est pas le seul et l'unique .

Ensuite, c'est une position certes subjective, mais dépendant des différents éléments dont nous avons eu connaissance à ce moment, de comment s'est déroulé notre projet et des résultats actuels.
Et c'est dans ce contexte que je maintiens que ce choix fut très bon, sans doute même le meilleur que nous puissions faire à ce moment.

D'autres personnes, avec d'autres connaissances, auraient pu faire un autre choix tout aussi bon ou "meilleur" dans leur contexte.

Tout ce qui compte pour nous, c'est le résultat et les délais (donc les coûts) pour l'atteindre. Et au jour d'aujourd'hui, nous n'avons pas à nous plaindre de nos choix.

[gorgonite]

Envoyé par BigTotoro

Mais de grâce ne vous prenez pas pour les inquisiteurs du langage fonctionnel. Il est vrai qu'en lisant ce forum on a parfois l'impression d'avoir à faire à des intégristes plutôt qu'à des personnes réfléchis ouvertes au débat (Je sais qu'ici je vais avoir le droit à une avalanche d'insulte). Mais c'est mon ressentiment. Je vous dit aussi tout de suite que je ne passerai pas mon temps à répondre à des attaques personnel ou autres si cela ne fait pas avancer les choses.

Je trouve votre affirmation plus que déplacée à l'égard des membres de ce forum... à ce que j'ai pu lire, très peu de personnes se sont permises des critiques "non constructives", car trop peu argumentées, mais qui pourraient se justifier sur le fond.

Si vous parcouriez un peu ce forum, vous constatriez que nous sommes au contraire, dans l'immense majorité des posteurs, particulièrement ouverts à tous les points de vue.


Je ne continuerais pas cette polémique, qui n'a pas sa place sur ce post, mais je tenais à ce que ce soit dit...


cordialement

[LLB]

Envoyé par BigTotoro

Ce que je veux dire par là, c'est toute décision est complètement subjective et peut être violemment critiqué pour de bonnes ou de mauvaises raisons.

Bien sûr. Je pense que personne ne vous fera de reproches pour ça.
Les personnes qui participent ici ne sont pas dans la même situation : ils sont ici par curiosité et cherchent à comprendre mieux le langage. Ce n'est donc pas un choix lazy, ils cherchent à comprendre les forces et les faiblesses (sans croire aveuglément les descriptions données). En tout cas, même si certaines remarques étaient assez vives, il ne faut surtout pas le prendre mal. Les remarques faites visent à aider les développeurs d'Anubis (lorsqu'elles sont pertinentes) ou à apporter des précisions sur le langage (lorsqu'elles ne sont pas tout à fait justes).

Envoyé par BigTotoro

Anubis nous prouve quotidiennement que nous avons fait le bon choix de langage pour notre projet.

Je reste persuadé que d'autres langages vous auraient apporté la même chose, voire mieux.
Bien sûr, dans le contexte de l'époque, et avec vos connaissances, c'était peut-être le meilleur choix.

Notamment, pour tout ce qui tourne autour de la sûreté, je pense que d'autres langages peuvent être apporter autant, à condition d'appliquer des règles avec rigueur (ces mêmes règles qui font que tu évites le alert en Anubis, font que tu gères les divisions par 0 dans d'autres langages).

Envoyé par BigTotoro

Il est vrai qu'en lisant ce forum on a parfois l'impression d'avoir à faire à des intégristes plutôt qu'à des personnes réfléchis ouvertes au débat

Je pense que les personnes qui participent sont beaucoup plus ouvertes que tu ne le croies. Certaines remarques permettront à DrTopos d'apporter des précisions et d'expliquer ses choix.

Envoyé par BigTotoro

Il se trouve que tout ceux qui critiques sur ce forum, je ne les ai jamais vu poster une critique sur le forum d'Anubis langage mis à part 2 personnes. La critique est constructive et permet de faire avancer les choses mais en aucun cas à les détruires.

Oui. Mais même une critique un peu agressive peut être constructive, tant que les remarques faites sont pertinentes. Il ne faut en aucun cas prendre mal les remarques faites.

Par ailleurs, comme DrTopos et d'autres viennent ici, je ne vois pas quel intérêt j'aurais à aller sur le forum d'Anubis. J'irai dessus le jour où je serai plus ou moins convaincu. Il existe énormément de langages, j'ai lu les manuels ou des livres sur beaucoup d'entre eux ; il y a donc pas mal de langages que je peux critiquer, mais ce n'est pas pour autant que je vais le faire sur les forums concernés.

Envoyé par ricard33

Quand aux divisions, débordements et dépassement de tableau, nous n'utilisons que les versions retournant un 'Maybe(quelque chose)' pour que le compilateur nous oblige à gérer les différents cas d'erreur.

D'accord, merci. C'est bien ce que je pensais. Mais du coup, on peut obtenir ce même comportement dans d'autres, et je ne suis pas convaincu par l'apport d'Anubis. De plus, l'interdiction d'écrire une expression comme "x / 2 + 1" me semble totalement démesurée.

L'idée d'éviter au maximum les exceptions n'est pas mauvaise. Dans beaucoup de cas, c'est même une bonne idée. Mais dans d'autres, c'est trop contraignant. Il arrive très souvent que le programmeur sache qu'il n'y a aucun risque. Je pense qu'avec un compilateur intelligent, ça pourrait donner quelque chose de pas mal : le compilateur devrait chercher, par analyse statique, si le diviseur peut-être nul. En cas de doute, il renverrait un type Maybe, sinon une valeur directe. Notamment, lorsque l'on divise par une constante non nulle, gérer le cas de la division par 0 devient absurde. Que peut-on faire dans ce cas imaginaire ? Utiliser alert, même si c'est déconseillé ? Renvoyer une valeur quelconque, qui n'a absolument aucun sens, et qui peut réduire la lisibilité du code ?

Envoyé par ricard33

Donc à chaque langage son utilisation.

Pour ma part, je préfère pouvoir utiliser le même langage dans 90% des cas. C'est pour ça que j'ai choisi F# (pour les 10% restants, j'utilise Bash/Zsh, Sed, C++ et Caml). Son héritage de ML le rend très adapté pour l'algorithmie, le calcul symbolique, la compilation, etc. Sa syntaxe très concise le rend utilisable pour des scripts. Son intégration dans .NET le rend acceptable pour les interfaces graphiques ou pour réaliser des jeux. Il peut se combiner avec l'ASP (ou être utilisé seul) pour créer des sites web. Il peut aussi servir à réaliser des animations dans un site web, via SilverLight (bon, c'est encore trop récent pour être utilisable).
Je préfère ne pas avoir à multiplier les langages, d'autant plus que les langages sont rarement compatibles entre eux ; une même fonction doit pouvoir être réécrite dans un autre langage pour être utilisée.

Je me suis un peu éloigné du sujet, mais je voulais mettre en garde contre l'utilisation d'un langage aussi spécifique qu'Anubis. Pour moi, il me semble très peu adapté pour un particulier. Et utiliser un langage si peu connu, avec si peu de garanties, me semble plutôt risqué pour une entreprise. Mais j'apprécie le travail qui a été fait pour Anubis et il y a quelques bonnes idées dans le langage.

[BigTotoro]

Envoyé par gorgonite

Je trouve votre affirmation plus que déplacée à l'égard des membres de ce forum... à ce que j'ai pu lire, très peu de personnes se sont permises des critiques "non constructives", car trop peu argumentées, mais qui pourraient se justifier sur le fond.

Effectivement, je tiens à tempérer mon affirmation, et à m'excuser auprès des personnes que cela aurai pu blesser.

Envoyé par gorgonite

Si vous parcouriez un peu ce forum, vous constatriez que nous sommes au contraire, dans l'immense majorité des posteurs, particulièrement ouverts à tous les points de vue.

J'avais remarqué, et d'ailleurs j'apprécie.

Envoyé par gorgonite

Je ne continuerais pas cette polémique, qui n'a pas sa place sur ce post, mais je tenais à ce que ce soit dit...

C'est fait et j'acquiesce.

cordialement

Bonjour !

Envoyé par BigTotoro

Mais de grâce ne vous prenez pas pour les inquisiteurs du langage fonctionnel. Il est vrai qu'en lisant ce forum on a parfois l'impression d'avoir à faire à des intégristes plutôt qu'à des personnes réfléchis ouvertes au débat (Je sais qu'ici je vais avoir le droit à une avalanche d'insulte). Mais c'est mon ressentiment. Je vous dit aussi tout de suite que je ne passerai pas mon temps à répondre à des attaques personnel ou autres si cela ne fait pas avancer les choses.

Je pense être un petit peu concerné, surtout par la seconde partie, je vais donc commencer par là
J'ai effectivement été très incisif vis à vis de DrTopos directement, et je me rends compte que j'ai été trop incisif. Je tiens néamoins à en expliquer la raison. Il me semble normal, surtout lorsque l'on a passé 6 ou 7 ans à le développer, de faire la promotion de son langage, et d'en mettre en avant les avantages. En revanche, il ne me semble pas honnête de faire cela en dénigrant le travail des autres, surtout lorsque l'on dit en parallèle ne s'être tout simplement pas intéressé à ce travail. C'est ce qui m'a rendu particulièrement incisif et même agressif vis à vis de cette personne.

Pour ce qui est de l'intégrisme, nous sommes face à un langage qui se présente comme étant basé sur une théorie mathématique "à la pointe". Il me semble alors assez normal que certains tentent de se pencher sur des aspects théoriques, ce qui peut légèrement nous faire passer pour des intégristes.

D'un autre coté, un certain nombre de problème on ne peut plus pratique ont été soulevés, et n'ont toujours pas reçu de réponse de DrTopos, ce qui est un peu décevant

Bref, je tiens à m'excuser pour les attaques trop personnelles envers DrTopos. En revanche, je maintiens les nombreuses réserves que j'ai directement vis à vis du langage, et qui ne changeront pas tant que je n'aurais pas reçu de réponse précise.

--
alex_pi

[BigTotoro]

Bonjour alex_pi

Envoyé par alex_pi

D'un autre coté, un certain nombre de problème on ne peut plus pratique on été soulevé, et n'ont toujours pas reçu de réponse de DrTopos, ce qui est un peu décevant

DrTopos est en vacances, ce sont des choses qui arrive, surtout pendant la période d'été.
Donc laissons lui le temps de rentrer afin de poursuivre le débat sur les points de détail que seul lui à le secret.

Cordialement