Discussion :

[gorgonite]

Et, au fait, tu arrives à battre Delphi (vilain langage impératif dérivé du Pascal) côté nombre de lignes écrites pour résultat produit ? Le record à battre est un programme fonctionnel et interactif avec zéro ligne de code écrite par le développeur...

merci de ne pas le laisser repartir sur une autre polémique... donc oui, c'est possible dans des domaines très spécifiques (langages synchrones utilisant des signaux, et ayant une syntaxe fonctionnelle)

[Mac LAK]

merci de ne pas le laisser repartir sur une autre polémique... donc oui, c'est possible dans des domaines très spécifiques (langages synchrones utilisant des signaux, et ayant une syntaxe fonctionnelle)

C'était juste pour montrer qu'au jeu du "kikikaleplugro", la palme n'est tenue ni par l'impératif, ni par le fonctionnel, mais par les RAD... Ce serait même amusant d'ailleurs de voir jusqu'à quel point je pourrais farcir une fiche Delphi de composants sans jamais écrire la moindre ligne de code à la main, et d'uploader ensuite l'exécutable ici, tiens...

Et donc, que mesurer le nombre de lignes de code n'a pas beaucoup d'intérêt, l'important étant plutôt le temps passé à les écrire et le temps de recherche diverses et variées nécessaires à cette écriture (notamment dans la doc du langage).

[Jedai]

Oui, je sais. Je ne suis toujours pas d'accord, un ordinateur n'est pas une télé avec un clavier, il est important de savoir un peu comment ça marche à l'intérieur.
De plus, coder de façon "élégante, lisible, modulaire et correcte" est possible dans absolument tous les langages, notamment en Pascal et en Ada que je défends en tant que langages d'initiation.

Tout à fait d'accord, il est important que l'informaticien sache un peu comment un ordinateur marche, il apprendra ça en cours d'architecture des ordinateurs (habituellement ces cours sont accompagnés de TP où on fait de la programmation bas niveau). En attendant il apprendra plus d'algorithme et les comprendra mieux s'il utilise un langage de haut-niveau pour ce faire.

Si ta fonction ne renvoie pas toujours le même résultat pour les mêmes entrées, faudrait peut-être voir à virer les variables globales / statiques du code, non ?

Je ne vois pas en quoi essayer de virer les variables globales de ton code est risible, tous les programmeurs impératifs expérimenté que je connaîs évitent les variables globales autant que possible parce qu'ils créent des interdépendances entre des parties du programmes apparemment indépendantes.

Mais bon, redevenons sérieux : tu as des exemples de fonctions (en programmation impérative) qui ne renvoient pas les mêmes données avec les mêmes entrées ? N'oublie pas que l'environnement fait partie des entrées, si tu l'utilises dans ta fonction...

L'environnement ne fait pas partie des entrées explicites en impératif, il est un argument implicites de toutes les fonctions, ce qui signifie qu'il faut connaître le code d'une fonction ou faire confiance à la documentation pour être certain qu'une fonction ne va pas changer de comportement si votre petit frère toto a créé un fichier dans le répertoire /blougaboulga... Les fonctions Haskell ne prennent pas l'environnement comme argument implicitement, seules les actions IO le font, ce qui signifie qu'on peut regarder le type d'une fonction et être certains que seuls ses arguments explicites sur lesquels on a un contrôle parfait (contrairement à l'environnement) vont influencer son résultat.

Moi, au contraire, j'ai toujours eu plus facile d'expliquer le principe des fonctions en donnant l'analogie d'une fonction mathématique (f(a) est constant tant qu'on ne modifie pas "a" ni "f", dans le cadre commun accessible à la plupart des gens) que d'expliquer qu'une fonction est un programme et que son fonctionnement est altéré par d'autres fonctions qui n'ont à priori rien à voir dans l'affaire... La plupart des gens pensent plus facilement en séquentiel (=impératif, donc) qu'en fonctionnel.

Pourquoi "au contraire" ? Tu es en train de dire que tu as toujours trouvé plus facile d'expliquer une fonction selon le point de vue fonctionnel (fonction mathématique) que selon le point de vue impératif (programme, recette séquentielle)... Autrement dit tu sembles être d'accord avec moi.

Comme je l'ai déjà dit et répété des dizaines de fois : être extrémiste et/ou faire du prosélytisme pour l'ultra-bas (ou ultra-haut) niveau n'apporte RIEN DE BIEN. Apprenez aux étudiants un langage médian, montrez-leur des portes vers chaque "univers" de la programmation, et foutez-leur la paix dans leurs choix par la suite.

Je trouve qu'un langage médian, mi chèvre mi choux, n'est pas un bon choix parce que justement il permet de mélanger le bas et haut niveau, entretient la confusion, tout en étant limité dans une direction comme dans l'autre. A mon sens un langage haut niveau strictement typé pour apprendre la programmation, l'algorithmique et la rigueur nécessaire pour la suite tandis qu'on suit également un cours d'architecture des ordinateurs avec quelques TP dans un langage de bas niveau est une meilleure approche.

Je ne défends pas le bas niveau par "intégrisme", mais parce que certains voudraient faire croire qu'il ne sert à rien, ce qui est une bêtise sans nom... Les deux aspects du développement ont leur avantages, inconvénients, et rôle.

Certes, personne n'a dit le contraire, et personne n'a dit que le bas niveau était inutile, ce n'est d'ailleurs pas le sujet du débat.

Pour des débutants il vaut mieux parler d'effets de bord, plutôt que de "paradigme impératif vs paradigme fonctionnel", qui tient plus de la querelle de théoriciens.

Certes, mais je n'avais pas l'intention de le présenter ainsi à des débutants, nous employons ces termes ici parce que nous essayons d'être précis et que les participants sont censés être expérimentés.

Pour en revenir strictement au sujet du débat, je pense que LISP est un excellent langage aussi bien pour débuter l'apprentissage de la programmation que pour voir, plus tard, certains aspects avancés (macros puissantes, CLOS,
boucle read-eval, persistance des données, fonctions de première classe, etc)

