Débuter en programmation fonctionnelle

[Gnux]

Envoyé par Jean-Marc.Bourguet

Il faut avouer que je suis plus fasciné pour le moment par le typage statique.

Et pourquoi donc?

[Gnux]

Envoyé par InOCamlWeTrust

Programmer dans un langage pur et strict me paraît être une mauvaise idée, car il s'agit de deux notions contradictoires, ou du moins qui ne collent pas bien entre elles.

Comment ça? Je comprends pas trop en quoi les deux ne collent pas très bien entre elles?

[Jean-Marc.Bourguet]

Envoyé par Gnux

Et pourquoi donc?

Pourquoi pas?

[InOCamlWeTrust]

Envoyé par Gnux

Comment ça? Je comprends pas trop en quoi les deux ne collent pas très bien entre elles?

Ca consomme trop de ressources sur des données un peu grandes. Les langages purs, de par leur conception, permettent justement de s'affranchir de cette contrainte.

Je voulais juste dire que pour développer des applications, voire de gros programmes, Scheme ou Lisp n'est peut-être pas l'idéal. Par contre, pour apprendre la philosophie et l'état d'esprit de l'approche fonctionnelle, ça peut être une bonne idée car il s'agit de langages relativement simples.

[InOCamlWeTrust]

Le typage statique garantit qu'aucune erreur ne surviendra lors de l'exécution du programme, et, en ce sens, est un gage indéniable de sûreté de développement.

Par exemple, le gros challenge de la couche objet de OCaml a justement été de conserver cette approche, tout en gardant un langage entièrement polymorphe, alors que l'approche objet lève beaucoup de cas où une partie de la vérification de types est faite classiquement à l'exécution... pour le coup, la Caml team a fait du beau travail.

Objective Caml est d'ailleurs le seul langage à objets polymorphe au monde, typé statiquement.

[Jean-Marc.Bourguet]

Envoyé par InOCamlWeTrust

l'approche objet lève beaucoup de cas où une partie de la vérification de types est faite classiquement à l'exécution... pour le coup, la Caml team a fait du beau travail.

Quelle partie de la vérification de types est faites à l'exécution en C++? Ou quelle erreur de typage passe alors inapperçue? (tant qu'on n'utilise pas ce qui est fait explicitement pour ça naturellement.)

[InOCamlWeTrust]

Je ne connais pas les détails de l'inféreur de types de C++, ni même comment il est foutu ; par contre, en Java, il m'est déjà arrivé d'avoir des erreurs de typage à l'exécution, car Java n'est pas entièrement typé à la compilation :

http://deptinfo.cnam.fr/~barthe/OO/typage-java-2/

Ce sont les traits de la POO (surcharge, héritage, sous-typage) qui font qu'il est presque impossible de typer certaines choses à la compilation.

OCaml, bien que polymorphe et objet, conserve le typage statique : mais les classes ne se comportent pas exactement comme en C++ ou Java, c'est une approche un peu différente : entre autres, il n'y a pas de surcharge (ce qui viendrait casser le polymorphisme et ferait rentrer le système dans un doute potentiel) et le type des méthodes ne peut contenir de variable de type libre, sauf si cette variable paramètre elle-même la classe. Le sous-typage est, quant à lui, toujours explicite : il faut expliciter le sur-type lors de l'utilisation d'un objet d'une sous-classe dans une expression.

[Jean-Marc.Bourguet]

Envoyé par InOCamlWeTrust

Je ne connais pas les détails de l'inféreur de types de C++, ni même comment il est foutu ; par contre, en Java, il m'est déjà arrivé d'avoir des erreurs de typage à l'exécution, car Java n'est pas entièrement typé à la compilation :

http://deptinfo.cnam.fr/~barthe/OO/typage-java-2/

