Discussion :

[Woufeil]

On commence souvent avec du procédurale qui est plus « naturel » puisque hérité d'une pensée mathématique très pratiquée par les étudiantEs (enfin espérons :mg

là je ne suis pas tout à fait d'accord, si on veut quelque chose proche des mathématiques, autant faire du fonctionnel plutôt que du procédiral. J'aime beaucoup l'haskell pour ce genre de choses. Il permet vraiment de formaliser la pensée mathématique. Par exemple, pour les factorielles, la définition classique est de dire que factorielle de 0 est 1 et que factoriel de n est n * factorielle de n-1. En haskell, ça s'écrit comme ça :

Code :

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

1
2
fact 0 = 1
fact n = n * fact (n - 1)

Faire du C++ en le limitant aux procédures, c'est pas très beau et certains objets apparaissent quand même. C'est génant pédagogiquement d'expliquer l'écriture « f.getline() » ou « s.c_str() ». On sent que les étudiants les plus borderline (pardon pour l'anglicisme) se sentent mal à l'aise et ne comprennent pas ce qu'on fait. On peut leur dire « laisser faire, on vous expliquera plus tard » mais c'est pas très pédagogique non plus.

Bof, de toute façon on ne peut pas tout leur expliquer d'un coup en C non plus... Après 4 séances de C, les débutants ne comprennent toujours pas ce que signifie main() {} et comprennent encore moins pourquoi gcc leur retourne des warnings (si l'on compile avec -Wall) à cause de ce main(). On pourrait dès le début leur faire écrire int main(int argc, char** argv) mais là il ne comprendrait pas les paramètres ni le return 0 à la fin...
Il faut toujours faire des choix quand on enseigne la programmation, le C n'échappe pas à la règle.

[millie]

là je ne suis pas tout à fait d'accord, si on veut quelque chose proche des mathématiques, autant faire du fonctionnel plutôt que du procédiral. J'aime beaucoup l'haskell pour ce genre de choses. Il permet vraiment de formaliser la pensée mathématique. Par exemple, pour les factorielles, la définition classique est de dire que factorielle de 0 est 1 et que factoriel de n est n * factorielle de n-1. En haskell, ça s'écrit comme ça :

Code :

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

1
2
fact 0 = 1
fact n = n * fact (n - 1)

Pourquoi ressort on toujours l'exemple de la factoriel ? C'est une fonction tellement simple que ce n'est pas marrant.

Si l'on réflechit à un vrai problème, c'est au contraire souvent beaucoup plus délicat de donner une solution purement fonctionnelle.
Par exemple : serveur d'échanges de fichier, je te mets au défi de trouver des implémentations purement fonctionnelles.
En parlant d'outils mathématiques, si l'on travaille avec des matrices, on voit plutôt un parcours de tous les champs un par un sous forme impérative que sous forme fonctionnelle (même si des algorithmes fonctionnels existent, ils sont en général moins naturel)

Si l'on doit ajouter à une matrice le numéro de ligne pour chaque cas, tu penses plutôt :

Code :

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