Donc tu serais plutôt partisan d'apprendre avec un langage de haut niveau, fonctionnel ?

C'est surtout faux : "t" est un pointeur, donc il faut avec traîner l'environnement qui va avec... Donc, la mémoire aux alentours de "t", notamment la première valeur.

Exact, et c'est justement ce que nous reprochons à cette approche : dans ces langages impératifs rien ne permet de distinguer de l'extérieur une fonction pure dont le résultat ne dépend que de ces paramètres explicites d'une fonction impure qui peut globalement renvoyer n'importe quoi (puisqu'on n'a pas un contrôle complet sur l'environnement).

La plupart des gens (au sens ci-dessus) à qui on explique ça te demanderont pourquoi tu utilises un truc aussi bordélique qu'un max de tous les fils alors qu'il est si simple de parcourir l'arbre...

Tu dois vraiment avoir l'esprit déformé par le paradigme impératif si tu trouve "max de la profondeur de tous les fils" plus bordélique que "prof <- 0; h <- 0; parcourir l'arbre en ajoutant 1 à h à chaque fois qu'on descend et si h > prof alors prof <- h" et encore, je n'ai pas spécifié comment on parcourt l'arbre.

L'environnement, c'est vaste... Ce n'est pas que l'environnement dans le genre "variables d'environnement". Si tu préfères, remplaces-le par "contexte système", c'est à dire peu ou prou la somme de l'état logiciel de la machine (= ce qui est sauvé sur ton dur en mode Hibernation), plus l'état électronique courant de la machine (= non sauvable).

Oui, c'est bien le problème, il est si vaste qu'on a peu de contrôle dessus...

Tu crois sincèrement que le concept d'environnement en tant que paramètre d'une fonction est "nouveau" et introduit par les langages fonctionnels comme Haskell ? J'ai du mal à croire que tu puisses être sérieusement convaincu de ceci, alors que c'est une base commune de tous les langages bas niveau depuis qu'ils existent...

D'une part ce n'est pas ce que Alex-pi a dit, d'autre part ce "concept" n'est pas intégral à la conception des langages de bas niveau, il est apparu en même temps que les tentatives d'attribution d'une sémantique formelle à ces langages, où l'on s'est aperçu qu'il s'agissait d'une tache souvent difficile et rendu bien moins intéressante par ce manque de distinction entre fonctions pures et impures.

--
Jedaï

[alex_pi]

Oui, l'exécution d'un code est reproductible à l'infini tant que l'environnement (y compris réduit à quelques octets de mémoire épars) reste identique. C'est juste le principe de base des tests et de la validation.

Arghl Faut s'accrocher avec un phénomène comme toi hein. Ce qu'on te dit c'est que dans un langage fonctionnel pure comme haskell, il n'y a PAS de paramètre implicite. Que l'application d'une fonction ne dépend que de ses arguments. Des vrais arguments. Pas de la couleur du ciel, pas de l'action faite juste avant. Des arguments et de rien d'autre.
On parle de débutants ici. Comment est ce que tu peux prétendre que dire à un débutant
"L'application de f à x retourne toujours la même chose"
et
"L'application de f à x retourne toujours la même chose à condition que tu n'aies rien changé, ce qui est impossible puisque la base même de la programmation impérative est de changer les chose"
c'est pareil ? Si tu arrives à prétendre que c'est pareil, tu as gagné, j'abandonne et te classe définitivement dans la catégorie des mecs les plus bornés du monde.

Mets des lunettes alors, ou nettoie ton écran. Ta fonction déréférence un pointeur, donc forcément, la mémoire déréférencée fait partie de l'environnement de la fonction. En l'occurrence, sur l'exemple précis, l'environnement se limite très exactement à l'int situé à l'adresse "t".

ET DANS LE CAS D'UNE LISTE CHAINÉE ? J'ai deux liste chainées l1 et l2. Je calcule la somme des éléments de l1, j'obtiens un résultat. Je change l'élément de tête de l2. Je calcule la somme des éléments de l1. Le résultat peut avoir totalement changé. Tu trouves que c'est la chose la plus naturelle a expliquer à un débutant ?

Et tant que tu ne changeras pas ce tableau, la somme restera constante... Je ne vois vraiment pas le problème, en fait, sauf que tu essaies de faire croire qu'un code impératif retourne des valeurs plus ou moins "aléatoires" à données d'entrée égales.

Non, ce que je dis, c'est qu'à données d'entrée égale (le même tableau) la valeur est différente. Elle n'est pas aléatoire, juste non constante. Elle dépend du passé, voir même de se que tripatouille un autre thread.

Tu as mal compris le concept d'effet de bord de l'impératif, je pense, tu devrais réviser un peu.

JE n'ai pas compris le concept d'effet de bord ? Je dis que quand on appelle deux fois une fonction, le résultat peut varier à cause d'un effet de bord, mais je n'ai pas compris ce que c'est ?

Donnes-moi des exemples (sans utiliser "rand()" ou des fonctions d'horloge bien sûr), alors ! Non, ce n'est pas "courant". C'est toi qui est de mauvaise foi en ne sachant pas ce qu'est l'environnement d'une fonction. Ou alors, t'as jamais réussi à le comprendre, d'où ta "haine" des langages bas niveau et impératifs ?

En quoi "rand()" diffère de la lecture du premier élément d'un tableau ? Tu sais, tu nous expliquait si doctement que "l'environnement faisait partie des arguments de l'appel de la fonction". Donc rand est une fonction qui retourne toujours le même résultat, puisque l'était interne du compteur fait partie des arguments implicite. C'est beau hein cette vision du monde...

Et on ne saura jamais la suite...

Je ne pense pas que dire à un débutant que toute fonction, quel qu'elle soit, a un argument implicite qui est "l'intégralité de l'environnement pouvant potentiellement affecté son exécution" (cet environnement ayant d'ailleurs une définition plus que floue, puisque justement il dépend de l'environnement, qui lui même dépend de l'exécution des autres fonctions, qui elle même...) soit un plus.
Et on parle de débutant, mais même pour un non débutant, pouvoir se détacher de l'environnement est un plus non négligeable. (Mais j'imagine que quand les gars de chez Intel expliquent que l'avenir pour la programmation multi-coeur, c'est le paradigme fonctionnel, c'est parce que c'est une grosse bande de charlots qui ne comprennent rien au bas niveau)

