Discussion :

[gorgonite]

Oui mais c'est le cas : Windows est bien un nid à virus, il est effectivement instable, cher et offre peu de fonctionnalités.

Mais je dois avouer que dans le genre rapiah, Apple fait encore plus fort.

perso, je suis d'accord... mais on arrête là sur cette parenthèse

[alex_pi]

Cher Dr Topos

Vous dites dans un de vos posts aimer être incisif, j'en déduis que vous ne m'en voudrez pas de l'être.

Je tiens tout d'abord à préciser que je n'ai pas encore eu le temps de regarder votre langage, en revanche j'ai lu la quasi totalité de ce fil de discussion. Et disons le clairement, ça ne fait pas sérieux. Vous dites donc travailler au développement d'un langage fonctionnel depuis 7 ans maintenant, et il semble que vous ne vous soyez pas un seul instant penché sur ceux existant. En début de fils, vous attaquez violement Haskell en les accusant de ne pas dutout se servir de monade après avoir survollé le manuel. Vous découvrez quelque post plus loin que finalement, ces braves gens ne sont peut être pas si débile qu'ils en ont l'air.

Vous affirmez fièrement ne vous inspirer de rien d'autre. Est cela la recherche ? Ne surtout pas regarder ce que font les autres, pour ne surtout pas être influencé ? Ca me semble assez contre-productif, et légèrement prétentieux.

Vous attaquez Microsoft research en les accusant de ne rien faire de mieux que voler OCaml, de ne pas être capable d'inventer... Peut être que lorsque le sujet de recherche est la compilation d'un langage fonctionnel vers la plateforme .Net, est-il judicieux de choisir une syntaxe déjà éprouvée, et qui plus est connue, ce qui déconcertera beaucoup moins d'utilisateur potentiel.

Pour rester dans le sujet "Microsoft", vous confondez completement Microsoft, la société qui produit Windows, et Microsoft Research (certe financé par le précédant), qui est un labo de recherche d'excellente réputation. Là encore, assez dommage pour quelqu'un se prétendant "à la pointe de la recherche". J'aimerai savoir comment vous faites sans lire un seul papier (parce qu'en matière de programmation fonctionnel, dès qu'on commence à en lire, le nom de Microsoft Research ne tarde pas trop à pointer son nez).

Pour continuer dans le sujet papier, je n'en ai pas trouvé un seul concernant Anubis. Si c'est bien le cas, là encore, c'est plus que déconcertant ! Un langage à la pointe de la recherche, sans aucun papier ?

Vous parlez dans un de vos post de "portage linux, windows et MIPS". Aïe... MIPS est un processeur, linux et windows des systèmes d'exploitation... D'ailleurs Linux tourne sur architecture MIPS. Il y a un petit soucis quelque part non ?

Vous dites que les filtrages sont uniquement là pour éviter des emboitements de conditionnels. En tout cas en OCaml, le filtrage n'est pas dutout un emboitement de conditionnelles puisqu'il lie des variables, ce que ne fait pas la conditionnel (typiquement, quand vous avez un élément de type 'a option, ce n'est pas une conditionnelle qui vous extraira x de Some x)

C'est bien d'être convaincu de ce que l'on fait, c'est même indispensable pour continuer. Mais vous est-il réellement indispensable de cracher avec mépris sur OCaml et Haskell, qui semblent pourtant à première vue être plutôt appréciés de la communauté de l'informatique théorique ? Surtout quand ces critiques sont entrecoupé d'autres commentaires montrant que justement, vous ne connaissez pas ces langages.

Jetons un oeil au site : Bon, c'est bien d'essayer de vendre son produit. Mais quand le langage est utilisé par 3 boites(dont deux pour un site web), clamer à grand renfort de valeur quantitative :

the affirmation that debugging time in Anubis is 40 times shorter than in C is not an invention. This is a fact that any programmer may be convinced of after a bit of use of Anubis. This is not due to hazard, but to the fact that Anubis relies on the most advanced theory of mathematical foundations.

Vous trouvez pas que ça fait un peu charlatan sur un marcher, en train de vendre un sirop qui guérit tout, des mots de gorges aux vérues plantaires ?

Et ne serait-il pas plus pertinant de le comparer à d'autre langages du même genre ? J'entends par là que le C, c'est un langage vieux de pret de 35 ans, conçu pour programmer un système d'exploitation, bref, un gros assembleur. Tout le monde sait que même le langage fonctionnel le moins bien conçu du monde sera beaucoup plus facile à débugguer que du C.

