Discussion :

[Jedai]

Haskell se rapproche beaucoup de cet objectif, on remarque d'ailleurs que Tim Sweeney décrit fondamentalement Haskell dans son article, en défaveur d'Haskell il remarque que la syntaxe fait peur aux programmeurs mainstream, et il n'est pas convaincu par l'évaluation paresseuse.
Personnellement je pense que l'évaluation paresseuse est l'avenir, mais il est vrai que pour l'instant elle pose un certain nombre de problème technique.

--
Jedaï

[Garulfo]

Je crois que c'est GnuVince qui a fait l'excellente remarque de dire qu'il faut arrêter de dire « récursivité = fonctionnel ». À ma connaissance, certains algorithmes sont très difficiles à rédiger sous forme itérative, et même un langage de programmation impératif à recours à la forme fonctionnelle: par exemple, le triangle de Sierpinski. Il conviendrait donc d'avoir la bonne définition des paradigmes avant de continuer. Hélas, on sait que ces définitions peuvent changer selon les personnes. Cependant on devrait pouvoir s'en tenir à quelques points importants :
- le paradigme fonctionnel consiste dans le fait de pouvoir manipuler des fonctions comme une donnée de base et d'utiliser la transparence référentielle, c'est-à-dire grosso modo interdire les effets de bords (le résultat ne change pas si on change une expression par son calcul)
- le paradigme impératif par de l'idée que toute manipulation est une modification d'une machine « externe » au calcul et que donc on utilise des instructions modifiants cette machine. Grosso modo : on utilise donc des variables qui se modifient au cours du temps et représentent l'état explicite du programme par leurs sommes (dans le sens « l'union de chacune d'entre elles » et non « leur addition »).