Tu fais allusion au problème avec le tableau (je passe sur la conversion explicite que je classe dans les choses faites pour avoir de la vérification dynamique)? Je ne comprends pas pourquoi Java autorise l'assignation au départ, un tableau de D n'est pas un tableau de A même si D hérite de A. L'équivalent en C++ idiomatique n'est pas possible, mais l'est bien en utilisant les tableaux "C" (à cause de la conversion implicite des tableaux en pointeurs et la possibilité de faire de l'arithmétique des pointeurs -- un foutu m.... ces tableaux C, même quand on se limite au C) mais ça ne me convainc pas parce que cette caractéristique du C++ n'est pas fondamentalement liée au problème qui nous occupe.

[InOCamlWeTrust]

Envoyé par Jean-Marc.Bourguet

un foutu m.... ces tableaux C, même quand on se limite au C

Les tableaux C sont ce qu'ils sont : des tableaux bas niveau. Quand on sait bien les utiliser, la programmation est presque enfantine.

Envoyé par Jean-Marc.Bourguet

mais ça ne me convainc pas parce que cette caractéristique du C++ n'est pas fondamentalement liée au problème qui nous occupe.

Convaincre de quoi ?

[gorgonite]

Envoyé par InOCamlWeTrust

Bon, un tour de table bien fait me paraît important.

+1... rien ne remplace un listing
http://www.linux-center.org/fr/devel...nal/index.html

il manque Anubis... http://fr.wikipedia.org/wiki/Langage_Anubis

Envoyé par InOCamlWeTrust

Si je devais conseiller un langage fonctionnel, ce serait celui-là : les autres (Scheme et Lisp en particulier) sont trop difficiles à appréhender lorsque l'on veut faire des applications complexes, car ils laissent relativement peu de marge au programmeur.

perso, je trouve que Scheme est aussi pas mal pour les développeurs qui veulent faire quelque chose de leur code...
http://community.schemewiki.org/?Stalin

Envoyé par InOCamlWeTrust

Haskell serait aussi un bon choix, à ceci près qu'il possède énormément de particularités, souvent déroutantes pour des gens qui proviennent même du domaine fonctionnel : entre autres, les monades, très délicates à expliquer, et le système de classes, qui se situe un niveau au-dessus de ce que tu peux connaître. En effet, en Haskell, une classe regroupe des types et non des objets !

je dirais aussi que Haskell a aussi un avantage que l'on ne perçoit pas toujours... on peut faire à moindre coup un similateur pour traitement de data-flow sur un "modèle synchrone" (pour tous ceux qui ne veulent pas se mettre à Scade, Esterel ou Argos)

[gorgonite]

Envoyé par Jean-Marc.Bourguet

Quelle partie de la vérification de types est faites à l'exécution en C++? Ou quelle erreur de typage passe alors inapperçue? (tant qu'on n'utilise pas ce qui est fait explicitement pour ça naturellement.)

à ma connaissance, le C++ possède la plupart des polymorphismes existant à l'heure actuelle (j'ai pas dit tous), et conserve un typage fort... et statique !!! (désolé InOcamlWeTrust, mais on reste copain ?)

toutefois, il faut admettre que le transtypage de pointeur est une entorse à la règle...


en ce qui concerne Java, le typage est en deux partie : statique et dynamique... ce qui est à ma connaissance le cas de tous les langages autorisant l'introspection et l'invocation des objets. le paradigme objet revenant à SmallTalk

[InOCamlWeTrust]

Envoyé par gorgonite

à ma connaissance, le C++ possède la plupart des polymorphismes existant à l'heure actuelle (j'ai pas dit tous), et conserve un typage fort... et statique !!! (désolé InOcamlWeTrust, mais on reste copain ?)

Pas sûr que ce soit le même polymorphisme... mais bon, je dois admettre que je n'ai jamais touché une seule ligne de C++. Peut-on écrire des méthodes valables pour TOUS les types en C++ ?

[Gnux]

Envoyé par Jean-Marc.Bourguet

Pourquoi pas?

Eh bien pourquoi trouves tu qu'il est plus fascinant d'avoir une vérification de typage avant la compilation plutot qu'à l'exécution?
Il n'existe pas de bons livres d'introduction à la notion de types et de typage en dehors de ceux de Pierce...?

