Discussion :

[kisitomomotene]

Réponse:
-Lorsqu'on reutilise du code en faisant copier-coller-modifier_la_nouvelle_copie,
- lorsqu'on ne commente pas son code,
- et lorsque pour étendre/modifier les fonctionnalités du programme , on modifie le code source du programme

Je trouve que l'amélioration des methodes de programmation depuis la programmation impératives jusqu'à la programmation orienté aspect vise à diminuer le nombre de reutilisation du code par copier_coller dans un projet, et à permettre des ajout/modification des fonctionnalités sans modifier le code source.

[Admin]

Je ne pense pas qu'on puisse etre aussi catégorique. Parce que l'existant n'est jamais à la pointe des methodes de programmation, et qu'il faut s'adapter a tous types de code, je préfère nettement un developpeur qui fait du copier-coller de code qu'un developpeur bloqué parce que c'est pas du code objet.

[Franck.H]

Le fait de réutiliser du code, celui qui fait du copier-coller n'est pas forcement quelqu'un qui code mal. Néanmoins, faire un copier-coller au lieu d'organiser en module et dont un code réutilisable pourrais etre un module qu'on ajouter a sa guise est quand meme dommage.
Moi j'ai deja du code réutilisable en C bah pour l'utilise j'ajoute simplement le header qui va bien et j'ajouter le *.c dans le projet .. pour moi, c'est ca un code réutilisable !

Mais savoir qu'on programme mal et qu'on est pas trop débutant, pour moi ce serais en fait, un code bourré d'erreurs, surtout des erreurs de conception donc en somme, un qui code mal, pour moi c'est une personne qui ne reflechi pas du tout ou pas trop avant de coder !

[vincent63]

Pour ma part, je dirai qu'un bon développeur (je prends le sujet à l'envers ) , c'est quelqu'un qui tient compte de trois (enfin j'en vois pas plus pour l'instant) axes principaux :
- l'architecture de l'application,
- l'utilisation qui est faite du langage,
- le fonctionnel

1. L'architecture de l'application (j'entends par là l'utilisation des bons patterns) permet de mettre au point un logiciel souple, robuste avec des modules réutilisables et souvent faciles à faire évoluer.

2. Chaque langage offre plusieurs possibilités pour arriver à un même résultat, seulement le plus souvent, une seule est bonne.
String ou StringBuffer en java?
=> problème de performances

Chaque langage offre des spécificités par rapport aux autres qui sont autants d'atouts qu'il faut savoir utiliser. Je fais allusion (entre autres) à des bibliothèques très abouties qui offrent des traitements optimisés mais aussi aux outils qui gravitent autour de ces langages (ie. la possibilité de bien documenter son code et de générer une doc en fait parti). Il FAUT bien connaitre un langage et donc ses spécificités et chercher à les exploiter au maximum.
Exemple : la STL pour c++, l'utilisation des collections en java (point très important), etc...

3. Le plus important peut-être, le fonctionnel. Il faut avant tout que ton application fasse bien ce pourquoi elle a été conçue.


Bref, si ton code architecture n'est pas bien conçue, si tu utilises n'importe comment les outils fournis par un langage ou si ton application ne se comporte pas comme elle devrait : alors le programme n'est pas bon.

[Admin]

3. Le plus important peut-être, le fonctionnel. Il faut avant tout que ton application fasse bien ce pourquoi elle a été conçue.

Tu soulignes un point que beaucoup de developpeurs négligent, dommage que tu le cite en point numéro 3 ;-)

Il ne faut pas oublier d'un language n'est un but en soi, mais un outil, le codage n'est pas un but en soi, mais une utilisation de l'outil, le but c'est de faire une application qui est le reflet des spécifications fonctionnelles.

Ce n'est pas parce que le code n'est pas commenté que le developpeur est mauvais, il fut un temps ou la taille en memoire d'un code empechait de creer des variables avec des noms clairs, empechait de mettre des commentaires, cette ère est révolue, mais il ne faut pas pour autant croire que les personnes qui developpaient en ce temps etaient mauvais bien au contraire.