Si on est d'accord là-dessus ça serait déjà bien.
Dans ce cas, on remarque que les effets de bords sont quasiment naturel au paradigme impératif. Non ? (je réflechis au fur et à mesure que j'écris).
Certes, l'ajout du paradigme modulaire permet d'éviter une exagération, mais un « retour » dans le paradigme impératif, reste un effet de bord; de même que la transmission d'arguments d'ailleurs.

En tout cas, qu'en pensez vous ?

[Garulfo]

Haskell se rapproche beaucoup de cet objectif, on remarque d'ailleurs que Tim Sweeney décrit fondamentalement Haskell dans son article, en défaveur d'Haskell il remarque que la syntaxe fait peur aux programmeurs mainstream, et il n'est pas convaincu par l'évaluation paresseuse.
Personnellement je pense que l'évaluation paresseuse est l'avenir, mais il est vrai que pour l'instant elle pose un certain nombre de problème technique.
--
Jedaï

Je suis globalement en accord avec ce que tu dis. D'ailleurs pour les problèmes sous-jacent à l'évaluation paresseuse, rappelons nous qu'il y a qqs années la récursivité terminale n'était pas optimisée automatiquement. D'ailleurs l'inférence de type n'était pas aussi bien maîtrisée. On peut donc espérer que des optimisations de ce type vont apparaître de plus en plus.

La performance n'est pas la pierre centrale de la célébrité (sinon point de Java face au C++), cependant ça ne fait quand même pas de mal

[Jean-Marc.Bourguet]

Je reprends cet exemple car il convient tout à fait.. Vous n'appellez pas ça de la syntaxe diffcile à comprendre (ou "ésotérique"), vous ??

Pas plus (ni moins) que la syntaxe de n'importe quel autre autre langage. Le seul qui reussit plus ou moins bien a etre comprehensible a des non inities, c'est le COBOL. Et je ne suis pas sur que la syntaxe du COBOL soit un modele a suivre.

[gorgonite]

gorgonite, les ";;" ne servent à rien dans Caml. Je vois que tu les mets à chaque fois, mais ça enlaidit le code (ils ne servent qu'en mode interactif, mais ce n'est pas à toi de les taper, c'est à ton éditeur de le faire).

j'aime bien avoir un code qui fonctionne aussi bien en mode interactif qu'en mode compilé... donc je les mets
et mon éditeur de texte a suffisamment d'options bizarroïdes à ma sauce pour éviter de le surcharger avec des trucs du style

Et pourtant... crois tu que tu es mieux placé que tes profs ?
Je ne dis pas qu'il n'y a que des bons profs. Parmi mes collègues je pourrais en trouver aisément quelques uns qui porte préjudice à la crédibilité d'un prof.

Maintenant tu es culotté de dire que tu peux juger, non ? C'est plus facile de critiquer que d'être capable de faire mieux je pense

Je ne vois pas pourquoi je n'aurais pas le droit d'exprimer critiques, même si je ne suis certainement pas capable de mieux faire (je n'ai jamais prétendu être pédagogue ). sinon ça revient à interdire à 95% des programmeurs de critiquer les bugs windows car ils ne seraient pas capables de faire eux-mêmes leurs OS

en programmation fonctionnelle, ce n'est que très récemment (depuis la fin de ma 2ème année d'école d'ingénieur) que j'ai eu des profs qui m'ont semblé savoir ce qu'ils faisaient... avant c'était souvent des profs de maths qu'on avait chargé de dispenser un enseignement d'informatique, et qui excellaient certainement en algorithmique, mais pas trop en programmation (sauf mon prof de maths de sup, que je n'ai pas eu en cours d'info, mais qui m'a certainement appris plus de choses que mes profs d'info de prépa même s'il faisait du lisp et non du caml )

L'argument de la lisibilité est un faux argument contre les langages fonctionnels. J'ai toujours trouvé le PERL peu agréable à lire.

perso, je n'ai jamais compris en quoi Perl serait plus illisible que d'autres langages... sa syntaxe est concise, il y a 3 symboles à retenir au début, et ensuite tout reste logique. mais comme toujours, ça dépend du programmeur, tu démontres toi-même qu'un utilisateur de lisp voulait faire un petit effort peu rendre son code attrayant (ce qui n'est pas souvent le cas )

mais un « retour » dans le paradigme impératif, reste un effet de bord; de même que la transmission d'arguments d'ailleurs.

En tout cas, qu'en pensez vous ?

je ne suis pas tout à fait d'accord sur la partie des passage des arguments... tant qu'on utilise pas des pointeurs ou des références (et ça arrive quand même assez souvent )

[Garulfo]

[...]
Je ne vois pas pourquoi je n'aurais pas le droit d'exprimer critiques, même si je ne suis certainement pas capable de mieux faire (je n'ai jamais prétendu être pédagogue ). sinon ça revient à interdire à 95% des programmeurs de critiquer les bugs windows car ils ne seraient pas capables de faire eux-mêmes leurs OS

Tu as le droit d'exprimer des critiques mais ce que tu as fait n'en étais pas une c'était juste une vengeance personnelle et généralisatrice. Car tu as placé l'ensemble des profs dans une même catégorie
Et Windows n'est pas une personne : un développeur de Windows ne pourrait probablement pas faire Windows lui-même.

Mais c'est une bonne règle d'éviter de trop critiquer quand on dit soi-même qu'on ne pourrait pas faire mieux ^_^

[...]en programmation fonctionnelle, ce n'est que très récemment (depuis la fin de ma 2ème année d'école d'ingénieur) que j'ai eu des profs qui m'ont semblé savoir ce qu'ils faisaient... avant c'était souvent des profs de maths qu'on avait chargé de dispenser un enseignement d'informatique, et qui excellaient certainement en algorithmique, mais pas trop en programmation (sauf mon prof de maths de sup, que je n'ai pas eu en cours d'info, mais qui m'a certainement appris plus de choses que mes profs d'info de prépa même s'il faisait du lisp et non du caml )

C'est une problématique due à la structure des programmes en France dans les écoles prépas. Mais tu généralises trop non ?

[...]
perso, je n'ai jamais compris en quoi Perl serait plus illisible que d'autres langages... sa syntaxe est concise, il y a 3 symboles à retenir au début, et ensuite tout reste logique. mais comme toujours, ça dépend du programmeur, tu démontres toi-même qu'un utilisateur de lisp voulait faire un petit effort peu rendre son code attrayant (ce qui n'est pas souvent le cas )