C'est standard, ça, "fst" ? Moi, je ne connais pas.
A moins que tu ne veuilles dire "get_first" ? Houlà, mais tu codes crade !!! "GetFirst", ou mieux : "Get(Tab,Index)".
Et après, ça donne des leçons sur l'impératif...

http://haskell.org/ghc/docs/latest/h...ude.html#v:fst
http://caml.inria.fr/pub/docs/manual...es.html#VALfst

Convention de nomage différente = coder crade. Nan c'est sûr, c'est bien. On va progresser comme ça. Nan et puis en plus ça change le fait que la fonction retourne une valeur différente sur le même argument, c'est sûr.
Enfin t'es quand même d'accord que "return a[0];" est la bonne solution maintenant ?

Yep. On n'est pas en maths, là, on est en informatique, au fait...

Et ? Comment on fait pour programmer sans aucune notion de maths ? Comment on fait pour prouver que son algo ne fait pas de la merde si on ne comprend rien à la notion de récursion, d'induction structurelle ? Si on ne sait pas ce qu'est une fonction ? Ah bah oué, on fait pas. On regarde le programme et on se dit "bah, ça doit bien marcher". Et puis de toutes façons, puisqu'on a mis des optims bas niveau, on ne peut plus rien prouver.
Parce que pour le débutant, lui inculquer qu'un algo, ça se PROUVE, ça ne fait pas que se coder, il faudrait peut être lui fournir les outils pour. Genre des bases de maths, et un langage qui s'y prête. Et non, prouver l'algo sur du pseudo-code puis l'implémenter dans un langage qui n'a plus rien à voir n'est pas une bonne solution. Il y a qu'à voir le nombre monstrueux de faille qui sont dues à des implems foireuse alors que l'algo de base était correct.
Et oui, je pense qu'un langage de haut niveau est bien plus adapté qu'un langage "médian" pour prouver ses algos, ce que tout débutant un peu sérieux (qui suit des cours, pas l'auto-didacte, et encore) devrait faire.

Sinon, j'avoue que je serais assez surpris de voir ta fameuse "constance" des résultats en Haskell sur une lecture de fichier ou une réception de socket, par exemple... Toujours les mêmes paramètres, et résultats différents à chaque fois, ça doit t'agacer...

Ca n'agace personne, parce que le système de type indique que le résultat provient d'un effet de bord. La lecture au clavier produit une IO string et pas une simple string. Il n'y a aucun moyen d'oublier que ça vient de là et d'en faire n'importe quoi. Personne ne peut se tromper, ni le débutant, ni le programmeur experts.

Et le résultat, t'en fais une guirlande ? Soit tu l'utilises (ce qui revient peu ou prou à une affectation, même si c'est juste "affecté à un paramètre de fonction"), soit tu ne l'utilises pas (et dans ce cas, pourquoi l'avoir calculé ?).

C'est sur qu'en disant que tout est pareil, on n'arrive à dire que rien n'est différent... Mais non, définir une fonction par une succession de modification d'emplacement mémoire, et la définir par composition de fonction, ce n'est pas la même chose.

Le terme "branchement" est le terme "consacré"... Cela peut aussi bien recouvrir un saut (JMP) qu'un appel (CALL). Dans tous les cas, le PC (Program Counter) est modifié, c'est ça la définition d'un branchement.

Donc un no-op, c'est un branchement, puisque le compteur est incrémenté de 1. \o/
Nan mais je pense effectivement que pour expliquer à un débutant ce qu'est une fonction, lui dire "en fait on pousse les arguments dans la pile, du moins ceux qu'on n'a pas pu affecter aux différents registres, on sauve le PC, et après on saute au code de la fonction", c'est vachement plus clair que lui expliquer ce qu'est un appel de fonction d'un point de vue un poil plus abstrait : "pour calculer "f(3)", tu exécutes le corps de la fonction en remplaçant partout x par 3".
Tu as aussi des branchements dans les boucles, les sorties de boucles, les retours de procédures / fonctions, les tests... "Branchement" est le terme générique recouvrant tout ça.

Encore une fois, le troll reparaît... C'est la manière d'expliquer l'opération qui est trop mathématique pour la plupart des gens.

max, c'est trop mathématique ??

Je l'ai bien dit : cela revient à la même chose au final car il n'y a pas beaucoup de manières de calculer la hauteur d'un arbre.

Alors vas y, dis nous juste comment tu expliques à un débutant ce qu'est la hauteur d'un arbre. Quelle est la définition de la hauteur. Parce qu'avant de coder un truc, c'est pas mal de savoir ce que l'on code, histoire de voir si le code colle à la spec. Donc quelle est cette spec ?
Et finalement, comment tu l'implémentes dans ton langage "médian" de façon moins "bordélique" que moi en Caml ?

C'est lié à ton domaine d'activité, et/ou au domaine de prédilection de tes langages... Moi, c'est exactement le contraire, j'utilise assez rarement des arbres en fait. C'est souvent trop lent, comme les listes chaînées, c'est réservé à certains usages particuliers.

Et donc à un débutant, il ne faut pas lui expliquer ce que sont les arbres et les listes chaînées, parce que s'il font des super liens gigabits \\o youhou o// ça risque d'être trop lent ?

[chaplin]

Ce serait intéressant pour les débutants d'avoir un exemple de code sur la hauteur d'un arbre dans les différents langages: C, pascal, langage fonctionnel.
Il n'y a rien de mieux qu'un exemple.

[alex_pi]

Ce serait intéressant pour les débutants d'avoir un exemple de code sur la hauteur d'un arbre dans les différents langages: C, pascal, langage fonctionnel.
Il n'y a rien de mieux qu'un exemple.

En caml :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
(* un arbre est soit une feuille, soit un noeud, contenant un arbre gauche, une valeur et un arbre droit *)
type arbre = Feuille | Noeud of arbre * int * arbre

(* la hauteur d'une feuille est 0, la hauteur d'un noeud est un de plus que le max de la hauteur de ses fils. Le _ est pour signifier que la hauteur ne dépend pas de la valeur du noeud *)
let rec hauteur a = match a with
   | Feuille -> 0
   | Noeud (g, _, d) -> 1 + max (hauteur g) (hauteur d)

(* tests : *)
# hauteur Feuille;;
- : int = 0
# hauteur (Noeud (Feuille, 4, Noeud (Feuille, 42, Feuille)));;
- : int = 2

Voilà

[Mac LAK]

Tout à fait d'accord, il est important que l'informaticien sache un peu comment un ordinateur marche, il apprendra ça en cours d'architecture des ordinateurs (habituellement ces cours sont accompagnés de TP où on fait de la programmation bas niveau).

Chose que n'aura pas quelqu'un dans une filière non-informatique "pure"... Ni un autodidacte, ni un gamin qui veut s'initier à la programmation...

En attendant il apprendra plus d'algorithme et les comprendra mieux s'il utilise un langage de haut-niveau pour ce faire.

Non. La plupart des gens comprennent plus facilement un algorithme décrit sous forme séquentielle, donc proche de l'impératif.

Personne n'a dit que le bas niveau était "nul" sauf toi, nous avons simplement décrié l'intérêt d'apprendre la programmation avec un langage bas niveau ou même "médian" (selon toi). Le bas niveau reste très nécessaire et utile dans certaines circonstances.

Disons qu'à force de faire du prosélytisme pour les langages fonctionnels en décriant tout ce qu'il est possible de faire en bas niveau, on se demande, hein ?
Moi, je te dis que quelqu'un qui a appris à trop haut niveau sera toujours une buse en bas niveau, tout comme quelqu'un qui a appris à trop bas niveau sera toujours une buse à haut niveau. Axiome hélas vérifié sans arrêt...

Je ne vois pas en quoi essayer de virer les variables globales de ton code est risible, tous les programmeurs impératifs expérimenté que je connaîs évitent les variables globales autant que possible parce qu'ils créent des interdépendances entre des parties du programmes apparemment indépendantes.

Ce n'est pas risible, ce qui l'est, c'est de prendre comme "base" de la programmation impérative que tout développeur fait du code de porc à base de variables globales et d'éléments externes non maîtrisés...
Ce qui est à peu près aussi crade que programmer de la récursion en fonctionnel en écrivant à la main les "f(f(f(f(f(f(a))))))", mais bon...

L'environnement ne fait pas partie des entrées explicites en impératif, il est un argument implicites de toutes les fonctions, ce qui signifie qu'il faut connaître le code d'une fonction ou faire confiance à la documentation pour être certain qu'une fonction ne va pas changer de comportement si votre petit frère toto a créé un fichier dans le répertoire /blougaboulga...

Ce qui est le rôle aussi des préconditions, invariants et postconditions que tu es censé écrire dans ta documentation, tout comme tu es censé spécifier quels éléments d'environnement tu utilises dedans (concepts de réentrance et compatibilité multitâche, par exemple).
Faudrait arrêter de croire que tous les programmes impératifs sont écrits comme dans "bidouillez.com", hein...

seuls ses arguments explicites sur lesquels on a un contrôle parfait (contrairement à l'environnement) vont influencer son résultat.

Mmmm... Aucun contrôle sur ton environnement en impératif ? Ah, tiens, première nouvelle !! Tu ne sais peut-être pas le faire, mais ne dis pas que c'est "impossible", stp.

Je me demande vraiment comment on fait pour faire des programmes impératifs qui marchent, et ceci depuis 50 ans, tandis que pendant la même durée (à quatre ans près) les langages fonctionnels n'ont jamais percé "lourdement" au point de déloger la programmation impérative, nettement majoritaire pourtant.

Pourquoi "au contraire" ? Tu es en train de dire que tu as toujours trouvé plus facile d'expliquer une fonction selon le point de vue fonctionnel (fonction mathématique) que selon le point de vue impératif (programme, recette séquentielle)... Autrement dit tu sembles être d'accord avec moi.

La remarque portait sur ta phrase "l'idée que "f(5)" ne renvoie pas toujours la même chose est souvent surprenante pour les débutants". Donc, je demande des exemples de fonctions impératives de ce genre, parce que moi, je n'en connais pas à part les fonctions I/O, aléatoires et de gestion du temps...

Je trouve qu'un langage médian, mi chèvre mi choux, n'est pas un bon choix parce que justement il permet de mélanger le bas et haut niveau, entretient la confusion, tout en étant limité dans une direction comme dans l'autre.

La confusion n'existe que dans l'esprit de celui qui enseigne le langage... Quant à la limite, justement, c'est ce qui est intéressant : ne pas aller TROP loin, tout en ouvrant l'esprit. Si tu veux poursuivre de façon poussée dans un paradigme particulier, tu changes de langage.

Exact, et c'est justement ce que nous reprochons à cette approche : dans ces langages impératifs rien ne permet de distinguer de l'extérieur une fonction pure dont le résultat ne dépend que de ces paramètres explicites d'une fonction impure qui peut globalement renvoyer n'importe quoi (puisqu'on n'a pas un contrôle complet sur l'environnement).

Ce qui contredit ton exemple de "f(5) qui ne renvoie pas la même valeur"... Distinguer les deux ? C'est pourtant l'enfance de l'art (la base aussi d'ailleurs).
Encore faut-il que l'enseignant le sache lui-même !! La première fois qu'un prof m'a expliqué les pointeurs (un ancien prof de maths reconverti, tiens, d'ailleurs...), alors que je savais déjà ce que c'était, j'ai fini par douter et me demander si j'avais bien tout lu tellement il a été confus, peu clair et souvent à côté de la plaque... Et en y passant deux heures de cours, en plus.
J'ai re-expliqué le tout à mes camarades après, en quinze minutes, et tout le monde a pigé du premier coup.

Faudrait quand même arrêter de confondre "difficulté du paradigme impératif" et "absence de pédagogie des enseignants" : ce n'est pas la même chose. Le problème, c'est aussi d'avoir des profs de maths reconvertis en profs d'info, ou des informaticiens formés sur le tas à partir du bas niveau et qui ne savent pas expliquer un concept de haut niveau sans passer par les registres du CPU.

J'ai eu la chance d'avoir des profs formés "à l'école médiane", j'ai nettement vu la différence entre ceux provenant du "haut niveau" et ceux provenant du "bas niveau"... Y'a pas photo.

Tu dois vraiment avoir l'esprit déformé par le paradigme impératif si tu trouve "max de la profondeur de tous les fils" plus bordélique que "prof <- 0; h <- 0; parcourir l'arbre en ajoutant 1 à h à chaque fois qu'on descend et si h > prof alors prof <- h" et encore, je n'ai pas spécifié comment on parcourt l'arbre.

Non, j'ai même bien précisé que ça revenait exactement au même au final. La formulation initiale sera tout simplement prise pour "des maths" par la plupart des débutants, certains se braqueront même directement rien qu'à cause de ça.

Si tu n'arrives pas à expliquer un algo à quelqu'un qui n'a pas de base mathématique, c'est que tu expliques mal.

Oui, c'est bien le problème, il est si vaste qu'on a peu de contrôle dessus...

A toi d'en limiter l'étendue, c'est la base de la modularité et de la réutilisabilité. Cela s'apprend.

D'une part ce n'est pas ce que Alex-pi a dit, d'autre part ce "concept" n'est pas intégral à la conception des langages de bas niveau, il est apparu en même temps que les tentatives d'attribution d'une sémantique formelle à ces langages, où l'on s'est aperçu qu'il s'agissait d'une tache souvent difficile et rendu bien moins intéressante par ce manque de distinction entre fonctions pures et impures.

Ce qui ne change pas grand-chose à l'affaire : le concept existe en impératif depuis le début.
La seule nuance, c'est qu'en impératif, tu peux décider d'en tenir compte ou pas, en fonctionnel tu n'as pas le choix.

Reste après à correctement l'apprendre en impératif (ce qui est l'ouverture vers le fonctionnel, entre autres, tout comme le chaînage d'appels), la programmation parallèle a bien aidé justement à rendre plus "visible" les conséquences d'un code de porc...


Reste le fait suivant : tandis que je recherche à ouvrir l'esprit d'un débutant vers les différents concepts du développement, tu cherches à l'enfermer dans un seul... J'adhère moyennement pour ma part, j'ai toujours eu horreur des œillères posées de force aux gens.

[F.Saad]

Après avoir fait du C#, voudrais tu encore changer de langage ?

Bonne question, je sens qu'une fois le C# Assez bien maitriser , je passerais au LUA.
En fait, ses selon mes besoin et de je que je veut réaliser.

[chaplin]

Quelle a été ta démarche F.Saad au tout début. Quel est ton premier langage et tes premiers essais (réussites, échecs).

alex_pi: je découvre le langage fonctionnel avec ton exemple. A chaud, je dirais que c'est une approche très mathématique, en plus l'exemple utilise la récursivité , c'est peut être pas le meilleur exemple pour démarrer après réflexion. Sinon, pour l'instant j'entrevois deux approches pour cet exemple:
1) procédural et pointeurs.
2) générics et méthodes anonymes (Delphi 2009 ).

Le premier me semble plus "Hack" tandis que l'autre est plus élégant, du moins ce sont les approches que j'ai à l'esprit pour l'instant ... j'en vois pas d'autres.

[SpiceGuid]

Et on parle de débutant, mais même pour un non débutant, pouvoir se détacher de l'environnement est un plus non négligeable. (Mais j'imagine que quand les gars de chez Intel expliquent que l'avenir pour la programmation multi-coeur, c'est le paradigme fonctionnel, c'est parce que c'est une grosse bande de charlots qui ne comprennent rien au bas niveau)