D'où vous vient cette vision comme quoi "l'execution d'un programme est toujours normale" qui vous a amené à bannir les exceptions ? Elles sont quand même un moyen extremement naturel de programmer. Prenons un exemple. Supposons que je programme un interpréteur pour un langage manipulant des chaines de caractères, à typage fort. Depuis la première fonction appelé à la racine, un paquet de fonction s'empilent avant d'arriver au moment où je teste que ma chaine à le bon type. Et si ce n'est pas le cas, et bien c'est un cas "anormal". Je n'ai vraiment, mais alors vraiment pas envie d'avoir à gérer ce cas à la main dans chacune des fonctions intermédiaires, avec un type somme "CaMarche | CaMarchePas". Non, je veux réellement lancer une exceptions qui sera ratrapé à la racine, affichera un message d'erreur, et interrompra l'execution du programme. Le monde réel n'est malheureusement pas celui, idéal, des mathématique où tout se passe toujours bien :-)

Bref, pour conclure, je n'ai pas encore regardé le langage en lui même, mais, comme vous l'aurez constaté, l'enrobage me déplait fortement. Heureusement que maintenant le téléchargement est libre, sinon je me serai arreté là !

A dans quelques jours pour les commentaires sur le langage à proprement parler.

[SpiceGuid]

Permettez-moi d'être en désaccord sur la gestion des erreurs, le principe même de la programmation fonctionnelle c'est que tout est une valeur, une erreur doit être une valeur comme une autre, "CaMarche | CaMarchePas" est le type (ou le codomaine de la fonction) qui capture la possibilité que CaNeMarchePas, cette possibilité doit avoir une valeur et un type sinon on s'éloigne de la programmation fonctionnelle.

Alors, bien sûr, on voudrait ne pas avoir à filtrer CaMarchePas dans chaque fonction pour progager l'erreur. Mais il s'agit là d'une critique de la syntaxe, on peut très bien imaginer un mécanisme de déclaration de point fixe (du filtrage), de telle sorte que dans un filtrage endomorphe on ait, par défaut:

CaMarchePas -> CaMarchePas

De fait il n'y aurait alors qu'à filtrer CaMarchePas à la racine, ce qui est bien la fonctionnalité que vous recherchez. Pour être honnête je pense qu'il serait abusif de dire qu'Anubis est incomparablement plus sûr du fait de l'absence d'exceptions, il n'empêche que l'expérience a montré qu'au bout du compte il y a toujours un avantage à inclure davantage de spécifications dans le type. Peut être la gestion des erreurs en Anubis est-elle un peu pesante, mais au moins on ne peut pas l'ignorer, espérons qu'elle se fera plus discrête dans une prochaine version.

Les autres remarques me parraissent davantage centrées sur la démarche ou sur la personne, je n'y répondrai pas.

[alex_pi]

A dans quelques jours pour les commentaires sur le langage à proprement parler.

Je retire ce que j'ai dit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
***@***:~/test/anubis$ tar -xsf Anubis_1_7_0_1_Linux.tar.gz
***@***:~/test/anubis$ ./install
./install: 11: Syntax error: "(" unexpected

Ca va être plus long que prévu... Je vais tenter avec une autre version. [EDIT]En fait non, puisqu'il n'y a pas l'air d'avoir les archives. Je vais donc hacker le script à la main :-\[REEDIT]le bug *et* la solution ont été indiqué sur un forum anubis il y a maintenant 2 mois. Elle n'a pas été mise en place (alors qu'elle consiste à rajouter deux lettre. Ou mieux, à corriger le script pour le rendre compatible sh)[/REEDIT][/EDIT]

BTW, la majorité des unixien préfère faire un *minimum* de chose avec les droits roots. C'est pour ça que généralement, on met un script configure, qui permet de définir le chemin d'installation pour éventuellement le mettre dans son home, puis un make a executer en utilisateur normal, et un make install a exécuter avec les droits du répertoire destination de l'installation. Donc éventuellement avec les droits normaux pour les tests dans le home.
De plus, pourquoi remettre des tar.gz dans un tar.gz ?

[alex_pi]

AAAAARGGGHHHL !!

Mon Dieu, mais comment pouvez vous prétendre que votre langage est 40 fois plus rapide à débuguer qu'un autre avec une telle *horreur*

Si i est trictement plus petit que 0 tout se passe comme si i valait 0. S’il est strictement plus grand que n-1, tout se passe comme s’il valait n-1.