Attention je n'ai pas dit que du code Perl était illisible. Je me contentais de dire qu'à première vue quasiment tous les codes sont illisibles, et qu'en s'y penchant et avec un effort, ils deviennent tous lisibles. Sauf que je trouve le Perl peu agréable. Mais pas illisible. Je déteste Victor Hugo et nombreux sont ceux qui aime sont styles -_- c'était clairement une question de goût.

humm sauf le forth lui c'est vraiment illisible en fait
(c'est un clin d'œil à un ami – ne pas le prendre au pied de la lettre)

[...]
je ne suis pas tout à fait d'accord sur la partie des passage des arguments... tant qu'on utilise pas des pointeurs ou des références (et ça arrive quand même assez souvent )

Je parlais de l'idée derrière en disant ça. Comme je l'ai dit je pensais à voix haute. Mais en y repensant ça m'a toujours l'air censé. Je m'explique: le modèle pour un programme impératif c'est une suite d'instruction qui modifie une « machine » à l'extérieur du programme. L'idée derrière une procédure, c'est un module dans le sens hardware. C'est-à-dire que les paramètres, le sont dans le sens mathématiques du terme. C'est la raison pour laquelle on n'appelle pas ça des variables. Mais je ne parle pas du comportement stricto sensu. C'est le mécanisme de pensée qui accompagne ce que tu fais : le paradigme. La même chose est vu comme un passage mathématique et donc sans effet de bord en paradigme fonctionnel. Vois-tu là où je voulais en venir ?

Quand tu dis qu'il est rare d'utiliser des pointeurs ou des références, je trouve ça étonnant. En général beaucoup de langage impératif récent décide de ne passer QUE des références.

[Garulfo]

Pas plus (ni moins) que la syntaxe de n'importe quel autre autre langage. Le seul qui reussit plus ou moins bien a etre comprehensible a des non inities, c'est le COBOL. Et je ne suis pas sur que la syntaxe du COBOL soit un modele a suivre.

Tiens, c'est amusant. Je n'avais jamais vu ça vraiment. Mais maintenant que tu le dis... ça se discute.

[gorgonite]

Tu as le droit d'exprimer des critiques mais ce que tu as fait n'en étais pas une c'était juste une vengeance personnelle et généralisatrice. Car tu as placé l'ensemble des profs dans une même catégorie

C'est une problématique due à la structure des programmes en France dans les écoles prépas. Mais tu généralises trop non ?

je parle de mon expérience personnelle, donc je ne généralise pas du tout... par ailleurs, je n'ai aucune raison de vouloir me venger de mes profs de prépa qui étaient assez sympas

Je parlais de l'idée derrière en disant ça. Comme je l'ai dit je pensais à voix haute. Mais en y repensant ça m'a toujours l'air censé. Je m'explique: le modèle pour un programme impératif c'est une suite d'instruction qui modifie une « machine » à l'extérieur du programme. L'idée derrière une procédure, c'est un module dans le sens hardware. C'est-à-dire que les paramètres, le sont dans le sens mathématiques du terme. C'est la raison pour laquelle on n'appelle pas ça des variables. Mais je ne parle pas du comportement stricto sensu. C'est le mécanisme de pensée qui accompagne ce que tu fais : le paradigme. La même chose est vu comme un passage mathématique et donc sans effet de bord en paradigme fonctionnel. Vois-tu là où je voulais en venir ?

je crois comprendre, mais je ne suis pas d'accord avec la description de l'impératif... question de goût certainement

Quand tu dis qu'il est rare d'utiliser des pointeurs ou des références, je trouve ça étonnant. En général beaucoup de langage impératif récent décide de ne passer QUE des références.

uniquement quand il passe des objets en arguments... le problème, c'est que beaucoup n'utilise plus que des objets

[Jean-Marc.Bourguet]

Tiens, c'est amusant. Je n'avais jamais vu ça vraiment. Mais maintenant que tu le dis... ça se discute.

C'etait un des objectifs du langage (qui date de la fin des annees 50), et il y reussit pas trop mal.

[Garulfo]