Un fondeur ne peut pas continuer indéfiniment à produire un cpu pour un langage ou un paradigme déterminé. Ça a été tenté pour Lisp, pour Java et pour d'autres et aucun n'a percé durablement. Il y aura peut être un jour du multi-coeur à grande échelle exploité par de la programmation fonctionnelle, dans tous les cas ça restera une techno de niche.

Je me demande vraiment comment on fait pour faire des programmes impératifs qui marchent, et ceci depuis 50 ans, tandis que pendant la même durée (à quatre ans près) les langages fonctionnels n'ont jamais percé "lourdement" au point de déloger la programmation impérative, nettement majoritaire pourtant.

À mon avis c'est une question de divergence sur la notion de lisibilité.

Pour le programmeur impératif la lisibilité c'est avant tout une notion syntaxique, avec pleins de conventions (bien indenter, bien nommer ses variables, toujours utiliser la portée de déclaration la plus petite,...).

Pour le programmeur fonctionnel la lisibilité c'est ces mêmes conventions plus une supplémentaire :

• la preuve de correction du code doit être transparente lors de sa lecture

Les débutants recherchent-ils un tel niveau de lisibilité ?

À mon avis dans leur majorité ils ne le souhaitent pas.
Dans leur majorité les débutants sont autodidactes, souvent même ils arrivent avec une idée naivement ambitieuse dans le genre "je veux concevoir une IA pour un RPG distribué persistant en 3D".
Déjà pour leur faire accepter les bons usages il faut lutter contre le penchant naturel à croire qu'il suffit de l'imaginer pour que l'ordinateur l'exécute.
Les bons usages s'apprennent mieux pas à pas, l'un après l'autre.