1
2
3
4
for(int i=0; i<matrice.largeur(); i++)
  for(int j=0; j<matrice.hauteur(); j++) {
     matrice(i,j) += i;

Ou :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
fonction Matrice somme(Matrice m) {
 retourner sommeAux(m, 0,0);
}

fonction Matrice sommeAux(Matrice m, int i, int j) {
  if(j==matrice.hauteur())
    retourner matrice;
  if(i==matrice.largeur())
    retourner sommeAux(m, 0, j+1);
  retourner sommeAux(ajouter(m, i,j, i), i+1, j);
}

[LLB]

Pourquoi ressort on toujours l'exemple de la factoriel ? C'est une fonction tellement simple que ce n'est pas marrant.

Il montre bien la différence de raisonnement. Mais c'est vrai que c'est limité comme exemple.

Par exemple : serveur d'échanges de fichier, je te mets au défi de trouver des implémentations purement fonctionnelles.

Tout simplement parce que la programmation fonctionnelle est peu utilisée. Je ne vois pas le problème avec cet exemple.

Si l'on doit ajouter à une matrice le numéro de ligne pour chaque cas

Ton exemple est très moche.

À titre personnel (et tant que possible, je privilégie le fonctionnel pur), j'écrirais (F#) :

Code :

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

Array2.map ((+) 1);;

C'est très fonctionnel : il n'y a pas d'effet de bord, il y a une fonction d'ordre supérieur et il y a une évaluation partielle. C'est également plus sûr : il n'y a pas de problème de dépassement (qui arrive quand on se trompe dans les indices).


Edit : Il ne faut croire que fonctionnel = récursif. Quand je peux éviter la récursion, je le fais et je passe par une fonction d'ordre supérieur. Si je devais écrire une factorielle, j'écrirais plutôt (Haskell) :

Code :

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

product [1..n]

[millie]

Je ne vois pas le problème avec cet exemple

Je pense que l'approche des personnes ne manipulant pas un langage fonctionnel tous les jours va imaginer un processus impératif :

Si le fichier n'est pas déjà chargé en mémoire
ouvrir le fichier
Lire dans le fichier
Envoyer ce qui a été lu
...

Ton exemple est très moche.

À titre personnel (et tant que possible, je privilégie le fonctionnel pur), j'écrirais (F#) :

Code :

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

Array2.map ((+) 1);;

C'est très fonctionnel : il n'y a pas d'effet de bord, il y a une fonction d'ordre supérieur et il y a une évaluation partielle. C'est également plus sûr : il n'y a pas de problème de dépassement (qui arrive quand on se trompe dans les indices).
[/CODE]

Je considèrerai que je ne disposais pas de fonction intermédiaire (sauf somme) pour écrire mon algorithme fonctionnel. Par algorithme purement fonctionnel, j'entends uniquement algorithme n'utilisant pas d'affectation.
Mais heureusement, les langages fonctionnels ne se limitent pas à ça.

[millie]

À titre personnel (et tant que possible, je privilégie le fonctionnel pur), j'écrirais (F#) :

Code :

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

Array2.map ((+) 1);;

Tu es sûr que ça marche ? Mon algo devait ajouter le numéro de la ligne courante et pas 1 à chaque case.

EDIT : Oh oui, mon exemple est aussi inutile que moche

[publicStaticVoidMain]

Bof, de toute façon on ne peut pas tout leur expliquer d'un coup en C non plus... Après 4 séances de C, les débutants ne comprennent toujours pas ce que signifie main() {} et comprennent encore moins pourquoi gcc leur retourne des warnings (si l'on compile avec -Wall) à cause de ce main(). On pourrait dès le début leur faire écrire int main(int argc, char** argv) mais là il ne comprendrait pas les paramètres ni le return 0 à la fin...
Il faut toujours faire des choix quand on enseigne la programmation, le C n'échappe pas à la règle.

A mon avis, ca dépend de la façon dont le cours est donné.
Et si vraiment après 4 séances de C, les étudiants ne comprennent tjrs pas , c'est qu'il y'a un problème.
Et je trouve que les warnings générés avec l'option -Wall de gcc te poussent à vraiment à chercher et à coder proprement.

[LLB]

Ah oui, j'avais lu trop vite. Il faut plutôt écrire :

Code :

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

Array2.mapi (fun i _ -> (+) i)

Je considèrerai que je ne disposais pas de fonction intermédiaire (sauf somme) pour écrire mon algorithme fonctionnel.

Je considère que les fonctions de type map, iter et fold sont aussi fondamentales que le for du C. J'aurais tendance à dire que l'intérêt de la programmation fonctionnelle réside dans les... fonctions. J'ajouterais aussi que ton exemple est légèrement biaisé : tu travailles sur une structure qui a une nature impérative.

Si tu souhaites éviter toute fonction prédéfinie et utiliser une structure impérative, alors oui, un langage impératif se débrouillera mieux. Mais quand on n'a pas les pieds liés, le fonctionnel répond correctement à la plupart des besoins.

Je pense que l'approche des personnes ne manipulant pas un langage fonctionnel tous les jours va imaginer un processus impératif :

Si le fichier n'est pas déjà chargé en mémoire
ouvrir le fichier
Lire dans le fichier
Envoyer ce qui a été lu
...

Je ne vois pas de problème à implémenter ça de façon fonctionnelle.

Code :

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

1
2
3
let fichier = ...
let contenu = ...
send ...