L'acces hors borne dans un tableau est une des sources première de bug (en gros, tous les erreurs de segmentation en C, plus ceux, bien plus sioux, où l'on va modifier le voisin sans s'en rendre compte), et là, au lieu de permettre de détecter ce bug, HOP, vous le glissez sous le tapis !! Moralité, c'est encore plus dur à débuger que C, parce qu'en C on a une petite chance d'avoir un crash, ici, rien.

Et pour la cohérence, c'est joli. Quand on écrit dans un emplacement du tableau, et qu'on relit immédiatement le même emplacement, on n'est pas sûr de récupérer la valeur écrite. Nan, y a pas à dire, c'est secure et mathématiquement à la pointe.

[alex_pi]

J'ai enfin réussi à installer le machin, et j'ai commencé à jouer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
Type A:...
Type B:b(Var(Maybe(A)) val).
Type A:a(Var(Maybe(B)) val).


global define One
  foo
    (
      List(String) blih
    ) =
    with a = (A) a(var(failure)), b = (B) b(var(success(a))),
    val(a) <- success(b);
    foo([]).

Vous allez rire, ça bouffe toute ma mémoire, et ça fout mon pc à genoux. En voilà un GC qu'il est bien écrit :-) Rassurez moi, ce n'est pas uniquement un GC à incrément décrément ?? Non pardon, tout le monde sait que ça ne fait pas l'affaire face à une structure récursive, donc ce n'est évidement pas de là que vient le problème.
Nan parceque la version ocaml

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
# type a = {mutable a:b option} and b = {mutable b:a option};;
type a = { mutable a : b option; }
and b = { mutable b : a option; }
# let rec foo () =
        let a = {a = None} in
        let b = {b = Some a} in
        a.a <- Some b;
        foo ();;
val foo : unit -> 'a = <fun>

elle tourne a mémoire constante (0,5%). Doit y avoir quelque chose.

[InOCamlWeTrust]

Permettez-moi d'être en désaccord sur la gestion des erreurs, le principe même de la programmation fonctionnelle c'est que tout est une valeur, une erreur doit être une valeur comme une autre, "CaMarche | CaMarchePas" est le type (ou le codomaine de la fonction) qui capture la possibilité que CaNeMarchePas, cette possibilité doit avoir une valeur et un type sinon on s'éloigne de la programmation fonctionnelle.

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 !

[InOCamlWeTrust]

Vous allez rire, ça bouffe toute ma mémoire, et ça fout mon pc à genoux. En voilà un GC qu'il est bien écrit :-) Rassurez moi, ce n'est pas uniquement un GC à incrément décrément ?? Non pardon, tout le monde sait que ça ne fait pas l'affaire face à une structure récursive, donc ce n'est évidement pas de là que vient le problème.
Nan parceque la version ocaml

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
# type a = {mutable a:b option} and b = {mutable b:a option};;
type a = { mutable a : b option; }
and b = { mutable b : a option; }
# let rec foo () =
        let a = {a = None} in
        let b = {b = Some a} in
        a.a <- Some b;
        foo ();;
val foo : unit -> 'a = <fun>

elle tourne a mémoire constante (0,5%). Doit y avoir quelque chose.

OCaml fait ici du partage de valeurs, c'est pourquoi a "pointe" ici sur b et b "pointe" sur a ; de plus, a et b sont très probablement balayés assez rapidement par le GC mineur, d'où la faible consommation mémoire. Pour bouffer toute la mémoire, Anubis, je pense, ne doit faire que de la copie de valeurs, ou alors son Garbage Collector est nul ou cassé... ce qui est possible ; on peut aussi se demander si Anubis optimise la récursivité terminale. Une petite explication du concepteur serait intéressante.

[InOCamlWeTrust]

Serait-il possible d'avoir accès aux sources du compilateur et de la machine virtuelle ? J'ai l'impression que la distribution Linux ne contient que les sources de la librairie standard.

Pour ce qui est du langage en lui-même, je ne le connaissais pas, je n'en avais même jamais entendu parler, mais il y a trop de choses dans la rubrique Philosophy que j'ai du mal à avaler : découvrir ce langage sera difficile.

In CAML, there is a notion of 'filtering' which looks somewhat like the conditionals in Anubis. However, using filtering in CAML is not mandatory. CAML programmers may use more traditional conditionals and have the same problems as C programmers. In Anubis, this is different, because Anubis conditionals are the only way of destructing datas in sums and products. This fact is the main reason why Anubis is so secure. One will be easily convinced of that after some manipulations of lists for example.