Donc je serais plutôt de l'avis de Mac LAK, un programmeur qui a acquis les bons reflexes (bien indenter, bien nommer ses variables, toujours utiliser la portée de déclaration la plus petite,...) est devenu autonome et libre de choisir s'il veut aller davantage du côté de la qualité (par exemple avec un langage déclaratif), du protypage (par exemple avec un langage dynamique), de la programmation système, des web services ....

Ceci dit je suis d'accord pour dire que le principe de récurrence n'est pas assez prégnant dans l'apprentissage de la programmation. Toutefois aller jusqu'à l'imposer à ceux qui se destinent aux web services, non seulement ça me paraît overkill mais surtout je doute que beaucoup l'acceptent.

Evidemment, il y aura toujours des personnes plus motivées et plus douées que les autres, qui n'auront jamais besoin ni qu'on les aide ni qu'on les oriente, et qui débuteront directement avec un langage exigeant.

[Jedai]

Quelle a été ta démarche F.Saad au tout début. Quel est ton premier langage et tes premiers essais (réussites, échecs).

alex_pi: je découvre le langage fonctionnel avec ton exemple. A chaud, je dirais que c'est une approche très mathématique, en plus l'exemple utilise la récursivité , c'est peut être pas le meilleur exemple pour démarrer après réflexion. Sinon, pour l'instant j'entrevois deux approches pour cet exemple:
1) procédural et pointeurs.
2) générics et méthodes anonymes (Delphi 2009 ).