Maintenant nous avons les outils permettant de faire un code, propre, réutilisable, commenté, organisable mais cela ne veux pas dire qu'il faille absolument le faire.

Dans le monde de l'entreprise ce qui importe c'est de faire peu cher, et fonctionnel, un code souple et réutilisable coute plus cher à faire qu'un code rigide, moins de parametre, plus de chose figé dans le code par exemple.

[vincent63]

Dans le monde de l'entreprise ce qui importe c'est de faire peu cher, et fonctionnel, un code souple et réutilisable coute plus cher à faire qu'un code rigide, moins de parametre, plus de chose figé dans le code par exemple.

Il y a deux écoles qui s'affrontent : les partisants du "vite fait mais ça marche" et "ceux du bien fait mais c'est plus long à faire" (j'ai pas mieux comme nom de catégorie dsl )
Même si les contraintes professionnelles poussent vers la première solution, je pense que passer du temps sur une architecture n'est pas une mauvaise chose.

Une application mal conçue (et là on est en plein dans le vif du sujet) sera difficile à maintenir.
Son évolution risque d'être plus délicate voire impossible, à moins d'ajouter des rustines sur les rustines déjà existantes ou de refondre toute l'architecture pour une plus juste.
De plus, une mauvaise architecture est souvent signe d'une mauvaise compréhension du domaine conceptuel.

Le travail en SS2I nécessite souvent le passage (bref mais intense ) sur de nombreux projets. Une mauvaise documentation (commentaires entre autres), des bidouilles de code utilisées à la place de solutions simples et efficaces et une conception parfois un peu trop rapide rendent souvent difficile la compréhension et par extension font perdre un temps précieux.

[vincent63]

Mais pour qu'il n'y ait pas confusion, je me situe encore dans la catégorie des "vite fait mais ça marche" mais je me soigne...

[Admin]

Tout à fait !

Je ne peux qu'etre d'accord avec toi, le mieux reste le code propre, mais devant des impératifs de rentabilité, cela ne fais malheuresement pas le poids, meme lorsque les coups sont doublés deux ans plus tard.

[kisitomomotene]

Pour ma part, je dirai qu'un bon développeur (je prends le sujet à l'envers ) , c'est quelqu'un qui tient compte de trois (enfin j'en vois pas plus pour l'instant) axes principaux :
- l'architecture de l'application,
- l'utilisation qui est faite du langage,
- le fonctionnel

J'avais parlé de bon programmeur..... Pour ce qui est d'un bon developpeur, c'est un autre débat.

[Admin]

J'avais parlé de bon programmeur..... Pour ce qui est d'un bon developpeur, c'est un autre débat.

C'est quoi la différence pour toi ?

[vincent63]

J'avais parlé de bon programmeur..... Pour ce qui est d'un bon developpeur, c'est un autre débat.

jour'
Je pense que la différence entre développer et programmer n'est pas suffisamment grande (s'il y en a une) pour que ma réponse change.

Une petite définition :
http://www.linux-france.org/prj/jargonf/D/deacvelopper.html

[kisitomomotene]

J'avais parlé de bon programmeur..... Pour ce qui est d'un bon developpeur, c'est un autre débat.

C'est quoi la différence pour toi ?

Un developpeur parcour presque tout le cycle de vie d'un logiciel surtout, il fait l'analyse, la conception, et le codage. Le programmeur travaille souvent avec moins de d° de liberté. genéralement on lui impose un environnement de travaille, un langage, et exactement ce qu'il doit produire. Les programmeurs travaillent à partir des documents fournis par des architectes, des analystes.
C mon point de vue

[sjrd]

des architectes, des analystes.

Ben tu viens de te contredire toi-même Ce que tu appelles des développeurs ce sont justements des architectes/analystes Un développeur c'est un programmeur