je parle de mon expérience personnelle, donc je ne généralise pas du tout... par ailleurs, je n'ai aucune raison de vouloir me venger de mes profs de prépa qui étaient assez sympas

Quand tu dis qu'écouter ses profs c'est rarement une bonne idée tu ne généralises pas alors que tu ne connais pas les profs de la personne qui a dit ça ?

je crois comprendre, mais je ne suis pas d'accord avec la description de l'impératif... question de goût certainement

C'est-à-dire que tu n'es pas d'accord ? Tu as une autre définition à proposer ?
C'est comme ça qu'ont été définis les caractéristiques des langages impératifs, il me semble. Et c'est pour cela qu'ils s'appelent « impératif » car ils donnent des ordres à une machine externe.
Je ne crois pas que ce soit une question de goût.

uniquement quand il passe des objets en arguments... le problème, c'est que beaucoup n'utilise plus que des objets

Comment ferais-tu autrement dans un paradigme objet ?

[gorgonite]

je répondrais au reste plus tard...

Comment ferais-tu autrement dans un paradigme objet ?

ben pourquoi systématiquement boxer les int en Integer par exemple ?
je comprends qu'avec les langages proposant l'invocation dynamique de méthodes ce soit difficile de faire autrement, mais je ne trouve pas forcemment cela très utile...

un truc du style :

Code :

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

1
2
Object res = Object.invoke(mon_objet,"le nom de la méthode",mon_tableau_d_objets_a_passer_en_argument);

mais si l'on se passe de cette fonctionnalité, rien n'empêche de passer des types simples comme int

[Jedai]

Quand tu dis qu'écouter ses profs c'est rarement une bonne idée tu ne généralises pas alors que tu ne connais pas les profs de la personne qui a dit ça ?

Je pense que ce qu'il voulait dire (et en tout cas ce que j'en avais compris et approuvé) c'est que faire une confiance aveugle à ses professeurs est rarement une bonne idée (nul n'est parfait), tout particulièrement quand on a des preuves que le professeur s'est trompé (et dans le cas de DarkVenoM c'était le cas, sa décision de "faire confiance à ses profs" était donc tout spécialement mal avisée). Je prends toujours ce que me disent mes professeurs avec un grain de scepticisme, même ceux que je respecte profondément.

--
Jedaï

[Garulfo]

Je pense que ce qu'il voulait dire (et en tout cas ce que j'en avais compris et approuvé) c'est que faire une confiance aveugle à ses professeurs est rarement une bonne idée [...]

Ça c'est par contre très vrai. Alors si c'est ce qu'a voulu dire Gorgonite je m'excuse

[Garulfo]

[...]
ben pourquoi systématiquement boxer les int en Integer par exemple ?

Parce que c'est le paradigme objet. On retombe sur ce qui doit être dans le paradigme et le fait, qu'intelligemment, en bon humain qui a compris qu'il y a mieux, on fait autrement. Cependant, le strict respect du paradigme objet fait qu'il est logique que quasiment tout soit passé par référence. Et c'est pourquoi la majorité des langages le font à l'heure actuel. Que ce soit une bonne ou une mauvaise chose est un autre problème. Notons que dans le pur objet il ne devrait pas y avoir de forme structurée à proprement parler, mais des objets aussi. Ça devient clairement horrible, d'où le fait que tout langage OO fait de facto l'utilisation du paradigme structuré.

Je me réadresse à DarkVenom donc : nul ne préconise d'utiliser strictement un paradigme sans en utiliser d'autre. Ce n'est bon que pour se rendre compte des forces et des faiblesses d'un paradigme.

---

Mais bon revenons à nos moutons impératifs et fonctionnels.
Que proposes tu de mieux pour la définition du paradigme impératif que ce que j'ai proposé ?

[Garulfo]

[...]Je prends toujours ce que me disent mes professeurs avec un grain de scepticisme, même ceux que je respecte profondément.

Au passage, et un peu HS, un collègue réputé pour ses compétences pédagogiques et extrêmement apprécié de tous les étudiants (on ne compte plus les prix que les étudiants lui ont décernés), nous faisait remarquer à quel point il est étonnant de voir combien les étudiants et étudiantes en première année en informatique croit tout savoir ou presque et remettent continuellement en doute ce que dit le prof (pour leurs majorités bien sûr).