D'un autre côté, traiter les arbres sans récursivité est difficile et bien souvent plus confus qu'avec. Par ailleurs la récursivité n'est pas un concept si difficile, bien que la plupart des apprentissages impératifs de la programmation fasse l'impasse dessus pour des raisons historiques (performances déplorables comparées aux solutions itératives dans les langages impératifs historiquement, bien que ce soit aujourd'hui beaucoup moins vrai) et à cause d'une image trop "mathématique" (mais depuis quand ce mot est-il devenu péjoratif ?).

Note que ta solution (2) est aujourd'hui possible en grande partie grâce à l'influence des langages fonctionnels type ML (large) sur les langages et les standards modernes. Les génériques entre autres sont issues principalement des recherches sur les systèmes de types menées sur des langages fonctionnels à l'origine.

--
Jedaï

[chaplin]

Je n'ai rien contre d'utiliser la récursivité pour parcourir les arbres et je ne rabaisse absolument pas les maths.
Cependant, je suis pas certain que beaucoup(ie tous) de gens soient à l'aise avec la récursivité (suite arithmétique/géométrique, programme 1ère S... à l'époque ).

En fait il peut s'agir de gens qui décident de faire de l'informatique sans avoir un bagage mathématique conséquent.

Cela ne m'empèche pas d'être (agréablement) étonné par la concision du langage fonctionnel qui me rappel Mapple même si c'est différent.