[Hephaistos007]

Ben tu viens de te contredire toi-même Ce que tu appelles des développeurs ce sont justements des architectes/analystes Un développeur c'est un programmeur

Je ne vois pas en quoi il se contredit. :

Développeur : prend en charge un processus (un enchainement de tâches).
Programmeur : une seule tâche, celle de programmer.

Il dit que le programmeur suit les instructions d'un développeur (architectes/analystes). Et c'est souvent le cas, un développeur délègue la tâche "programmation" à un programmeur.

[DrTopos]

Il me semble surtout qu'on programme mal (indépendamment des bugs) quand on fait des modules qui ne sont pas facilement réutilisables (par d'autres ou par soi-même quand quelques mois après on a tout oublié). Bien programmer consiste donc d'abord à écrire de bonnes spécifications (une bonne interface).

Le problème vient de ce que les langages qu'on utilise en général (C,C++, Java, Pascal, etc...) n'offrent que des moyens extrèmement rudimentaires pour spécifier. Le fait de donner le type d'une fonction en C ou en Pascal est largement insufffisant pour spécifier cette fonction.

J'aimerai (puisque c'est un de mes dadas) faire une comparaison avec les maths. Je pose donc la question: Comment savoir qu'on démontre mal? La réponse pour le coup est assez simple: 'quand la démonstration est fausse', ce qui signifie très précisément quelle ne respecte pas sa spécification c'est-à-dire l'énoncé qu'elle est sensée démontrer. Ceci-dit, c'est un peu trompeur car l'écriture même de cet énoncé (le fait de spécifier) fait partie du travail à faire, et ce n'est pas le plus simple bien sûr.

Les matheux démontrent-ils assez bien pour que les théorèmes soient facilement réutilisables? En général, c'est le cas. En maths on réutilise les mêmes théorèmes depuis des siècles. Je crois que la raison est double. D'une part, les énoncés, à force d'être paufinés finissent par faire des spécifications très propres. D'autre part, comme je l'ai expliqué dans ce fil, il y a une différence fondamentale entre programmes et preuves, qui est le principe de l'unicité du témoin. Ce principe implique qu'un énoncé spécifie (un témoin) sans ambigüité, alors qu'un type de donnée ne peut pas spécifier une donnée sans ambigüité, tout simplement parce que le type de données contient éventuellement plusieurs données distinctes.

Donc pour bien spécifier une fonction, il faudrait non pas donner son type, mais énoncer un théorème prouvant l'existence et l'unicité d'une fonction de ce type ayant certaines propriétés. Si la preuve qui en est donnée est constructive, le code de la fonction peut en sortir de façon automatique, et du coup la spécification est parfaite. C'est certainement ça l'avenir de la programmation. Au lieu de programmer des fonctions, on démontrera constructivement leur existence et leur unicité. Inutile de dire bien sûr que pour en arriver là il faudra changer de langage de programmation.

[Katyucha]

Pour rajouter un peu d'eau au moulin, je me suis souvent apercu que les mauvais programmes sont ceux, qui une fois plantés, sont indéchiffrables. On y passe des heures à comprendre le fonctionement, le chemin torteux pris par le developpeur.
Mon avis est celui d'un administrateur système, qui voit régulièrement des scripts shells, perl..etc se vautrer sur un système. Le temps de déchiffrer la doc et le code mal commenté est souvent trop important.

[kisitomomotene]

Les matheux démontrent-ils assez bien pour que les théorèmes soient facilement réutilisables? En général, c'est le cas.

Je ne crois pas qu'on reutilise un théorème parcequ'il a été bien démontré, du moins reutiliser dans le sens de l'appliquer. Il y a plusieurs "formules mathématiques" qui ont été appliquées avant que les matheux ne les démontrent rigoureusement, je pense par exemple à la méthode des élements finis utilisées en mécaniques.
De plus, certains enoncés mathématiques sont célèbres justement parceque personne n'a encore reussit à les démontrer ou bien on été démontrées des siècles après ( le petit théorème de Fermat etc.)

