Discussion :

[Keihilin]

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

Oui oui, mais moi je ne parlais pas d'informaticien juniors, mais d'utilisateurs lambda qui ne sont pas du tout informaticiens !

Les deux comportements qui m'énervent :

• Ah t'es développeur ? Tu peux sûrement m'aider j'ai un problème avec mon imprimante.
• Moi aussi je suis développeur, j'ai fait un carnet d'adresse en Access/VB (suivi par de nombreux retour d'expérience, commentaires et conseils sur comment je devrais développer)

[GnuVince]

Oui oui, mais moi je ne parlais pas d'informaticien juniors, mais d'utilisateurs lambda qui ne sont pas du tout informaticiens !

Les deux comportements qui m'énervent :

• Ah t'es développeur ? Tu peux sûrement m'aider j'ai un problème avec mon imprimante.
• Moi aussi je suis développeur, j'ai fait un carnet d'adresse en Access/VB (suivi par de nombreux retour d'expérience, commentaires et conseils sur comment je devrais développer)

En tant qu'ancien technicien (qui s'est converti à la programmation), je peux te dire que c'est beaucoup plus facile de refuser d'aider quelqu'un avec son problème d'imprimante si tu dis que tu es un programmeur:

"Désolé, je voudrais t'aider, mais je fais de la programmation, c'est une autre équipe qui s'occupe des problèmes d'imprimantes, moi j'y connais plus rien malheureusement."

Si la personne insiste, tu dis que tu peux regarder, mais que ton taux horaire est 75$ / heure et que c'est pas certain que tu vas trouver. Ça les calme d'habitude.

Pour ton autre point, je suis d'accord. Beaucoup de gens me considèrent comme un bon programmeur, mais je vois en moi énormément de lacunes:

• Je connais rien à la programmation système
• Je connais pas l'assembleur
• Le typage statique me semble contraignant et j'ai de la misère à bien m'en servir (Haskell me kick régulièrement le derrière) *
• J'ai de la misère à penser en mode stack (Forth, Factor, etc.)
• Je connais pas C++ ou Java (par contre, j'en suis heureux)
• etc.

Je suis certain que je clanche n'importe quel ti-coune (expression québecoise) qui se pense l33t avec son petit programme en VBA, et pourtant lui se pense le roi du monde et moi j'ai des complexes sur mes capacités. Peut-être que de voir et reconnaître ses limites, ça fait parti d'être un bon programmeur...

* Petite note comique, dans ce thread, je parle des avantages côté sûreté que la programmation fonctionnelle apporte par rapport à la programmation impérative, mais j'ai de la misère à voir et profiter de la sûreté que le typage statique donne au programmeur. Je préfère les langages à typage dynamique... pour l'instant

[gorgonite]

* Petite note comique, dans ce thread, je parle des avantages côté sûreté que la programmation fonctionnelle apporte par rapport à la programmation impérative, mais j'ai de la misère à voir et profiter de la sûreté que le typage statique donne au programmeur.

franchement, le système de templates de C++ peut aussi faire pas de vérification dès la compilation...


considérons un exemple naïf sur les tableaux :

Code c++ :

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

1
2
3
4
5
6
 
template<typename T, int N> class Array {
   protected :
       T arr[N];
  /* ... */
};

juste avec le moteur de templates et la propagation de la constante, tu peux déjà éviter pas mal de *****



enfin, c'est clairement plus contraignant à développer à la main que du OCaml ou autre, mais avec un jeu de macros adéquate (au hasard SystemC ), ça peut devenir assez simple à écrire

[HanLee]

C'est un peu ce que je reproche a la programmation fonctionnelle pure, sa rigueur m'agace un peu. Alors oui c'est probablement plus facile de prouver un programme purement fonctionnelle (les fonctions récursives pourront par exemple êtres démontrées par récurences...), mais on a pas besoin tout les jours de prouver une application. Apres oui, en théorie ça permet de faire des programmes plus fiables et plus faciles a débugger, mais je doute qu'a court/moyen/long terme la programmation fonctionnelel pur apporte toujours des avantages par rapport à la programmation impérative.

On a pas besoin tous les jours de prouver une application, ça dépend des applications que tu développes.

C'est fondamental pour les algorithmes importants d'un programme. Typiquement, un jeu, il y a plein d'algorithmes géométriques. Là tu seras bien content de pouvoir t'assurer que telle ou telle partie d'un algorithme de collision, intersection, maillage ou je ne sais quoi encore marche bien.

Sachant que les effets de bord volent à foison...
En C++, je programme toujours mes algorithmes géométriques en style fonctionnel (pas d'effets de bords) pour le prototypage (sauf cas particulier, comme la manipulation des vecteurs de la STL où l'utilisation est disons, "canonique"), ce qui me garantit quasiment tout le temps des bons résultats dès les premiers coups.

Pour prendre un exemple où ça s'est mal passé, il n'y a pourtant pas longtemps de cela...

Je suis bien plus à l'aise en C++ qu'en OCaml, et pourtant j'ai mis beaucoup plus de temps pour mettre au point l'algorithme A* en C++ templatisé qu'en OCaml.

A cause d'erreurs dus à des effets de bords, qui dans un code non obstrué par plein de noms de types et typedef (vivement 'auto'...) ne serait pas passé inaperçu bien longtemps.

J'ai du écrire des foncteurs, créer beaucoup de nouvelles structures juste pour pouvoir manipuler simplement mes données, en utilisant std::map, std::list ou std::vector selon les propriétés voulues.

Au final, je me suis retrouvé avec une fonction templatisée et des structures annexes monstrueuses à regarder, en C++, mais qui marche bien heureusement.

------

LLB : la programmation fonctionnelle en C++ n'est pas toujours trop rebutante pour l'utiliser.

J'utilise boost::function pour réaliser ce qu'en POO on appellerait le pattern Commander, ca m'évite une hiérarchie de classe inutile.

J'ai eu à faire un petit interpréteur de formules pour EDF, merci boost::lambda, boost::bind et boost::variant. Ce qui m'a permis de finir le module avec aucune expérience en interprétation de langages de programmation, plutôt que de passer à OCaml.

boost::lambda qui est totalement inutile sur des types définis par l'utilisateur, se révèle très utilisable en pratique quand tu travailles sur les types primitifs du C++.
Exemple pour des mini-automates où pour la construction on te demande une fonction de transition + un prédicat.

[FR119492]

Bonjour à vous tous !

C'est avec beaucoup d'intérêt que je lis votre débat; je m'extasie devant l'acharnement que chacun d'entre vous met à défendre l'option qui est la sienne, et par conséquent qui est la meilleure. Alors, vous me permettrez, en ce temps de Noël (ou presque) de vous soumettre cette parabole qui se veut lénifiante:

Un marteau est un excellent outil pour planter des clous; une brouette est un excellent outil pour déplacer un tas de gravier. Mais essayez de planter un clou avec une brouette ou de transporter du gravier avec un marteau: ça ne va pas très bien!
Il y a donc des tâches très différentes et des outils très différents; il n'y a pas d'outil universel adapté à toutes les tâches (c'est ce qu'IBM avait essayé de faire avec le langage PL1, avec le succès que l'on sait...). Chacun de nous doit donc commencer par définir avec précision la tâche qu'il doit accomplir, et seulement ensuite choisir l'outil le mieux adapté.

Souviron34 et moi-même avons pour tâche de calculer numériquement des processus physiques. Pour cela, il faut un langage aussi proche que possible du langage compris par le processeur, et malgré cela compréhensible pour un humain normalement constitué et aisément déverminable. En général, nous renonçons à l'Assembleur et nous utilisons le Fortran ou le C.
D'autres parmi vous ont d'autres tâches, pour lesquels d'autres langages sont mieux adaptés. Il me semble aussi aberrant d'essayer d'écrire un programme de résolution de gros systèmes linéaires en Cobol que de créer un site Web en Fortran (encore que j'aie vu, à l'époque, un système de gestion de salaires sous la forme de macros WordPerfect)!

Alors, cessons nos querelles de clocher, utilisons le langage qui convient le mieux à nos tâches actuelles, et, si nous sommes confrontés à des tâches nouvelles, n'hésitons pas à apprendre un nouveau langage. Même à mon âge, ça se fait, et, de toute façon, à partir du dixième, c'est plus facile que pour le premier.

Meilleurs voeux à tous pour lanouvelle année.
Jean-Marc Blanc

[Garulfo]

[...]
Un marteau est un excellent outil pour planter des clous; une brouette est un excellent outil pour déplacer un tas de gravier. Mais essayez de planter un clou avec une brouette ou de transporter du gravier avec un marteau: ça ne va pas très bien![...]
Meilleurs voeux à tous pour lanouvelle année.
Jean-Marc Blanc

Il me semble que c'est ce que plusieurs d'entres nous disent depuis le début non ? En tout cas, je n'ai pas l'impression d'avoir dit autre chose.
En classe, j'utilise plutôt l'exemple de planter un clou avec un tourne-vis et de faire rentrer une vis avec un marteau pour leur illustrer le principe, mais on est bien d'accord : il faut savoir utiliser les bonnes techniques au bon moment.

[millie]

Il me semble que c'est ce que plusieurs d'entres nous disent depuis le début non ? En tout cas, je n'ai pas l'impression d'avoir dit autre chose.
En classe, j'utilise plutôt l'exemple de planter un clou avec un tourne-vis et de faire rentrer une vis avec un marteau pour leur illustrer le principe, mais on est bien d'accord : il faut savoir utiliser les bonnes techniques au bon moment.

Oui, tout à fait, le débat (qui est censé plutôt être une discussion) était relativement tourné sur la question : Pour quel type de problème avez vous privilégié un paradigme plutôt qu'un autre (quand le choix se justifiait évidemment) ?

Par exemple, j'ai dû prouver un assez gros algorithme avec PVS (système de preuve formelle), et l'implémentation se prêtait mieux dans un langage fonctionnel (et la preuve était plus simple avec un algorithme récursif)

[GnuVince]

Comme Garulfo l'a dit, personne n'a dit que le paradigme fonctionnel est le meilleur paradigme et le seul nécessaire. Il y a des problèmes (et leurs solutions) qui se prêtent mieux à l'impératif, et on devrait utiliser de l'impératif dans ces cas là.

La disparité est qu'est-ce qui devrait être le mode par défaut et qu'est-ce qui devrait être le "fall back".

Les gens du côté impératif préféreraient garder leur langage impératif, mais en ajoutant des fonctionnalités des langages fonctionnels. Si on veut déranger le moins possible l'état actuel du développement, c'est le choix à faire. On le vois avec C# qui va introduire des fonctionnalités fonctionnelles dans la version 3 du langage.

Les gens du côté fonctionnel sont d'avis que le paradigme fonctionnel devrait être celui par défaut et que seulement lorsque des effets de bords sont nécessaires devrions-nous utiliser l'impératif.

Qui a raison? Je sais pas. Je suis du côté du fonctionnel, j'ai eu ma révélation en regardant les vidéos de Abelson et Sussman du MIT.

Dans le 9 ou 10e vidéo, le professeur introduit la fonction SET! de Scheme qui permet de modifier la valeur d'une variable. Jusqu'à présent, tous les problèmes avaient été résolus sans mutations de variables. Et en commençant, il explique que ce qu'il va montrer c'est mal, dangereux, etc. mais que c'est nécessaire. Son exemple pour montrer pourquoi c'est "mal" est le suivant: dans le mode fonctionnel, un appel de fonction avec un argument va toujours retourner le même résultat. On peut appeler 100,000 fois la fonction (fact 5), elle va toujours retourner 120. Par contre, quand on a des effets de bords, une fonction avec le même argument peut retourner des résultats différents.

[Garulfo]

[...]
Qui a raison? Je sais pas. Je suis du côté du fonctionnel, j'ai eu ma révélation en regardant les vidéos de Abelson et Sussman du MIT.

L'idée au MIT est que le scheme est le plus approprié comme premier langage car il permet de s'émanciper d'une syntaxe lourde (la syntaxe du Scheme est très vite assimilable car extrêmement épurée) et donc de discuter très vite du sujet du cours : les paradigmes. Ainsi, on peut facilement en Scheme présenter tous les paradigmes aisément. La philosophie du MIT est de dire que la syntaxe exacte d'un langage peut être apprise tout seul dès que le paradigme est connu. C'est aussi ce que je crois. En général, on oppose à ça : le fait que les étudiants ne sont pas disponibles dès la deuxième session pour faire des stages (ils connaissent pas la syntaxe à-la-C, vu le faible nombre qui programme en C de toute façon ce n'est pas très pertinent, surtout que dans tous les cas ils ne savent pas faire grand chose après une session); le fait que les étudiants n'aiment pas le scheme (ils croient mieux savoir que les profs ce qui est bon pour eux – c'est connu, et ils ont vu du Java ou du C au collège donc ils croient que c'est l'unique façon de faire); le fait que nos étudiants sont moins bons que ceux du MIT (ça... bin c'est vrai -_-).

Je pense que dès qu'on a des algorithmes itératifs, ils faut les utiliser sans discuter. Mais je pense aussi que beaucoup de problèmes se résolvent bien mieux par une réflexion à-la fonctionnel, c'est-à-dire complètement mathématique. Ensuite, on s'évertue à en faire de l'itératif. Mais pour tester dans un premier temps, un prototype fonctionnel est beaucoup plus intéressant.

En tout cas, je reste convaincu que la base de toute la mauvaise publicité du fonctionnel n'est que les restes des difficultés techniques qui existaient. Hors ces difficultés disparaissent peu à peu. La curryfication automatique, le garbage collector, l'optimisation automatique des fonctions en forme récursive terminale, la compilation des langages fonctionnels, etc. tout ça n'existait pas, il y a 40 ans. Les techniques évoluant, beaucoup de langages récents offrent des features fonctionnels (python), voire sont fonctionnels (ruby). Rappelons nous que la programmation orientée-objet n'avait pas bonne presse. Pourtant bien plus de concepts sont passés de Smalltalk (comprendre OO) et Lisp (comprendre fonctionnel) vers le C (comprendre impératif) que le contraire. Je suis donc très optimiste comme je le disais

[ac_wingless]

Les paraboles de marteau et de brouettes sont indiscutables mais trop simplistes pour faire avancer le débat à mon avis. Ce qui compte, malheureusement, est de savoir par exemple avec quelle brouette on peut quand même enfoncer un clou sans trop de mal quand on n'a le droit qu'aux brouettes, ce qui est la situation normale, rappelons-le! Pour ceux que cette situation chagrine, attendez un peu: dans toutes les boites vous serez tôt ou tard interdit de clavier, au fur et à mesure de l'avancement de votre carrière, et vous aurez alors à gérer les fanatiques qui ne supportent pas de devoir utiliser un marteau (ou une brouette), avec tous les arguments à la clé, allant du dossier-béton prouvant que la perte de productivité est de 17.3%, jusqu'au gros caca sur la moquette. Au début, vous essaierez d'expliquer que l'univers est vaste et plein de gauchers, qu'il y a des projets qui durent plus de 6 mois, des programmes de plus de 100 pages, des collaborateurs qui arrêtent à 17h, des adorateurs de marteau (ou de brouette) qui ne sentent pas des aisselles. Et puis quand vous en aurez bouffé deux ou trois ans, vous ferez comme moi: tout le monde en brouette, et ta gueule (avec ou sans pincette).
Bon, n'empêche qu'il faut bien enfoncer des clous de temps en temps... et c'est pas marrant avec une brouette, faut avouer. Ben c'est comme ça.
Alors on fait ce qu'on peut. On fait des carénages de brouettes pour les "faire ressembler à des marteaux" (extrait du standard C++0x, pour ceux qui suivent). Ca le fait. Pas bien mais ça le fait, et c'est moins pire que si c'était encore pire. Les spécialistes ne se laissent d'ailleurs pas tromper par ces subterfuges pitoyables, et détectent rapidement la contrefaçon. Ben moi je leur souhaite de trouver un bon boulot d'enfonceur de clous, et d'ayatoller ailleurs

[Garulfo]

Les paraboles de marteau et de brouettes sont indiscutables mais trop simplistes pour faire avancer le débat à mon avis. [...]

Dans ce cas, tu devrais peut-être traduire ta discussion sans ces paraboles. Je n'ai malheureusement pas bien compris ce que tu essayais de dire.

[I_believe_in_code]

Ce qu'il a essayé de dire, c'est que vu la difficulté à gérer une équipe, connaissant les limites des uns et le dogmatismes des mêmes, il est plus simple d'imposer l'impératif à tout le monde.

[souviron34]

Ce qu'il a essayé de dire, c'est que vu la difficulté à gérer une équipe, connaissant les limites des uns et le dogmatismes des mêmes, il est plus simple d'imposer l'impératif à tout le monde.

Répondre à un post daté d'il y a presque 2 ans..... et qui plus est sans ajouter quoi que ce soit...

On peut dire que la discussion (et ses participants) ont autre chose à faire...