[ZoinX]

Encore faut-il que l'enseignant le sache lui-même !! La première fois qu'un prof m'a expliqué les pointeurs (un ancien prof de maths reconverti, tiens, d'ailleurs...), alors que je savais déjà ce que c'était, j'ai fini par douter et me demander si j'avais bien tout lu tellement il a été confus, peu clair et souvent à côté de la plaque... Et en y passant deux heures de cours, en plus.
J'ai re-expliqué le tout à mes camarades après, en quinze minutes, et tout le monde a pigé du premier coup.

Si les enseignants ont souvent du mal à expliquer les pointeurs aux débutants et si les débutants ont souvent du mal à comprendre les pointeurs, peut-être que c'est justement parce que c'est difficile à conceptualiser et difficile à concilier avec pédagogie... et du coup peut-être que les langages utilisant les pointeurs ne sont pas les plus pédagogiques et adaptés aux débutants, et peut-être qu'il est nécessaire de commencer avec des langages plus simples à appréhender, comme le java ou le c#

[chaplin]

On peut aussi faire de la récursivité sans les pointeurs, autrement dit on peut étudier l'un indépendamment de l'autre, puis les deux en même temps, quand les deux notions sont comprises individuellements.

Commencer tout de suite avec un langage objet, j'y crois pas.

[alex_pi]

alex_pi: je découvre le langage fonctionnel avec ton exemple. A chaud, je dirais que c'est une approche très mathématique, en plus l'exemple utilise la récursivité , c'est peut être pas le meilleur exemple pour démarrer après réflexion.