Pour éviter de continuer dans le hors sujet, et si tu n'es toujours pas convaincu, je t'invite à proposer aux défis fonctionnels un problème "typiquement impératif". Jusqu'à présent, les langages fonctionnels s'en sont toujours bien sortis (même pour la programmation réseau).

Je pense que l'approche des personnes ne manipulant pas un langage fonctionnel tous les jours va imaginer un processus impératif :

Je ne sais pas. Je pense que ça dépend beaucoup du premier langage (et comment il est enseigné). Je trouve aussi que le fonctionnel est beaucoup plus "pur" que l'impératif.

[Garulfo]

là je ne suis pas tout à fait d'accord, si on veut quelque chose proche des mathématiques, autant faire du fonctionnel plutôt que du procédiral.[...]

On est complètement d'accord -_-
Je n'ai de cesse de le clamer à qui veut l'entendre.

Mais bon, dire à une assemblée des profs « on va faire du procédural dans le premier cours comme ça on garde C++ » passe beaucoup mieux que « on va faire du fonctionnel alors il faut prendre du Scheme » ^_^

[Garulfo]

Pourquoi ressort on toujours l'exemple de la factoriel ? C'est une fonction tellement simple que ce n'est pas marrant.

Si l'on réflechit à un vrai problème, c'est au contraire souvent beaucoup plus délicat de donner une solution purement fonctionnelle.

Le factoriel est surtout un très mauvais exemple a priori puisqu'il y a une solution simple avec un simple for.

Par contre, je te ferais remarquer que 2000 ans de mathématique on été faite en fonctionnel... donc dire que c'est plus délicat semble un peu surfait. Il y a certes des problèmes qui peuvent te sembler moins aisé, mais as-tu pratiqué longtemps le fonctionnel pour trouver une réponse à ce que tu donnes ?

Parce que si tu regardes l'histoire des mathématiques, la solution de ta somme de matrice a déjà été défini de manière purement fonctionnel... Bien avant qu'on ait réfléchi à la possibilité de le faire autrement. En fait personne, il y a 100 ans n'aurait réfléchi comme tu viens de le faire.
Comment se fait-il si c'est plus simple en itératif ? Ton exemple est donc très mauvais, autant que le factoriel est un mauvais exemple pour montrer l'intérêt des fonctions récursives (car c'est ça que ça montre). Si je veux montrer l'intérêt du récursif, je leur fait dessiner une fractale. Et là, il n'y a pas photo.

Je ne dis pas que le fonctionnel est la seule chose à apprendre... attention. Il faut multiplier la connaissance des outils pour choisir le plus approprié dans une situation. Mais le fonctionnel a l'énorme avantage d'avoir été présenté aux étudiants depuis qu'ils font des maths.

[millie]

je t'invite à proposer aux défis fonctionnels un problème "typiquement impératif"

Je n'ai jamais dit que les langages fonctionnels ne savaient pas résoudre tous les problèmes, même des problèmes à solutions typiquement impérative. Heureusement d'ailleurs

Parce que si tu regardes l'histoire des mathématiques, la solution de ta somme de matrice a déjà été défini de manière purement fonctionnel...

Pourtant, la définition mathématique classique ressemble plutôt à ça :

Soit M de Mn,m(K) une matrice, on définie M' de Mn,m(K) tel que :
Pour tout i de [1,n], pour tout j de [1,m], M'(i,j) = M(i,j)+i

Ou version avec fonction :

On définie la fonction f de Mn,m(K) à valeur dans Mn,m(K) tel que pour toute matrice M de Mn,m(K), f(M) est l'unique matrice vérifiant pour tout i de [1,n], pour tout j de [1,m], f(M)(i,j) = M(i,j)+i

Ce qui me semble plus naturel pour un mathématicien.

[Jean-Marc.Bourguet]

J'avais compris la question de celui qui a créé le fil comme : quel est le meilleur langage pour apprendre (et comprendre) la programmation ?

Cette question est beaucoup plus vaste. Et necessite de la qualification, meme en restreignant a une perspective d'enseignement -- ce qui ne me semble pas etre la situation du message initial (mais apres 5 ans et le posteur initial qui n'a toujours que 2 messages, je ne suis pas sur qu'il faille toujours se concentrer sur cela) -- un cycle long a plus de latitude qu'un cycle court et il faut voir les contraintes apportees par le reste du curriculum.

Faire du C++ en le limitant aux procédures, c'est pas très beau et certains objets apparaissent quand même.

Pourquoi?

C'est génant pédagogiquement d'expliquer l'écriture « f.getline() » ou « s.c_str() ».

Je ne vois pas le probleme (a part que les deux exemples ne devraient pas se retrouver dans du code a expliquer a des debutants; on n'a pas a manipuler des pointeurs tant que le reste n'est pas acquis, ce qui est le gros probleme du C : impossible de faire quoi que ce soit d'un peu interessant sans passer par des pointeurs et on est force de les expliquer plus ou moins alors que les concepts sur lesquels ils se basent ne sont pas acquis). On a trois notations pour l'appel de fonction (f(a, b); a.f(b); a f b); une proche de l'appel de fonction classique, une proche des operateurs et une derniere qui favorise une des operandes et qui permet des choses en plus qui elles seront vues plus tard). Pour le genre d'approche du C++ qui me semble etre a conseiller avec des tout debutants, voir par exemple Accelerated C++.

[gege2061]

on est force de les expliquer plus ou moins alors que les concepts sur lesquels ils se basent ne sont pas acquis).

Parce qu'il faut que soit visuel pour intéresser les gens. Les cours/tuto commencent donc par des printf (merci à ce sacro-saint hello world) et ensuite pour pouvoir jouer, on passe au entrée (scanf c'est super simple : saisie de nombre et de chaîne de caractère avec la même fonction).