[gorgonite]

Envoyé par InOCamlWeTrust

Pas sûr que ce soit le même polymorphisme... mais bon, je dois admettre que je n'ai jamais touché une seule ligne de C++. Peut-on écrire des méthodes valables pour TOUS les types en C++ ?

ben non... c'est pour cela que j'ai dit "presque". ils n'ont pas le plus couillu, celui de caml

[gorgonite]

Envoyé par Gnux

Eh bien pourquoi trouves tu qu'il est plus fascinant d'avoir une vérification de typage avant la compilation plutot qu'à l'exécution?

parce que :
- la vérfication dynamique coûtent chère (cf SmallTalk ou Java), tout en autorisant des trucs rigolos en POO pur... mais ce n'est pas le débat
- la vérification statique débugge pas mal au passage
- si l'on n'est pas en modèle simplement typé (booléen, entier, fonction), il se pose plein de problèmes rigolos (et difficiles) de sous-typage... dont la propagation des contraintes, l'unification, etc.

et je peux ouvrir mes cours de typages pour t'en sortir plus...

[Woufeil]

Envoyé par gorgonite

ben non... c'est pour cela que j'ai dit "presque". ils n'ont pas le plus couillu, celui de caml

Ah, on parle d'impératid et d'OO, tout d'un coup je comprend bien

Que fais-tu des templates en C++ ? Un template est bien un type générique, donc on peut bien définir une méthode valable pour tous les types d'objets. Ou alors il y a une entore à la règle que je ne connais pas...

Toujours est il que tant qu'une méthode n'est pas virtuelle en C++, le typage de toutes les variables de cette méthode est statique, pour cause de compatibilité avec le C.

Pour le transtypage des pointeurs, c'est particulier... Je suppose que quoi qu'il en soit, un pointeur occupe une place constante dans la mémoire (un octet pour les processeurs 32 bits si je ne m'abuse). Donc, même après transtypage, un pointeur reste un poiteur, c'est juste qu'il ne ponte plus vers le même type de valeur. Ce n'est pas comme une converstion int vers float.

[gorgonite]

Envoyé par Woufeil

Que fais-tu des templates en C++ ? Un template est bien un type générique, donc on peut bien définir une méthode valable pour tous les types d'objets. Ou alors il y a une entore à la règle que je ne connais pas...

ceux sont des titres paramétrés... conceptuellement proches des "a' list" de caml

[HanLee]

Envoyé par gorgonite

parce que :
- la vérfication dynamique coûtent chère (cf SmallTalk ou Java), tout en autorisant des trucs rigolos en POO pur... mais ce n'est pas le débat
- la vérification statique débugge pas mal au passage
- si l'on n'est pas en modèle simplement typé (booléen, entier, fonction), il se pose plein de problèmes rigolos (et difficiles) de sous-typage... dont la propagation des contraintes, l'unification, etc.

et je peux ouvrir mes cours de typages pour t'en sortir plus...

Moi j'veux bien des cours de typage .

[Jean-Marc.Bourguet]

Envoyé par InOCamlWeTrust

Les tableaux C sont ce qu'ils sont : des tableaux bas niveau. Quand on sait bien les utiliser, la programmation est presque enfantine.

C'est pour ça que dès qu'il est question de ces tableaux sur les forums C et C++, je passe mon temps à démonter des mythes... Je n'ai pas l'impression que ce soit si compliqué que cela, mais le fait est qu'il y a pas mal de confusion

[Jean-Marc.Bourguet]

Envoyé par Gnux

Eh bien pourquoi trouves tu qu'il est plus fascinant d'avoir une vérification de typage avant la compilation plutot qu'à l'exécution?

Je ne trouve pas cela plus fascinant, je suis fasciné par cela pour le moment.

Il n'existe pas de bons livres d'introduction à la notion de types et de typage en dehors de ceux de Pierce...?

Je passe.