Deux petites choses :
1) Je ne pense pas que ce soit "très mathématique". C'est, j'insiste, finalement très proche de la définition "haut niveau" de la hauteur d'un arbre, et il n'y a vraiment rien de bien complexe. La syntaxe peut être un brin déroutante, mais pour un débutant, pas plus que celle de C ou Java

2) Et même si c'est un peu mathématique, est ce un vrai problème ? Si tu veux raisonner au sujet de tes programme, si tu veux te convaincre qu'ils font bien ce que tu veux, un approche un peu "rigoureuse" et "mathématique" est indispensable. Et si on essayait de convaincre les débutant que la correction de leur programme est bien plus primordiale que leur vitesse, ils seraient sans doute plus enclin à tenter de franchir le pas (qui n'est vraiment pas gros). Et si on arrêtait de penser que "ceux qui font du Web n'ont pas besoin de 'prouver' leur programme", on aurait peut être un peu moins de bouse comme certains site d'achat de billet de train ou autre.

Quel exemple te semblerait mieux pour "commencer" ? Histoire que je te montre ce que c'est en fonctionnel

[chaplin]

Et si on arrêtait de penser que "ceux qui font du Web n'ont pas besoin de 'prouver' leur programme"

Quel exemple te semblerait mieux pour "commencer" ? Histoire que je te montre ce que c'est en fonctionnel

Est ce que tu pourrais citer un exemple qui pourrait illustrer la programmation dans le monde Web ?

Pour débuter, le "reproche" que je fais à ton exemple, c'est que je ne vois pas de découpage du programme comme il existe en Pascal:

- interface (déclarations)
+uses
+constantes
+types
- implémentation (code)
+uses
+ codes des fonctions (function/procedure)

Avec des blocs de séparations (begin ... end), une section de déclaration des variables ainsi que leurs portées (fonction, unité, variables locales/globales) .

En ayant fait du Fortran, C, Java, quand j'ai découvert Delphi, je retrouvais un domaine de recouvrement entre les différents environnements: impératif/POO/Performance comme en C/C++.

[jabbounet]

Avec des blocs de séparations (begin ... end), une section de déclaration des variables ainsi que leurs portées (fonction, unité, variables locales/globales) .

CE serait bien que le language pour débutant identifie aussi clairement les paramètres "in" et "out" des fonctions/methodes/procédures

[SpiceGuid]

Et si on arrêtait de penser que "ceux qui font du Web n'ont pas besoin de 'prouver' leur programme", on aurait peut être un peu moins de bouse comme certains site d'achat de billet de train ou autre.

Pour certains il faut choisir entre faire une bouse et ne rien faire du tout. On pourrait faire beaucoup d'améliorations, même en restant dans le cadre de la POO impérative. On pourrait par exemple imposer une discipline de typage qui interdit de déréférencer les pointeurs nuls. La raison pour laquelle on ne le fait pas c'est parce que les langages d'aujourd'hui sont adaptés au niveau des programmeurs d'aujourd'hui, et non le contraire. Une majorité de programmeurs pensent que les langages d'aujourd'hui sont déjà trop difficiles alors que dans ton monde (où un programme est un brouillon avant une formalisation en Coq) ils sont encore beaucoup trop primitifs.

[jabbounet]

personellement je n'ai rien contre le haut niveau, mais je pense qu'il faut voir les deux. car ce sont les deux face d'une même pièce.

Un fondeur ne peut pas continuer indéfiniment à produire un cpu pour un langage ou un paradigme déterminé. Ça a été tenté pour Lisp, pour Java et pour d'autres et aucun n'a percé durablement. Il y aura peut être un jour du multi-coeur à grande échelle exploité par de la programmation fonctionnelle, dans tous les cas ça restera une techno de niche.

faut attendre de voir ce qu'il se fait du coté quantique ou du coté asynchrone, ca pourrait changer radicalement la façon de faire des programme.

[F.Saad]

Quelle a été ta démarche F.Saad au tout début. Quel est ton premier langage et tes premiers essais (réussites, échecs).
Le premier me semble plus "Hack" tandis que l'autre est plus élégant, du moins ce sont les approches que j'ai à l'esprit pour l'instant ... j'en vois pas d'autres.

Je ne suis encore qu'un gros débutant. Sinon, j'apprends via les tutos d'ici , + Les mods d'ici pour réaliser des mini projets bizarre et pas utile pour l'instant
http://code.google.com/p/sleeptime/s...wse/#svn/trunk
je dirais que le seul echec jusqu'a maintenant c'est le temps que ca me prend pour justement faire ces trucs tres simple
3h pour mon petit sleeptime, 2h 30 de recherche de classes adéquate et 10 min de tappage de code + 20 min de débogage
et un autre probleme lié a la facilité de C#; j'abuse GRAVE des public static ;(