Ce principe implique qu'un énoncé spécifie (un témoin) sans ambigüité, alors qu'un type de donnée ne peut pas spécifier une donnée sans ambigüité, tout simplement parce que le type de données contient éventuellement plusieurs données distinctes.

je ne comprend pas bien ce que vous voulez dire. En quoi par exemple le type int définit dans un langage donné est mal spécifié? peux tu me donner une ambiguitée dans la spécification du type int dans le langage Java par exemple?

Donc pour bien spécifier une fonction, il faudrait non pas donner son type, mais énoncer un théorème prouvant l'existence et l'unicité d'une fonction de ce type ayant certaines propriétés. Si la preuve qui en est donnée est constructive, le code de la fonction peut en sortir de façon automatique, et du coup la spécification est parfaite. C'est certainement ça l'avenir de la programmation. Au lieu de programmer des fonctions, on démontrera constructivement leur existence et leur unicité. Inutile de dire bien sûr que pour en arriver là il faudra changer de langage de programmation.

En analyse numérique on démontre de façon constructive l'existence de certaine fonction ( on n'est pas obligé de démontrer l'unicité pour utiliser la dite fonction), et le code de ces fonctions est alors déduit automatiquement.

En plus je pense que programmer en utilisant les assertions est une façon de faire "les maths" en programmation, puisque les assertions enoncent des propriétés obtenues pendant l'analyse et vérifient que pour les données en cour dans les programme ces propriétés reste vraies.

Java prend bien en compte les assertions dans sa spécification.

[DrTopos]

Je ne crois pas qu'on reutilise un théorème parcequ'il a été bien démontré, du moins reutiliser dans le sens de l'appliquer. Il y a plusieurs "formules mathématiques" qui ont été appliquées avant que les matheux ne les démontrent rigoureusement, je pense par exemple à la méthode des élements finis utilisées en mécaniques.
De plus, certains enoncés mathématiques sont célèbres justement parceque personne n'a encore reussit à les démontrer ou bien on été démontrées des siècles après ( le petit théorème de Fermat etc.)

Il faut faire la distinction entre appliquer des maths et faire des maths. Il est certain que les physiciens, et les ingénieurs n'hésitent pas à appliquer des énoncés non encore prouvés (à leurs risques et périls, mais ce sont souvent des expériences intéressantes). Par contre faire des maths c'est différent. Ca consiste à démontrer formellement, pas à faire des expériences.

Parmi les énoncés qu'un matheux utilise, la plupart sont démontrés, l'utilisation de conjectures étant extrèmement réduite. De toute façon, même dans ce cas on a quand même démontré un théorème, à savoir que l'énoncé conjecturé en entraine bien un autre.

Note: c'est le grand théorème de Fermat qui a resisté 3 siècles et demi, pas le petit dont la démonstration est bien connue depuis Fermat lui-même.

Ce principe implique qu'un énoncé spécifie (un témoin) sans ambigüité, alors qu'un type de donnée ne peut pas spécifier une donnée sans ambigüité, tout simplement parce que le type de données contient éventuellement plusieurs données distinctes.

je ne comprend pas bien ce que vous voulez dire. En quoi par exemple le type int définit dans un langage donné est mal spécifié? peux tu me donner une ambiguitée dans la spécification du type int dans le langage Java par exemple?

J'ai déjà donné des explications détaillées la dessus ici. Il ne s'agit pas de spécifier (définir) un type, mais une donnée. Pour résumer, il s'agit de ceci: le fait de spécifier que x est un entier (par exemple en déclarant son type comme 'int') ne détermine pas la valeur de cet entier. De même, le fait de dire qu'une fonction est de type 'int -> int' (par exemple) ne détermine pas cette fonction. Par contre, le témoin représenté par une preuve (le témoin est la sémantique de la preuve) est complètement déterminé par l'énoncé à prouver. C'est une différence fondamentale qui joue bien évidemment un rôle crucial dans la réutilisabilité.