En math, si un ou une prof écrit une forme linéaire doit s'écrire comme ça, personne n'osera dire que c'est faux. En physique, si un ou une prof dit que la bonne méthodologie c'est de faire A puis B, les étudiantes et étudiants ne le remettront pas en cause. En informatique, si tu leurs dis qu'il est mieux de procéder comme ceci ou comme cela pour telle ou telles choses, tu vas toujours avoir 4 ou 5 personnes qui vont dire qu'il y a mieux et remettre en cause ton jugement. C'est assez étrange comme phénomène. L'informatique est la seule science ou presque, où les étudiants et étudiantes pensent régulièrement que leurs avis est meilleur que celui du ou de la prof.

[souviron34]

Au passage, et un peu HS, un collègue réputé pour ses compétences pédagogiques et extrêmement apprécié de tous les étudiants (on ne compte plus les prix que les étudiants lui ont décernés), nous faisait remarquer à quel point il est étonnant de voir combien les étudiants et étudiantes en première année en informatique croit tout savoir ou presque et remettent continuellement en doute ce que dit le prof (pour leurs majorités bien sûr).

En math, si un ou une prof écrit une forme linéaire doit s'écrire comme ça, personne n'osera dire que c'est faux. En physique, si un ou une prof dit que la bonne méthodologie c'est de faire A puis B, les étudiantes et étudiants ne le remettront pas en cause. En informatique, si tu leurs dis qu'il est mieux de procéder comme ceci ou comme cela pour telle ou telles choses, tu vas toujours avoir 4 ou 5 personnes qui vont dire qu'il y a mieux et remettre en cause ton jugement. C'est assez étrange comme phénomène. L'informatique est la seule science ou presque, où les étudiants et étudiantes pensent régulièrement que leurs avis est meilleur que celui du ou de la prof.

et si c'était juste chez les étudiants dans les cours !!!

[Keihilin]

et si c'était juste chez les étudiants dans les cours !!!

+1

L'informatique a ceci de particulier que le premier quidam qui a installé son premier OS il y a 3 jours va expliquer son métier à un ingénieur avec 10 ans d'expérience.

[Bluedeep]

L'informatique a ceci de particulier que le premier quidam qui a installé son premier OS il y a 3 jours va expliquer son métier à un ingénieur avec 10 ans d'expérience.

+1

Ca sent le vécu

[Bluedeep]

Pas plus (ni moins) que la syntaxe de n'importe quel autre autre langage. Le seul qui reussit plus ou moins bien a etre comprehensible a des non inities, c'est le COBOL.

EXAMINE [kekchoz] TALLYING ALL SPACES REPLACING BY [..]
ALTER [..] TO PROCEED TO [...]

C'est vrai que c'est limpide ....

[gorgonite]

L'informatique a ceci de particulier que le premier quidam qui a installé son premier OS il y a 3 jours va expliquer son métier à un ingénieur avec 10 ans d'expérience.

sans vouloir vexer personne, je tiens à signaler que l'ancienneté n'est pas toujours synonyme d'expérience... parce que selon moi

• on trouve pas mal de petits **** fraichement sortis de l'école, persuadés qu'ils sont la future élite de la nation (leurs profs le leur ont repétés durant au moins 3 ans, donc ça doit être vraie ), et qui considèrent que tout ce qu'ils ont appris en cours (et en tp) constituent lechoix d'avenir... (notez que je n'ai pas dit un choix mais LE choix )
• on trouve malheureusement aussi des anciens qui pantoufflent à leur poste depuis si longtemps qu'ils ont fini par être dépassé, et continuent d'utiliser des produits ou techniques assez limites comme Merise, Foxpro, etc (notez aussi que je ne classe pas Cobol dans cette catégorie )

après comme toujours, il faut trouver un juste milieu... il est clair que beaucoup de juniors devraient presque toujours apprendre au lieu de parler, mais il faudrait aussi parfois que les anciens se remettent en cause