If Anubis conditionnals can destructure values, they are filters too, right ?

CAML programmers may use more traditional conditionals and have the same problems as C programmers.

Les programmeurs Caml (please, do not write it CAML) utilisent le filtrage à outrance, bien plus que les programmeurs Haskell... cette affirmation à du mal à passer, surtout si on a déjà mis son nez dans les sources de Caml !

The fact that conditionals, non only in Anubis, are structurally linked to sums is widely misunderstood in the programming community. This is of course mainly due to the fact that sums themselves are misunderstood.

Alors on est tous des ignares, et les mecs de Haskell et Caml aussi, non ? Merci, je ne m'en étais jamais rendu compte.

This is certainly the reason why the treatment of sums in C and similar languages is so disastrous.

Languages are generaly not disastrous : only programmers are !

C'est si difficile, en C, de faire ainsi...

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
/* Type des types contenus dans l'union : les types eux-mêmes deviennent des valeurs ! */
enum Union_type_t
{
    Union_typeint,
    Union_typedouble
};
 
/* Type des données contenues dans dans l'union */
union Union_data_t
{
    int Union_dataint;
    double Union_datadouble;
};
 
/* Type union */
struct Union_t
{
    enum Union_type_t Union_type;
    union Union_data_t Union_data;
};

Anubis version 1 is already a very noticeable advance towards a greater safety in programming. Compared to languages currently used around the world, among which the C language and its cousins, its degree of safety is considerably higher, and the affirmation that debugging time in Anubis is 40 times shorter than in C is not an invention.

Ca, c'est carrément inadmissible de l'affirmer ! Comment peut-on dire qu'un langage comme Anubis est plus sûr que le C !

En Anubis,