Donc pour bien spécifier une fonction, il faudrait non pas donner son type, mais énoncer un théorème prouvant l'existence et l'unicité d'une fonction de ce type ayant certaines propriétés. Si la preuve qui en est donnée est constructive, le code de la fonction peut en sortir de façon automatique, et du coup la spécification est parfaite. C'est certainement ça l'avenir de la programmation. Au lieu de programmer des fonctions, on démontrera constructivement leur existence et leur unicité. Inutile de dire bien sûr que pour en arriver là il faudra changer de langage de programmation.

En analyse numérique on démontre de façon constructive l'existence de certaine fonction ( on n'est pas obligé de démontrer l'unicité pour utiliser la dite fonction), et le code de ces fonctions est alors déduit automatiquement.

C'est exact qu'on n'est pas obligé de démontrer l'unicité pour obtenir constructivement et effectivement une donnée (fût-elle une fonction). L'axiome du choix est constructif dans certains cas. J'ai simplifié à l'extrème. Ce qui est sûr toutefois est que le principe de description (existence avec unicité) est constructif dans tous les cas, alors que l'axiome du choix ne l'est pas dans tous les cas.

En plus je pense que programmer en utilisant les assertions est une façon de faire "les maths" en programmation, puisque les assertions enoncent des propriétés obtenues pendant l'analyse et vérifient que pour les données en cour dans les programme ces propriétés reste vraies.

Java prend bien en compte les assertions dans sa spécification.

Programmer en utilisant des assertions comme en Java (ou comme on peut le faire en C avec 'assert') ne constitue pas une preuve que le programme respecte sa spécification. C'est seulement une insertion de tests (qui ne testeront qu'au run time). C'est très différent de ce que je proposais. Ce sujet a aussi été abondamment discuté dans les premières pages de ce fil, où a été levée la confusion possible entre preuve et test.

Je suis bien conscient d'avoir répondu trop succinctement à tes questions. Mais je suis prêt à donner des explications supplémentaires si besoin est.

[kisitomomotene]

Donc pour bien spécifier une fonction, il faudrait non pas donner son type, mais énoncer un théorème prouvant l'existence et l'unicité d'une fonction de ce type ayant certaines propriétés. Si la preuve qui en est donnée est constructive, le code de la fonction peut en sortir de façon automatique, et du coup la spécification est parfaite. C'est certainement ça l'avenir de la programmation. Au lieu de programmer des fonctions, on démontrera constructivement leur existence et leur unicité. Inutile de dire bien sûr que pour en arriver là il faudra changer de langage de programmation.

En analyse numérique on démontre de façon constructive l'existence de certaine fonction ( on n'est pas obligé de démontrer l'unicité pour utiliser la dite fonction), et le code de ces fonctions est alors déduit automatiquement.

Je compléte mon raisonnement. Quant bien même on pourait trouver une demonstration constructive d'une fonction, on pourra tout au plus deduire un algorithme dont on la preuve qu'il "marche", mais on ne peux pas prouver que le programme effectif déduit automatiquement de cet demonstration n'a pas de "BUG". C'est là tout le problème.
Donc pour faire de l'informatique exactement de la même manière qu'on ferait des mathématiques, il faudrait que les systèmes informatiques aient un modèle mathématique "fiable". Je crois qu'on en ait encore loin.
Et d'après moi toute tentative de "mathématiser" l'informatique en dehors d'un modèle mathématique fiable des système informatiques n'est que de la poudre aux yeux

[DrTopos]

Je compléte mon raisonnement. Quant bien même on pourait trouver une demonstration constructive d'une fonction, on pourra tout au plus deduire un algorithme dont on la preuve qu'il "marche", mais on ne peux pas prouver que le programme effectif déduit automatiquement de cet demonstration n'a pas de "BUG". C'est là tout le problème.