Il n'y aurait pas de problème si on commençais par la base : les fonctions, on arrive aux paramètres puis tout naturellement aux pointeurs. Après ça on peux jouer

[millie]

Parce qu'il faut que soit visuel pour intéresser les gens. Les cours/tuto commencent donc par des printf (merci à ce sacro-saint hello world) et ensuite pour pouvoir jouer, on passe au entrée (scanf c'est super simple : saisie de nombre et de chaîne de caractère avec la même fonction).

Il n'y aurait pas de problème si on commençais par la base : les fonctions, on arrive aux paramètres puis tout naturellement aux pointeurs. Après ça on peux jouer

Le premier TP de C que j'ai fait était assez violent.
On est arrivé à écrire le code suivant :

Code c :

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

1
2
3
4
5
6
7
8
9
10
11
 
#include <stdio.h>
#include <stdlib.h>
 
int main(void) {
  int * i = NULL;
  printf("Hello world");
  i* = 3;
 
  return EXIT_SUCCESS;
}

Et devinez la question ? Pourquoi la chaine Hello world ne s'affiche pas.

Les cours étaient très orientés sur des parties techniques délicates à appréhender plutôt qu'un apprentissage rapide des fonctionnalités du C sans vraiment savoir comment ça fonctionnait en dessous (en prenant les matchs un par un)

[gorgonite]

Et devinez la question ? Pourquoi la chaine Hello world ne s'affiche pas.

Les cours étaient très orientés sur des parties techniques délicates à appréhender plutôt qu'un apprentissage rapide des fonctionnalités du C sans vraiment savoir comment ça fonctionnait en dessous (en prenant les matchs un par un)

on n'a jamais dit que les écoles d'ing ne manquaient pas de pédagogie

[souviron34]

bon j'interviens juste un p'tit peu, puisque de toutes façons mon opinion (et mon age) me mettent dans la catégorie des vieux croutons...

En ce qui concerne la question originale, j'aurais tendance à dire (par histoire personelle) :

le Fortran pour plusieurs raisons

Quasi le plus ancien et toujours en usage
introduit toutes les notions nécessaires (variables, fichiers, tableaux, programmes, sous-programmes, fonctions, données partagées)
simple
strict

(plus utilise quelques notions utiles pour la suite (équivalences par exemple))


Puis,


passer au C :

chemin logique, mêmes notions, plus 2 : les pointeurs et les void.

et enfin si on veut au C++..


Je ne suis absolument pas d'accord que c'est "proche du système". Et par rapport aux remarques sur les langages fonctionnels, je me permet de soulever que l'écriture d'une équation mathématique en Fortran ou en C est beaucoup plus semblable à ce qu'on écrit sur du papier qu'à ce que je vois d'expressions utilisées par Haskell (entre autres).

Une fois ces 2 langages introduits et maîtrisés, on a à sa disposition la CONNAISSANCE de COMMENT en gros PEUT fonctionner un programme (avec le fonctionnement de la mémoire, les entrées/sorties, etc).