Peux-tu détecter une panne de mémoire ? Si oui, peux-tu en connaître la cause exacte ? Peux-tu survivre à une panne mémoire ?
Peux-tu gérer les signaux arrivant sur le processus en cours, les bloquer, ou effectuer des traitements spéciaux ?
Peux-tu connaître les raisons fines et détaillées d'échec d'une fonction système ?
Peux-tu survivre à un segfault ou une erreur de bus (en C, un segfault ou un buserror n'est pas nécessairement fatal, et même dans les langages sûrs, on en rencontre de temps à autre) ?
Peux-tu avoir un contrôle fin des erreurs provoquées par les opérations arithmétiques ou flottantes ?

J'en passe et des meilleures.

Affirmer une telle chose en 2007 n'est que le signe d'une méconnaissance totale du C.

Hier matin, j'ai pu parler avec un membre du projet Gallium sur les orientations futures du langage : on voit bien la différence entre ceux qui font la théorie, et ceux qui passent leur temps à la contempler. Dans tous les cas, si il doit y avoir un nouveau langage fonctionnel issu de chez Gallium, il ne ressemblera pas vraiment à ce que l'on connaît désormais.

Tout ça pour dire qu'en matière de programmation il faut savoir redescendre sur terre de temps en temps.

[alex_pi]

Je pense en avoir assez vu de ce langage pour pouvoir maintenant répondre à la question initial du thread "que pensez vous du langage Anubis ?".

Pour faire court, je pense qu'il est tout simplement mauvais et inutilisable. Et je crois que la raison profonde est très simple. Je la tire d'un forum du site anubis

(1) les langages de programmation existant ne m'intéressent pas, c'est uniquement la modélisation des preuves et programmes par des outils mathématiques (en l'occurence la Théorie des Topos) qui m'intéresse

Autrement dit, le concepteur de ce langage n'est pas dutout au fait des avancés de la communauté des langages de programmation, ni d'ailleurs des simples besoins des programmeurs. C'est ainsi qu'il fait un garbage collecteur d'une qualité execrable (incapable de gérer une structure circulaire \o/ C'est quand même une erreur que l'ont fait généralement dans le premier quart d'heure du TD sur les ramasses miettes...) , qu'il pense supprimer les erreurs en retournant une valeur farfelue lors d'un acces hors borne à un tableau (ça, c'est ce qui a définitivement tué la crédibilité de ce langage à mes yeux. Prétendre diviser par 40 la temps de débugage quand on gère d'une façon si absurde la cause majeure de bugs informatiques....) etc.

Mais même sur un plan théorique, le concepteur, très légèrement imbu de lui même, fait parfois doucement sourire. Lorsqu'il dit

Comparons un peu la théorie des types à celle des catégories. La théorie des types est d'inspiration syntaxique. C'est avant tout une affaire de 'langage'.

Il donne quand même très légèrement l'impression de penser qu'un système de typage, c'est "t = int | t-> t"...

Son choix de vocabulaire dans la documentation de son langage est un peu déroutante. J'apprend ainsi qu'effectuer une écriture sur la sortie standard est une oppération non déterministe. C'est ammusant, la dernière fois que j'ai testé, quand je fais "print_string \"kikoo\"", ça imprime "kikoo", même si la varible x vaut 42.

Il type ses expressions au petit bonheur la chance. Les addresses produisent toujours des Int8, mais leur type est quand même paramétré par Int8. C'est bien, le langage n'était pas assez verbeux comme ça.

Lorsqu'il introduit la programmation fonctionnelle récursive, il montre qu'il n'y est pas dutout habitué. Il a une première fonction map sur les listes dont la définition caml (non tail récursive) est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
let rec map f = function 
  | [] -> []
  | t::q -> (f t)::(map q);;

Il a ensuite un liste de fonctions 'a -> 'b, et il veut écrire un autre fonction map qui prend une telle liste, plus un élément de type 'a, et retourne une 'b list. Que fait-il ? il la redéfini... alors que la solution est évidement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

let map_bis l v = map (fun f -> f v) l

Hé oui, c'est *ça* la magie du fonctionnel...

Pour montrer que la récursivité est plus simple que les boucles, il prend l'exemple du calcul de a ^ b, et écrit ça en C avec une boucle while. Il parraitrait que la boucle for soit là pour ça... Si la machine virtuelle est écrite comme ça, elle doit être simple à débugger !

Il prétend qu'il vaut mieux utiliser la pile du systeme qu'une pile faite à la main, et que c'est pour ça qu'il ne faut surtout pas se prendre la tête avec la récursivité finale. Un bon gros n'importe quoi Dans ma pile, je mets la valeur qui m'intéresse. Dans la pile systeme, il y a des copies de registres, des adresses de retour, etc. Ma pile est dans le tas, donc uniquement limité par la taille mémoire, la pile système est généralement de petite taille. Bref, il *faut* privilegier la récusivité finale !

Il dit que le compilateur Anubis *version 1* n'est pas capable de vérifier certaine chose, sous entendant que le 2 le sera ? C'est dommage que la propriété en question soit notoirement indécidable.

L'idée de la surveillance des variables est ammusante. Mais là encore, c'est n'importe quoi. Déjà je ne peux rien faire du ticker retourné, à part le garder. Alors pourquoi adjoindre à son type celui de ma variable, et pas juste lui donner le type Ticket ? Mais surtout, ne pas m'autoriser à désinscrire ma variable, parce que "le GC le fera tout seul", c'est malin ça. Supposons que j'ai une raison valable de désinscrire ma variable à chaque fois que je passe dans une certaine fonction. Qu'en gros, je veux suspendre l'inscription, écrire dans ma variable, reprendre l'instruction. Bah je peux pas. Enfin, disons que si le GC est bien programmé (qui a dit "on a déjà vu que non" ?), il n'est pas sensé s'exécuter entre chaque instruction. Donc je ne peux pas juste me débarasser du ticket, faire mon écriture, en ouvrir un autre. Je suis juste bloqué. Le principe même d'un GC est d'être non déterministe (au sens courement admis...) Le programmeur n'a pas à savoir quand est ce qu'il va se lancer. Il ne se lancera d'ailleurs probablement jamais sur un cycle majeure (je parle là de GC générationnel). Donc le programmeur*doit* avoir la possibilité de fermer ses fichiers, ses connections réseau, etc, sinon il n'a aucune assurance que ce sera fait un jour.

Bref, pour résumer, je pense que ce langage est ammusant pour 24h, mais qu'il n'apporte rien, qu'il propose des performances catastrophique, et qu'il est à oublier. Si vous voulez un langage fonctionnel efficace et qui a fait ses preuves, regardez OCaml. Si vous voulez un langage fonctionnel de grande qualité théorique (lui aussi basé sur la théorie des catégories, mais avec bien plus de sérieux), regardez Haskell.

[EDIT]Ah, et j'oubliais, le script d'install, non compatible sh, a la bonne idée de rajouter ses librairies en tête du path. Heureusement que je n'ai pas installé ça en root... [/EDIT]
Have fun

[SpiceGuid]

L'acces hors borne dans un tableau est une des sources première de bug (en gros, tous les erreurs de segmentation en C, plus ceux, bien plus sioux, où l'on va modifier le voisin sans s'en rendre compte), et là, au lieu de permettre de détecter ce bug, HOP, vous le glissez sous le tapis !!

Et ta conclusion c'est que les exceptions sont indispensables, au moins pour gérer les accès tableaux hors-bornes. Je ne serai pas aussi catégorique, il existe déjà des langages qui sont capables d'interdire les accès hors-bornes à la compilation, dans ce cas les notions de tests à l'exécution et d'exceptions "hors-bornes" deviennent obsolètes. Avant de critiquer l'absence d'une fonctionnalité dans un langage de recherche il faut souvent demander ce qui est censé la remplacer.

[alex_pi]

Et ta conclusion c'est que les exceptions sont indispensables, au moins pour gérer les accès tableaux hors-bornes. Je ne serai pas aussi catégorique, il existe déjà des langages qui sont capables d'interdire les accès hors-bornes à la compilation, dans ce cas les notions de tests à l'exécution et d'exceptions "hors-bornes" deviennent obsolètes. [/CODE]

Le seul problème est que c'est notoirement indécidable \o/

Avant de critiquer l'absence d'une fonctionnalité dans un langage de recherche il faut souvent demander ce qui est censé la remplacer.

Je ne considère pas Anubis comme un langage de recherche (Haskell oui, bien sûr)

[gorgonite]

Il dit que le compilateur Anubis *version 1* n'est pas capable de vérifier certaine chose, sous entendant que le 2 le sera ? C'est dommage que la propriété en question soit notoirement indécidable.

rien ne te permet d'interpréter les "sous-entendus" à ta guise... perso, je verrais plutôt que la version 2 sera capable de vérifier plus de choses que la 1.
par ailleurs, j'ai ouï dire qu'avec certaines logiques anti-axiomatiques, la décidabilité n'était pas forcemment un problème

Bref, pour résumer, je pense que ce langage est ammusant pour 24h, mais qu'il n'apporte rien, qu'il propose des performances catastrophique, et qu'il est à oublier. Si vous voulez un langage fonctionnel efficace et qui a fait ses preuves, regardez OCaml. Si vous voulez un langage fonctionnel de grande qualité théorique (lui aussi basé sur la théorie des catégories, mais avec bien plus de sérieux), regardez Haskell.

c'est ton opinion, et je la respecte... perso, je n'ai pas encore commencé à tester anubis. toutefois, permets moi de te dire que je trouve "ridicule" des remarques du style : dans mon langage préféré, ils font comme cela, et pas ici... donc c'est nul :-p


je pense que c'est assez mesquin de ta part d'essayer de surinterpréter les propos d'une personne, avant même qu'elle est eu le temps de se justifier... car créer un nouveau langage aux performances correctes est un travail pharaonique, et pour gagner du temps, on n'implémente parfois pas l'algorithme "optimal" dans les premières versions

je te dirais juste que si anubis était si mauvais que cela, comment le site l'hébergeant pourrait-il tourner ? peut-être n'as-tu pas pris le recul nécessaire pour comprendre comment programmer efficacement avec ce langage peu commun

[alex_pi]

rien ne te permet d'interpréter les "sous-entendus" à ta guise... perso, je verrais plutôt que la version 2 sera capable de vérifier plus de choses que la 1.
par ailleurs, j'ai ouï dire qu'avec certaines logiques anti-axiomatiques, la décidabilité n'était pas forcemment un problème

Bah dans ce cas, je veux bien que tu m'écrives un programme en logique anti-axiomatique qui détermine si un autre programme va finir ou non :-\

c'est ton opinion, et je la respecte... perso, je n'ai pas encore commencé à tester anubis. toutefois, permets moi de te dire que je trouve "ridicule" des remarques du style : dans mon langage préféré, ils font comme cela, et pas ici... donc c'est nul :-p

Je ne pense pas avoir fait beaucoup de comparaison avec Caml au niveau des choix. Juste pour le GC, mais bon, entre "faire planter le système" et "tourner à usage mémoire constant de 0,5%", je pense que le choix n'est pas ridicule, mais plutot objectif :-)

je pense que c'est assez mesquin de ta part d'essayer de surinterpréter les propos d'une personne, avant même qu'elle est eu le temps de se justifier... car créer un nouveau langage aux performances correctes est un travail pharaonique, et pour gagner du temps, on n'implémente parfois pas l'algorithme "optimal" dans les premières versions

En fait, si le monsieur n'était pas aussi prétentieux dans ses "Avec Anubis, c'est 40 fois moins de temps de débugage" ou "si les concepteur d'OCaml/Haskell avait compris quoi que ce soit à la théorie machin", je n'aurais évidement pas été aussi catégorique et agressif. Disons qu'il clame un peu trop haut et fort des choses qui s'avèrent être fausse.

je te dirais juste que si anubis était si mauvais que cela, comment le site l'hébergeant pourrait-il tourner ? peut-être n'as-tu pas pris le recul nécessaire pour comprendre comment programmer efficacement avec ce langage peu commun

Euh... On fait tourner des tas de site web en PHP, et je pense que personne ira prétendre que c'est un langage d'une surreté exceptionnelle, basé sur une théorie mathématique à la pointe de la pointe etc...

[gorgonite]

Bah dans ce cas, je veux bien que tu m'écrives un programme en logique anti-axiomatique qui détermine si un autre programme va finir ou non :-\

soit tu es un débutant (ce qui ne semble pas être le cas), soit tu fais semblant de ne pas savoir qu'il y a une différence entre logique et programmation... donc je ne pourrais pas écrire un programme dans une logique anti-axiomatique, puisque ce n'est pas un langage de programmation
par ailleurs, ce qui est théoriquement possible n'est pas toujours réalisable dans la pratique... pour implanter quelque chose il faudrait un algorithme (ou une démonstration constructiviste) de l'existence d'un tel programme.

Je ne pense pas avoir fait beaucoup de comparaison avec Caml au niveau des choix. Juste pour le GC, mais bon, entre "faire planter le système" et "tourner à usage mémoire constant de 0,5%", je pense que le choix n'est pas ridicule, mais plutot objectif :-)

peut-être n'as-tu pas trouvé la bonne manière de l'implanter ? (je laisse le bénéfice du doute, a priori en une journée, tu ne maitrises pas le langage)

qui te dis que je n'arriverais pas à rendre ton programme ocaml aussi gourmand en bidouillant un peu ta façon de coder...

Euh... On fait tourner des tas de site web en PHP, et je pense que personne ira prétendre que c'est un langage d'une surreté exceptionnelle, basé sur une théorie mathématique à la pointe de la pointe etc...

peut-être, mais ils tournent... et même parfois sans faille de sécurité (même si c'est rare )

anubis est un langage très jeune (encore plus que php semble-t-il), et pourtant il semble pouvoir déjà mieux faire... donc il ne doit pas être si nul que cela

[alex_pi]

soit tu es un débutant (ce qui ne semble pas être le cas), soit tu fais semblant de ne pas savoir qu'il y a une différence entre logique et programmation... donc je ne pourrais pas écrire un programme dans une logique anti-axiomatique, puisque ce n'est pas un langage de programmation
par ailleurs, ce qui est théoriquement possible n'est pas toujours réalisable dans la pratique... pour implanter quelque chose il faudrait un algorithme (ou une démonstration constructiviste) de l'existence d'un tel programme.

Si j'ai dit ça, c'était justement pour mettre l'emphase sur le fait que ton histoire de logique anti-axiomatique n'avait pas grand chose à voir avec le schmilblique, puisque là le problème est justement *d'implémenter* une vérification des bornes du tableau.

peut-être n'as-tu pas trouvé la bonne manière de l'implanter ? (je laisse le bénéfice du doute, a priori en une journée, tu ne maitrises pas le langage)

et

car créer un nouveau langage aux performances correctes est un travail pharaonique, et pour gagner du temps, on n'implémente parfois pas l'algorithme "optimal" dans les premières versions

J'ai trouvé exactement la bonne méthode pour le programmer, puisque mon but était de vérifier si le GC était simplement à incrément/décrément, ce qui semble être le cas. Plusieurs chose par rapport à la seconde citation. Un GC non optimisé est un GC lent, qui prend beaucoup de ressources. Un GC qui ne supprime pas de la mémoire des données pourtant inaccessible est un mauvais GC. Il y a une *grosse* différence

qui te dis que je n'arriverais pas à rendre ton programme ocaml aussi gourmand en bidouillant un peu ta façon de coder...

Le fait que j'ai une grande confiance dans la qualité du GC d'OCaml ? But be my gest !

[Garulfo]

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 !

Là je suis d'accord avec toi effectivement. Les exceptions ont « réussi » pour plusieurs bonnes raisons : améliore la lisibilité, raccourci la taille du code, séparation clair entre la partie gestion erreur et gestion du cours normal du programme etc.

[gorgonite]

Si j'ai dit ça, c'était justement pour mettre l'emphase sur le fait que ton histoire de logique anti-axiomatique n'avait pas grand chose à voir avec le schmilblique, puisque là le problème est justement *d'implémenter* une vérification des bornes du tableau.

c'est toi qui as introduit la décidabilité dans ce débat...

Le seul problème est que c'est notoirement indécidable \o/

je n'ai fait que répondre par une notion tout aussi théorique, et certainement aussi difficile à obtenir en pratique

J'ai trouvé exactement la bonne méthode pour le programmer, puisque mon but était de vérifier si le GC était simplement à incrément/décrément, ce qui semble être le cas.

qui te dit qu'il n'y a pas un mécanisme particulier pour implanter ce genre de structure, qui justement ne ferait pas foirer le GC ???

But be my gest !

si tu veux des défauts d'OCaml, sur des choses qu'on ne peut coder facilement alors que "fonctionnellement" c'est assez trivial... il y en a des listes déjà prêtes

du genre comment programmer un combinatoire de point fixe de manière simple et élégante en Caml ? perso, la manière la plus propre, selon moi, ne passe pas le typeur... alors que l'on peut prouver à la main que ça marche bien comme il faut

[alex_pi]

Et ta conclusion c'est que les exceptions sont indispensables, au moins pour gérer les accès tableaux hors-bornes. Je ne serai pas aussi catégorique, il existe déjà des langages qui sont capables d'interdire les accès hors-bornes à la compilation

c'est toi qui as introduit la décidabilité dans ce débat...

Noop, c'est SpiceGuid ;-) Mon histoire de décidabilité est juste pour dire que tu ne peux pas résoudre à la compilation tous les problèmes d'acces hors borne
tu dis que

je n'ai fait que répondre par une notion tout aussi théorique, et certainement aussi difficile à obtenir en pratique

mais la décidabilité ou la calculabilité ne sont pas des problèmes "théorique", c'est au contraire très pratique : "ai je une chance de faire ce que je veux faire". Et pour la vérification des bornes à la compilation, dans le cas général, la réponse est pratique aussi : "non"

qui te dit qu'il n'y a pas un mécanisme particulier pour implanter ce genre de structure, qui justement ne ferait pas foirer le GC ???

Tout ce que je fais, c'est créer une structure circulaire, et tenter de l'oublier. Je ne fais définitivement rien de particulier. D'ailleurs, voici une version (qui bouffe de la mémoire comme la précédante), qui pourtant devrait marcher même sans tail récursivité (ça devrait juste faire un stack overflow)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Type A:...
Type B:b(Var(Maybe(A)) val).
Type A:a(Var(Maybe(B)) val).

define One
  bar
    (
      One blih
    ) =
     with a = (A) a(var(failure)), b = (B) b(var(success(a))),
    val(a) <- success(b);
    unique.


define One
  foo
    (
      One blih
    ) =
    bar(unique);
    foo(unique).

global define One
  fail
    (
      List(String) blih
    ) =
    foo(unique).

si tu veux des défauts d'OCaml, sur des choses qu'on ne peut coder facilement alors que "fonctionnellement" c'est assez trivial... il y en a des listes déjà prêtes

du genre comment programmer un combinatoire de point fixe de manière simple et élégante en Caml ? perso, la manière la plus propre, selon moi, ne passe pas le typeur... alors que l'on peut prouver à la main que ça marche bien comme il faut

Il y a quand même une grosse différence entre un programme qui ne typecheck pas (et donc ne compile pas), alors qu'on a de (peut être) bonne raison de penser qu'il devrait, et un programme qui compile et qui échoue alors qu'on a de (peut être) bonne raison de penser qu'il ne devrait pas (échouer).

[Garulfo]

[...]
En fait, si le monsieur n'était pas aussi prétentieux dans ses "Avec Anubis, c'est 40 fois moins de temps de débugage" ou "si les concepteur d'OCaml/Haskell avait compris quoi que ce soit à la théorie machin", je n'aurais évidement pas été aussi catégorique et agressif. Disons qu'il clame un peu trop haut et fort des choses qui s'avèrent être fausse.[...]

Et bien soit heureux tu as toi gagné la palme de la personne la plus détestable du fil même si tes remarques sont bien souvent bien justifiées.

Ceci mis à part, tu as de nombreux point qui sont très pertinent et Dr Topos devrait probablement répondre pour donner son avis. Car certains de tes jugements sont posés rapidement sans attendre une explication.