Tout cela est un peu vague. Il faudrait d'abord savoir ce qu'on entend exactement par 'bug', ce qu'on entend par 'algorithme' et ce qu'on entend par 'programme déduit d'un algorithme'.

En ce qui concerne le bug, j'aime assez la définition suivante: c'est tout ce qui entre en contradiction avec la spécification. Ceci dit, j'ai l'habitude d'en distinguer deux sortes: le bug formel et le bug d'intention. Le bug formel est ce qui entre en contradiction avec ce qui est spécifiable formellement, le bug d'intention est ce qui entre en contradiction avec ce qui est spécifié de façon non formelle. Je donne des exemples: une division par zéro est un bug formel, car il existe des moyens formels de spécifier la division telle qu'on la connait en mathématiques (tenant compte de la restriction qu'on ne peut pas diviser par zéro). Par contre, on peut trouver des programmes formellement corrects (sans bug formel) qui ont donc une interprétation mathématique correcte, mais qui font cependant autre chose que ce qu'on attendait. Ca c'est un bug d'intention. Parfois, le bug d'intention peut devenir formel (et donc être évité) par un affinement des spécifications, mais bien entendu c'est souvent assez difficile. Encore une fois, ce que je dis là ne s'applique qu'avec des langages avec formalisation des preuves, c'est-à-dire certainement pas ceux qu'on utilise en général de nos jours.

En ce qui concerne les algorithmes, il y a aussi des définitions mathématiques très précises. Par exemple, une classe de fonctions récursives totales (j'élimine d'office tous les algorithmes qui ne terminent pas ou ceux qui peuvent avoir des comportement exceptionnels).

Une preuve est constructive quand elle satisfait des critères précis (et en général très mal connus, sauf des logiciens intuitionnistes). Mais tout ceci à une définition mathématique très précise, et le fait de détecter qu'une preuve est correcte et constructive est algorithmique en temps linéaire. L'extraction d'un algorithme d'une preuve constructive est une chose triviale ne posant aucun problème. De même, la transformation d'un algorithme en programme est un faux problème: un algorithme est un programme.

En conclusion, il est tout à fait certain que si on a une preuve mathématique correcte et constructive de l'existence d'une fonction, on peut en déduire mécaniquement un programme exempt de bug formel.

Donc pour faire de l'informatique exactement de la même manière qu'on ferait des mathématiques, il faudrait que les systèmes informatiques aient un modèle mathématique "fiable". Je crois qu'on en ait encore loin.
Et d'après moi toute tentative de "mathématiser" l'informatique en dehors d'un modèle mathématique fiable des système informatiques n'est que de la poudre aux yeux

J'ai l'impressionn qu'il y a confusion sur ce qu'on entend par modèle. S'il s'agit de modéliser un phénomène physique, en utilisant des approximations et des nombres en virgule flottante, alors certainement, le modèle ne sera jamais parfait.

Par contre, s'il s'agit de modéliser un comportement logique à l'aide d'outils de logique mathématique, alors on peut obtenir un modèle dont on peut démontrer qu'il satisfait certains critères (par exemple absence bug formel dans le programme final). Je me garderai d'utiliser le mot 'parfait', dont le sens de toute façon n'a pas été défini.

Pour tempérer un peu je dirai qu'on dispose de modèle mathématiques tout à fait fiables pour ce qui concerne la programmation déterministe (celle qui est indépendante du temps et de l'espace). Pour ce qui est de la programmation non déterministe, c'est plus difficile, encore que des modèles comme ceux du langage B ou de LUSTRE, sont des approches à propos dequelles des théorèmes sont également démontrables. Ici toute la question est de choisir une bonne modélisation du temps. Dans le cas de LUSTRE par exemple, il y a une horloge principale et le temps est une succession d'instants. On arrive à des certitudes mathématiques sur les points qui intéressent les ingénieurs, ce qui est l'essentiel.