Là on peut s'occuper de choses comme de l'objet ou du fonctionnel.

Ce qui m'attriste beaucoup dans un GRAND nombre de cas que je vois de gens n'ayant appris que du C++ c'est qu'en gros ils n'ont aucune notion des LIMITATIONS imposées par la machine, et que quel que soit leur code, il sera retranscrit en langage machine, et donc qu'on ne peut pas faire PLUS que ce que peut faire la machine...

La deuxième chose qui m'attriste est que (et j'en ai le cas en ce moment même sous les yeux) on peut faire ENCORE PLUS COMPLIQUE en C++ qu'en C, car les classes, les composantes, les iterateurs, et autres méthodes ne sont que des OUTILS... Ce qui est important est la MODELISATION et la pensée cohérente de ce qu'on veut faire...

Donc un découpage en classes et une programmation à base de composantes n'est DE LOIN pas forcément plus claire et compréhensible qu'un découpage fonctionnel bien fait..


NB: je suis CERTAIN que quasi-personne ici-même ne se rend compte que les COMMON Fortran existent sur tous les systèmes (au moins unixoides) et sont gérables par TOUS les langages...(par principe même)....

[Jedai]

Je ne suis absolument pas d'accord que c'est "proche du système". Et par rapport aux remarques sur les langages fonctionnels, je me permet de soulever que l'écriture d'une équation mathématique en Fortran ou en C est beaucoup plus semblable à ce qu'on écrit sur du papier qu'à ce que je vois d'expressions utilisées par Haskell (entre autres).

Tu es déformé par tes années de programmation impérative, rien que pour définir une suite simple :

Code :

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

1
2
u 0 = 5
u n = 4 * u (n-1) / sqrt 3

M'apparait bien plus proche de la notation mathématique que :

Code :

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

1
2
3
4
5
6
7
8
double u(int n) {
  if( 0 == n ) {
    return(5);
  }
  else {
    return(4 * u(n-1) / sqrt(3));
  }
}

...

--
Jedaï

[Woufeil]

Attention, je ne me fais pas le défenseur du fonctionnel, je dis juste que je trouve le fonctionnel beaucoup plus proche de la pensée mathématique que l'impératif
Un autre exemple, toujours aussi mathématique : la fonction dérivée (très très naïve, je vous l'accorde) :

Code :

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

deriv f h = \a -> (f (a + h) - f a) / h

Une fois qu'on sait que \ signifie en gros fonction, on peut presque lire la ligne comme ceci : la dérivée de f avec un pas de h est égale à la fonction qui à a associe f de a + h - f de a sur h, exactement la définition mathématique.

Après, dès qu'on s'éloigne des mathématiques, je trouve que l'impératif est très adapté aux problèmes informatiques, comme pour reprendre l'exemple de millie les serveurs :

Code Perl :

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
my $serveur =  IO::Socket::INET->new ( LocalPort => 3000, Type => SOCK_STREAM, Reuse => 1, Listen => 5) or die "Problème serveur : $!";
my $chaine;
while (my $client = $serveur->accept()) {
	my $pid = fork;
	unless ($pid) {
		while (1) {
			print $client "Entrez le nombre dont vous voulez connaître le carré : ";
			$chaine = <$client>;
			exit unless defined $chaine;
			chomp ($chaine);
			if ($chaine =~ m/^\d+\r?$/) {
				my $rep = "Le carré de $chaine vaut ".$chaine * $chaine;
				print $client "$rep\n";
			} 	
			else {
				print $client "Erreur !\n";
			}
		}
	}
}

Difficile de faire plus compréhensible...

Pour publicStaticVoidMain : tu es sûr que tu te rappelles de tes débuts en informatique ??? Sachant qu'il y a des personnes qui ont moins de 16h de programmation derrière eux (premiers cours, comptez dans les séances l'historique et les divergences), tu veux déjà leur faire apprendre comment accéder aux paramètres de main() ? Je ne voudrais pas t'avoir comme prof dans une matière que je ne maitrise pas...

Pour revenir sommairement au sujet, je dirais que c'est bien plus une question de pédagogie que de langage... J'ai très mal appris (en autodidacte je précise) le C++ par exemple : je me suis retrouvé dans un code C++ à faire mes chaînes de caractère avec des tableaux de char, je n'ai quasiment rien vu de la STL (même pas les vector et les lists, c'est dire !)... Globalement, je trouve que le C++ est trop souvent mal enseigné en tant que premier langage : comme du C avec des classes...

Apprendre le C en premier langage se défend aussi très bien, je ne vais pas redonner les arguments de chacun.

[LLB]

Après, dès qu'on s'éloigne des mathématiques, je trouve que l'impératif est très adapté aux problèmes informatiques, comme pour reprendre l'exemple de millie les serveurs

Que reproches-tu à la solution Caml de bluestorm (voir ici) ? Encore une fois, je n'ai pas trouvé les langages impératifs plus adaptés que les langages fonctionnels sur cet exemple.

Je n'ai jamais dit que les langages fonctionnels ne savaient pas résoudre tous les problèmes, même des problèmes à solutions typiquement impérative.

Bien sûr : on peut tout implémenter dans les deux paradigmes. Mais ton exemple ne m'a pas semblé convainquant. D'ailleurs, les défis jusqu'à présent m'ont plutôt convaincu que C++, C#, Java et compagnie n'ont absolument rien à m'apporter (sauf le C++ en cas de contraintes particulières, comme les performances).

Je ne suis absolument pas d'accord que c'est "proche du système".

Pourtant c'est le cas. Qu'est-ce qu'un pointeur ? Ce n'est absolument pas une abstraction, c'est une notion bas-niveau. Comment fait-on le type string en C ? Ca me semble relativement proche du système, non ? Qu'est-ce qu'un malloc ? Une vague surcouche à l'appel système brk... Comment fait-on la gestion d'erreurs en C ? En modifiant un entier global comme errno, ou en ne faisant rien... c'est alors le système qui choisit (ou non) d'envoyer un signal en cas de problème. Tout ça est extrêmement près du système.

À l'opposé, un langage comme Lisp n'a pas été conçu à partir de l'assembleur, mais plutôt à partir d'un modèle théorique. En Lisp, on ne se pose pas la question de déplacer des pointeurs ou de mettre un 0 à la fin d'une chaine. On se fiche aussi de mot-clefs comme sizeof.

Utiliser un langage comme le C nécessite de comprendre le fonctionnement du système. Utiliser un langage fonctionnel nécessite de connaitre les bases du raisonnement.

[Garulfo]

[...]
Je ne vois pas le probleme [...]. On a trois notations pour l'appel de fonction (f(a, b); a.f(b); a f b); une proche de l'appel de fonction classique, une proche des operateurs et une derniere qui favorise une des operandes et qui permet des choses en plus qui elles seront vues plus tard). Pour le genre d'approche du C++ qui me semble etre a conseiller avec des tout debutants, voir par exemple Accelerated C++.

Je pense que tu ne te rends pas comptes à quel point la notation a.f(b) est stressante pour qqs qui a déjà du mal à écrire

Code :

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

1
2
3
4
int f (int x, int y) 
{
    return x+y ;
}

Peut-être n'as tu jamais eu de problème sérieux en débutant l'informatique. Je suis dans cette catégorie aussi ayant commencé à 10 ans. Mais quand qqun n'a jamais fait d'informatique, changer l'écriture est parfois synonyme de suicide.

Maintenant

Code :

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

s.c_str()

est aussi nécessaire si tu veux pouvoir ouvrir un fichier avec un nom mis dans une string, sachant que les tableaux de caractères sont plus une plaie qu'un plaisir. Encore une fois, il faut que tu te mettes au niveau de personne qui viennent de bio par exemple et qui ont un cours obligatoire en C++... la vie n'est pas toujours drôle pour eux dans ce cours

[Woufeil]

Que reproches-tu à la solution Caml de bluestorm (voir ici) ? Encore une fois, je n'ai pas trouvé les langages impératifs plus adaptés que les langages fonctionnels sur cet exemple.

J'avais fait exprès de ne pas dire que les langages impératifs étaient plus adaptés que les langages fonctionnels pour ce type d'applications
Les deux paradigmes sont bien entendu envisageables. C'était juste pour préciser que je ne dénigrais pas l'impératif.

C'est terrible, dès qu'on dit qu'un paradigme est bien, on nous rétorque que l'autre aussi