Discussion :

[lichemz]

Bonjour à tous,

Débat très intéressant et qui, à mon avis, met en évidence une forme d'opposition entre ceux qui pensent que les nouveautés sont à considérer avec circonspection (voire avec méfiance) et ceux qui estiment qu'il faut s'y adonner clairement.

Pour ma part je suis plutôt "jeune" (26 ans) même si j'ai commencé à programmer il y a fort longtemps en QBasic sur un vieux 386. Je suis ainsi passé par l'assembleur, le pascal, le C, les triplet C++/Java/C# et bien d'autres langages, parmi lesquels le très intéressant Caml (incontournable en prépa).

Mon sentiment est qu'il y a toujours une forme de méfiance de certains "vieux" (j'emploie ce terme affectueusement), persuadés que toute nouveauté est une forme d'agression à l'encontre de leur savoir et de leurs compétences. Je pense que c'est une façon de penser assez extrémiste et stérile. Heureusement, la plupart des séniors que j'ai rencontré n'ont pas cette vision réductrice et ne rechignent pas à utiliser eux-mêmes des outils comme Eclipse.

La question qui se pose, pour moi, est celle de l'apport des SDK et des frameworks. Au risque de paraître moi-même un peu "vieillot", j'estime que ce sont des outils dont il faut savoir se servir en connaissance de cause et pas "parce que ça fait bien". J'ai une assez faible expérience du monde du travail mais j'en ai suffisamment pour avoir rencontré des personnes qui utilisent des objets ou des frameworks sans rien savoir de la technique sous-jacente et s'il fallait, pour moi, mettre en avant un aspect dangereux de ce genre de choses, c'est bien la tentation de considérer ces outils comme des boîtes noires.

Pour prendre un exemple simple, j'apprécie quand mes collaborateurs savent ce qu'est un tableau, ce qu'est une liste chaînée, ce qu'est une table de hachage (ouverte, fermée) et quand utiliser chacun (beaucoup d'insertions/suppressions ? beaucoup d'accès séquentiels ? nécessité d'accéder à un objet en temps constant ?). J'apprécie que les membres de mon équipe aient ne serait-ce qu'une notion de ce qu'est la complexité d'un algorithme et pourquoi il est important de savoir la calculer.

Pour moi, ce n'est qu'une fois le concept clairement assimilé qu'on peut passer à un outil permettant de l'automatiser. A partir de ce moment, j'approuve presque sans réserve l'utilisation d'outils comme Eclipse car l'utilisateur sait alors clairement ce qu'il fait et comment. Comme le disait un de mes professeurs, "l'IDE ne programme pas à votre place. Il ne décidera pas pour vous s'il faut utiliser systématiquement un QuickSort ou si, en dessous d'une certaine taille, il ne vaut pas mieux passer à un tri Shell ou à un tri par insertion.".

A part ça, j'apprécie énormément quand mon IDE (Eclipse, Visual Studio, Netbeans, peu importe) m'aide à créer mes getters/setters, quand il m'aide avec l'auto-complétion, quand il fait de l'indentation automatique ou, même, qu'il me permet de gérer en un seul endroit la programmation, la compilation, la doc et le lancement des exécutables. A ce titre, un outil comme Emacs est aussi un IDE, voire une "usine à gaz", terme caricatural souvent entendu dans la bouche de certains séniors qui croient ainsi dénigrer Eclipse alors que l'Emacs qu'ils prônent propose exactement les mêmes fonctions ... voire beaucoup plus.

Tout ceci ne m'empêche pas de me servir d'un vi si le besoin s'en fait sentir. Mais uniquement s'il s'en fait sentir. L'auto-flagellation ne fait pas partie de mes principes et si je peux aller plus vite, être plus efficace et finalement m'amuser plus avec Eclipse, je le ferai sans arrière-pensée. Je ne vois pas où est la gloire de se farcir 50 get/set avec vi alors qu'un Eclipse me soulage de ces tâches peu intéressantes pour me permettre de me focaliser sur ce qui importe vraiment.

Pour conclure cette partie, je dirais que je suis tout à fait ouvert à l'utilisation des nouvelles technologies (dont je suis moi-même un fervent utilisateur) mais sans oublier les fondamentaux. Il ne s'agit pas d'oublier comment ça marche, mais d'aller plus vite tout en sachant faire sans l'outil si besoin est. De même, de bonnes connaissances en algorithmique, en structures de données, en complexité sont indispensables. Pas pour réinventer la roue mais pour être capable, en toute circonstance, de faire le bon choix et d'assurer à son programmes des performances sinon optimales, du moins excellentes. A ce titre, des livres comme "Algorithmes en langace C" de Sedgewick ou le fameux "Concepts fondamentaux de l'informatique" d'Aho et Ulmann doivent figurer dans la bibliothèque de tout ingénieur qui se respecte.


La seconde partie sur laquelle j'aimerais donner mon avis c'est la fameuse opposition entre les langages. Sur ce plan il n'y a pas à tergiverser, le marché dicte sa loi. J'ai un faible pour les algos en C fignolés et optimisés aux petits oignons (même si le "grand" Knuth a toujours prévenu contre les méfaits de l'optimisation) mais pour l'instant je fais du Java ... et je ne m'en porte pas plus mal ! Le langage n'est pas réellement un problème quand on connaît les fondamentaux. Pour le coup, je n'ai aucun mal à passer du Java/.NET ... au C, au Perl ou même à l'assembleur. Par contre, il est vrai que les nouveautés sont légion d'année en année. Toutefois, cela ne m'inquiète pas trop. En effet, bien que pratiquant la veille technologique (comme tout le monde, j'imagine), je ne le fais pas de façon effrenée. Pourquoi ? Parce que même si beaucoup de nouveautés sont séduisantes, combien subsisteront ? Je ne suis pas du genre à me jeter à corps perdu dans chaque truc qui sort parce que je sais par avance que c'est peine perdue. Je préfère me focaliser sur ce que réclame le marché et franchement, ce n'est pas très difficile : en gros, C/C++, Java, .NET et du web. Un de mes profs disait "90% des technologies sur lesquelles vous travaillerez n'existent pas encore". J'ai envie de lui répondre que pour l'instant ce n'est pas trop le cas car nombre de technologies sur lesquelles j'ai eu l'opportunité de travailler n'ont rien de nouveau. Je n'ai pas encore eu à bouleverser ma façon de travailler, je n'ai pas encore découvert un langage ou une technologie révolutionnaire, juste des paradigmes de programmation un peu différents de ce que je connaissais (AOP, par exemple).

Enfin, il faut tordre le cou à ces préjugés qui veut que les "vieux" soient systématiquement de parfaits experts du code, capables de faire un Cray d'un 386 et les "jeunes" de parfaits incapables, capables de faire d'un Cray une machine poussive avec leurs "usines à gaz". Ce genre de considération émane souvent de personnes ayant une certaine expérience mais je peux vous dire que j'ai connu plusieurs "vieux" incapables de coder proprement, d'architecturer intelligemment leur code ou même, tout simplement, de le commenter. Dois-je pour autant céder à la faciliter et généraliser à tout va ?


Bref, et pour finir, il est difficile d'avoir un avis tranché et définitif. L'informatique évolue vite, très vite même, mais on fait beaucoup de neuf avec du vieux. L'important est de savoir discerner le bon grain de l'ivraie et de savoir évoluer en toute circonstance. Je ne pense pas que le savoir "profond" de l'informaticien soit remis en cause, on lui demande le plus souvent de savoir s'adapter à un nouvel outil ou à un nouvel environnement. Pour le reste les structures de données n'ont pas beaucoup évolué en 50 ans, le C est encore d'actualité et je gage qu'on en fera encore dans 20 ans, de même que le Java. Non, franchement, la rapide évolution déguisée des technologiles ne m'inquiète pas.

[yann2]

Salut et bienvenu.

Je suis complètement d'accord avec la première partie (utiliser un framework/outils... en connaissance de cause et non comme une boite noire) de ton post (en fait elle ressemble beaucoup à un post que j'ai laissé ici même).

Bon je suis assez d'accord avec le reste.

Bonne analyse.

Très bon premier message !!!! J'espère revoir d'autres posts comme celui là !

[Hibou57]

Lichemz,

Alut, et bienvenu toi

Mon sentiment est qu'il y a toujours une forme de méfiance de certains "vieux" (j'emploie ce terme affectueusement), persuadés que toute nouveauté est une forme d'agression à l'encontre de leur savoir et de leurs compétences. Je pense que c'est une façon de penser assez extrémiste et stérile.

Il y a une expression... trés courante chez les « vieux » (en tous cas au moins dans ma région natale, les Vosges). Cette expression dit : « si jeunesse savait, et si vieillesse pouvait ». Ce qui signifie que la jeunesse à souvent de l'energie, mais pas d'experience ou de maturité, et elle met souvent son energie à faire des erreurs, tandis que la vieillesse a la maturié (dans le meilleur des cas), mais plus l'energie d'agire.

Bien sure, on pourra rétorquer qu'en veillissant on peut parfois se scléroser... ce qui arrive malheureusement parfois, c'est vrai, et « les vieux/vieilles » sont souvent loin d'avoir la maturié qui siairerait bien à leurs âges honnorables.

Mais je te pose une colle tout de même : l'expérience et la maturité ne nécéssite t-elle pas le temps ?

Ah les belles intentions de la jeunesse, à l'exemple de ses idéaux de tolérance qu'elle met à l'oeuvre en invitant par exemple dans ces petites fêtes étudiantes.... étrangement exclusivement les étudiants qui lui ressemble, reléguant à l'exclusion ceux/celles qui lui font peur parce que d'une autre classe sociale que la sienne, parce que « bizzare », pas de la même culture ou autre (c.f. les taux de suicides dans les milieux étudiants... pas seulement dut à la pression des cours.... ou plutôt dut à la pression des cours rendu insupportable par l'hypocrisie des beaux idéaux, qui font surtout usage de belle facade - et un manque de solidarité flagrant).

Si la jeunesse était ce qu'on en dit, ça fait des siècle qu'elle aurait dut sauver le monde de son cahos.

Note : j'ai 33 ans.

Non, l'objectif de la jeunesse et d'affronté la vieillesse en duel, et ce par toute les excuses possible, et surtout de la supplanter, sous toutes les raisons possibles, quel qu'en soit le cout.

pour moi, mettre en avant un aspect dangereux de ce genre de choses, c'est bien la tentation de considérer ces outils comme des boîtes noires.

Assez d'accord J'y reviendrai plus tard (mais pas haujourd'hui)

l'IDE ne programme pas à votre place

C'est ce qu'on a pas cessé de répéter tout au long de ce fil.

A part ça, j'apprécie énormément quand mon IDE (Eclipse, Visual Studio, Netbeans, peu importe) m'aide à créer mes getters/setters, quand il m'aide avec l'auto-complétion,

Là aussi, je suis d'accord, mais je me demande pourquoi ces fonctionnalité, quand elles sont implémentés, le sont toujours aussi mal, et pourquoi cela nécéssite toujours des IDE aussi volumineux. Ma remarque est annecdotique, je te l'accorde.

qui croient ainsi dénigrer Eclipse alors que l'Emacs qu'ils prônent propose exactement les mêmes fonctions ... voire beaucoup plus.

Mais tu nous as mal lu! Où avons nous dit une telle chose ? Personne n'a dit « emacs c'est bien, eclipse c'est nul ». Personnellement, je place les deux au même niveau. Je crois que tu nous as mal compris. Tu nous as lu comme si nous avions proclamé « tout de qui est nouveau c'est nul, tout ce qui est ancien c'est bien ». Tu ne nous prendrais pas un peu pour des valoches par hasards ? Par contre, permet de te dire, pour te narguer un peu, que ta lecture ressemble beaucoup à une lecture hative de jeuniste

Si tu m'avais lu, ainsi que d'autre (comme Souviron) par exemple ailleurs, dans d'autres fils de ce forum, tu nous aurait vu tout autant dénoncer des technologie ancienne parfois aussi mal conçus. On ne dénnonce pas la jeunesse, mais la prise de pouvoir des commerciaux sur l'orientation des technologie, et la mauvaise orientation que prenne ces technologie en général : consomation de resource explosive et injustifié au regard de travail effectué par l'application, une complexité sens cesse croissante (et opaque, il y a une différence à faire entre complexe et compliqué) pour des spécifications pourtant quasiement constantes, implémentation en surcouche de surcouche de surcouche et etc. Entre autres exemple.

Bref, ce que l'on dénnonce, c'est la perte de la notion de ce que vaut une instruction processeur, un octet mémoire, une instruction d'entrée sortie, etc. C'est-à-dire qu'on en appel à la même prise de conscience que tu le fait avec ton exemple sur les algorithme de trie.

Je dirais que la question est de savoir : combien de temps tiendra tu face au pression de tes employeur. Combien de temps tiendra tu fasse au ditacte de la mode (toi qui a surement appris [je suppose], à la fac, appris à copier autruit, sous peine d'exclusion.... je dis ça, parce que tu semble en être fraichement sorti[e]).

Sur ce plan il n'y a pas à tergiverser, le marché dicte sa loi.

Ce que je viens de dire

J'ai un faible pour les algos en C

Puisqu'on en est au « perso », moi j'ai un faible pour destester un langage avec une syntax qui invite au bug. Je viens encore de remarquer tardivement un bug caché dans une de mes programme, dut à la fameuse confusion "=" vs "==".. cas typique qui démontre trop bien l'immaturité de ces lanagage, par opposition à d'autres, conçus et murrit pour éviter ce type d'erreurs (Pascal/Ada, par exemple). La plus grande usine à gaz ne remplacera jamais l'efficacité de ce qui est judicieux. Comme tu le vois, il ne s'agit pas de dénnonce le jeune au profit de l'ancien, mais plutôt de dénnoncer les attitude désinvolte, qui on produit le C en un temps, puis les usines à gaz en notre temps (mais aussi en des temps plus ancien). Et le problème est que maintenant, à cette époque actuelle, l'attitude désinvolte est érrigée en principe « fun et cool ». Genre « je fais du C parce que ça fais style de jouer dans la cours des grand, parce que ça fait style de coder avec un langage à la syntaxe cabalistique ». Mais pour concevoir sereinement, mieux vaut rester tranquille et ne pas s'affoler, et certains langage n'encourage pas à cette retenue (*). Puisque tu parle de ce langage, je pense qui est à l'origine de la plus grande part des dérapage de l'informatique actuelle. D'ailleurs si tous les nouveaux langage se réclame de cette syntax, ce n'est pas hasard... c'est pour faire « style ».. et on voit les résultats.

Mais ce n'est qu'une cause parmis d'autres.

(*) L'objectif n'est pas de coder plus vite (c.f. tes remarques sur les fonctions d'éditions semi-automatique), mais de coder mieux et plus clairement. Et d'expérience, tu apprendra peut-être que les codages les plus clairs sont les plus verbeux, et les plus longs à rédiger, parce que quand on y reviens, il s'avère bien plus facile à lire. Ce qui peut être généré automatiquement ne contient généralement qu'un faible taux d'information (c.f. les théories sur la compression de données par exemple), et l'information pertinante qui rend un code claire et fiable ne peut de toute façon pas être généré automatiquement. J'ajouterais encore que de devoir taper certaines ligne de code de manière rébarbative n'est pas ce qui peut perturber le plus quelqu'un qui travaille. Puisque c'est automatiquement, on le tape automatiquement tout en pensant à ce qu'on fait, en anticipant parfois. Bref, il faut prendre le temps (un contre exemple, par exemple : plus on passe vite sur un code, moins on a de chance de detecter les erreurs et les mauvaises conceptions qu'il contient). Coder toujours plus vite, voilà bien notre plus grand maux.

Enfin, il faut tordre le cou à ces préjugés qui veut que les "vieux" soient systématiquement de parfaits experts du code, capables de faire un Cray d'un 386 et les "jeunes" de parfaits incapables, capables de faire d'un Cray une machine poussive avec leurs "usines à gaz".

Beh mon/ma chèr(e), c'est tout de même un fait, hein, t'es pas d'accord ? : on faisait de la prévision météorologique avec des machines qui atteignait à peine à l'époque la puissance des 486 qui sont venu plus tard, et on est même plus capable de faire tourner un traitement de texte sur des machines 1000 fois plus puissantes que ces anciens Cray. Et quand je dis 1000 fois plus puissante, ce n'est pas une façon de parler. Excuse moi, mais il y a de quoi se poser des question non ? Peut-être un problème de conception non ?

C'est drôle, parce que tu as fait tout(e) seul(e) la remarque que je me fait souvent.


-----------

Je passais pour lire, je ne pensais pas écrire aujourd'hui, mais en te lisant, ça m'a échapper

Bien venue quand même encore ...


(je repasserai plus tard pour écrire d'autres choses que je pensais écrire, en dehors des réponses au post de Lichemz)

[davcha]

Non, l'objectif de la jeunesse et d'affronté la vieillesse en duel, et ce par toute les excuses possible, et surtout de la supplanter, sous toutes les raisons possibles, quel qu'en soit le cout.

C'est ballot à dire, mais les plus jeunes finissent toujours par remplacer le plus vieux...

[souviron34]

Bon puisque il y a du nouveau jus dans le débat j'y viens rajouter ma petite pincée

J'ai l'impression qu'on me prend pour un "vieux grincheux", qui n'accepte pas le progrès et qui dit "ah d'mon temps c'était ben mieux !!!"...

Mais ce n'est pas ce que j'ai dit...

Ce que je dit tiens dans une citation de lichemz :

...
Bref, et pour finir, il est difficile d'avoir un avis tranché et définitif. L'informatique évolue vite, très vite même, mais on fait beaucoup de neuf avec du vieux. L'important est de savoir discerner le bon grain de l'ivraie et de savoir évoluer en toute circonstance.
.

et justement c'est bien là-dessus que l'on discutait...

Quelle est la moyenne des langages demandés sur le forum offres d'emplois de DVP ??? (et encore, moyenne je suis généreux... Quasi-totalité serait plutot exact..).

PHP, .Net, J2E

Ce qui ne me semble pas représenter la réalité décrite par les forums et les posteurs....

CQFD...


-----------
[EDIT]

Un exemple de ce qu'on dit figure sur un autre forum.. Un PO pose la question :

Quand vaut-il mieux utiliser une BDD plutôt que XML?

Ce qui prouve qu'il n'a rien compris, mais vraisemblablement qu'on lui a enseigné que XML c'était pour faire de la Modélisation avec un M majuscule, et qu'on ne lui a pas enseigné que les 2 principes dont il parlait était comme si il comparait des pommes et des poires......


[/EDIT]

[davcha]

Quelle est la moyenne des langages demandés sur le forum offres d'emplois de DVP ??? (et encore, moyenne je suis généreux... Quasi-totalité serait plutot exact..).

PHP, .Net, J2E

Ptet parce que ces 3 langages font ce qu'on leur demande correctement, et qu'on est plus productif avec...

[gorgonite]

Ptet parce que ces 3 langages font ce qu'on leur demande correctement, et qu'on est plus productif avec...

franchement, je dirais que leurs concurrents Zope (python), Rails (ruby) ou Mason (perl) peuvent faire aussi bien... mais ils sont utilisés par des publics très restreints (on reste dans le portail web puisque J2EE, ASP.Net et php sont faits pour )

alors comment expliquer cela ?
+ la mode... sans doute
+ la réutilisabilité des langages dans d'autres domaines (pour C# et Java), pourquoi pas ? mais on peut en dire autant de perl, python et ruby
+ les performances... ok ruby est lent ; mais perl et python se défendent bien sur les applis web (ou la connexion est toujours la plus lente...)

[epsilon68]

Un exemple de ce qu'on dit figure sur un autre forum.. Un PO pose la question :

Quand vaut-il mieux utiliser une BDD plutôt que XML?

Ce qui prouve qu'il n'a rien compris, mais vraisemblablement qu'on lui a enseigné que XML c'était pour faire de la Modélisation avec un M majuscule, et qu'on ne lui a pas enseigné que les 2 principes dont il parlait était comme si il comparait des pommes et des poires......

je ne suis pas d'accord,

il y a un autre sens a BDD que Modélisation
il y a aussi le sens ou on veut des data (rien de compliqué comme schema) et pouvoir y acceder de maniere assez simple (SQL, XPATH).

et dans ce cas la question peut se poser. il y a des avantages aux deux, est-ce seulement en lecture ? qui va editer les data ? d'ou viennent les datas ? y a-t-il un export xml natif ? etc ....

tu ne peux pas dire que les autres n'ont rien compris, ils n'ont rien compris de ton point de vue et de ta connaissance, rien d'autre...

[lichemz]

EN REPONSE A Hibou57 :

Salut,

Merci de ta réponse argumentée. Je vais essayer d'y apporter une forme de contradiction car je suis loin d'être d'accord avec tout ce que tu écris.

Il y a une expression... trés courante chez les « vieux » (en tous cas au moins dans ma région natale, les Vosges). Cette expression dit : «

si jeunesse savait, et si vieillesse pouvait ». Ce qui signifie que la jeunesse à souvent de l'energie, mais pas d'experience ou de maturité, et elle met

souvent son energie à faire des erreurs, tandis que la vieillesse a la maturié (dans le meilleur des cas), mais plus l'energie d'agire.

Sans vouloir paraître désagréable, je dirais que c'est le genre de proverbe que l'on peut placer à loisir dans une conversation, pour mettre fin à la contradiction sans argumenter. J'ai vu autant de "jeunes" (ça me fait bizarre d'utiliser ce mot, étant donné que je me considère comme encore jeune, mais
bon) très expérimentés que de personnes plus âgées incapables de programmer un soft de qualité. Je pense que l'informatique échappe un peu à la mécanique des métiers traditionnels.

Mais je te pose une colle tout de même : l'expérience et la maturité ne nécéssite t-elle pas le temps ?

En quoi est-ce une colle ?

C'est même un lieu commun des plus regrettables. Non, la maturité n'est pas une question d'âge ni de temps. J'ai plein d'exemples à te fournir à ce sujet.

L'expérience est plus, par définition, dépendante du temps. Mais l'expérience n'est en rien la garantie d'une expertise. Encore une fois, j'ai travaillé avec des personnes ayant de l'expérience ... mais n'étant pas vraiment au fait des standards qui garantissent un travail de bonne qualité. Avoir 30 ans d'expérience et ne pas être capable de documenter correctement son code, se livrer à des optimisations massives non nécessaires, ne pas savoir architecturer son code ("parce que je fonctionne comme ça depuis 30 ans, petit, et personne n'a jamais eu à y redire !"), c'est une forme d'expérience peu flatteuse pour moi.

Bien évidemment, ce sont là des exemples tirés de mon expérience . Je ne dis pas que c'est toujours le cas, mais juste qu'il ne faut pas associer systématiquement "expérience" à "travail bien fait". Et encore moins "travail bien fait" à "âge canonique".

Ah les belles intentions de la jeunesse, à l'exemple de ses idéaux de tolérance qu'elle met à l'oeuvre en invitant par exemple dans ces

petites fêtes étudiantes.... étrangement exclusivement les étudiants qui lui ressemble, reléguant à l'exclusion ceux/celles qui lui font peur parce que d'une

autre classe sociale que la sienne, parce que « bizzare », pas de la même culture ou autre (c.f. les taux de suicides dans les milieux étudiants... pas

seulement dut à la pression des cours.... ou plutôt dut à la pression des cours rendu insupportable par l'hypocrisie des beaux idéaux, qui font surtout usage

de belle facade - et un manque de solidarité flagrant).

Si la jeunesse était ce qu'on en dit, ça fait des siècle qu'elle aurait dut sauver le monde de son cahos.

Note : j'ai 33 ans.

Non, l'objectif de la jeunesse et d'affronté la vieillesse en duel, et ce par toute les excuses possible, et surtout de la supplanter, sous toutes les

raisons possibles, quel qu'en soit le cout.

Je t'avoue n'avoir pas trop compris le but de ce laïus. J'aimerais que tu m'expliques un peu plus précisément car pour l'instant cela me semble hautement caricatural, bourré de lieux communs et d'erreurs. Et surtout, je ne vois pas le rapport avec le sujet.

Là aussi, je suis d'accord, mais je me demande pourquoi ces fonctionnalité, quand elles sont implémentés, le sont toujours aussi mal, et

pourquoi cela nécéssite toujours des IDE aussi volumineux. Ma remarque est annecdotique, je te l'accorde.

Anecdotique, certes. La remarque sur l'aspect volumineux des IDE est, pour moi, savoureuse. L'apport des IDE ne se limite heureusement pas à des fonctions classiques. C'est faire abstraction de tout ce qu'ils peuvent apporter en termes de productivité.

Mais tu nous as mal lu! Où avons nous dit une telle chose ? Personne n'a dit « emacs c'est bien, eclipse c'est nul ».

Mais tu m'as mal lu !
Attention, à aucun moment je ne parle des intervenants sur ce topic. Mais des personnes qui dénigrent Eclipse tout en faisant l'apologie d'Emacs, j'en ai vu et plein. Chose assez marrante, ces mêmes personnes font l'objet de moquerie de la part de certains adeptes de vi, qui trouvent Emacs trop lourd et bien trop fouillis. De fait, il y a plusieurs "étages" de tolérance aux usines à gaz et chaque outil est une usine à gaz pour quelqu'un. Evidemment, lorsque l'outil est si simple qu'il devient difficile d'attaquer sa lourdeur ou sa gourmandise, on critique son austérité ou sa vétusté. Ainsi les adeptes de vi trouvent à qui parler et la boucle est bouclée.

Bien évidemment tout ceci est stérile. Il appartient à chacun de trouver l'outil le plus adapté à ses préférences mais aussi à la situation. Si je dois éditer rapidement un fichier de config ou saisir un petit texte, je lance vi. Quand je fais du C, j'aime l'environnement d'Emacs ou Anjuta. Pour le Java ou le .NET, si je peux disposer d'Eclipse ou de Visual Studio, je ne m'en priverai pas.

Je dirais que la question est de savoir : combien de temps tiendra tu face au pression de tes employeur. Combien de temps tiendra tu fasse au

ditacte de la mode.

Je dirais, quant à moi, que se poser ce genre de question c'est déjà avoir peur d'être "dépassé". Je dirais également que peut-être contrairement à toi, je n'ai pas peur de me remettre continuellement en question. Cela fait partie de l'informatique telle qu'elle nous est enseignée aujourd'hui et par ailleurs le but est "d'apprendre à apprendre". J'imagine que la perspective de pouvoir se reposer sur des méthodes et des façons de faire inchangées doit être sympathique mais je crains fort que ça ne soit pas ainsi que les choses se passent désormais. D'ailleurs, encore une fois, ce n'est pas le savoir de l'informaticien qui est en cause. C'est plutôt sa faculté d'adaptation. On n'a rien inventé de nouveau (fondamentalement, j'entends) dans l'informatique depuis 20 ans. Et pourtant, certains ont la sensation d'être perdus. Pourquoi ?

(toi qui a surement appris [je suppose], à la fac, appris à copier autruit, sous peine d'exclusion.... je dis ça, parce que tu semble en être

fraichement sorti[e]).

Une fois de plus, supposition et tentative hasardeuse d'expliquer je ne sais quoi. Je ne vois pas de quelle "copie" tu parles ni à quelle "exclusion" tu fais allusion.

Puisqu'on en est au « perso », moi j'ai un faible pour destester un langage avec une syntax qui invite au bug. Je viens encore de remarquer

tardivement un bug caché dans une de mes programme, dut à la fameuse confusion "=" vs "==".. cas typique qui démontre trop bien l'immaturité de ces lanagage,

par opposition à d'autres, conçus et murrit pour éviter ce type d'erreurs (Pascal/Ada, par exemple).

C'est pour moi un faux problème. Tu ne peux t'affranchir des règles intrinsèques du langage avec lequel tu programmes. Et je dirais qu'un compilateur bien conçu (ou un IDE intégrant une compilation à la volée) aurait dû t'avertir de la possible confusion entre les opérateurs. Eclipse, par exemple, t'avertit d'une telle possibilité d'erreur lorsque tu écris un test du type 'if(a = b)' au lieu de 'if(a == b)'.

Cela dit, il est vrai qu'en Pascal l'opérateur := est très pratique.

Et le problème est que maintenant, à cette époque actuelle, l'attitude désinvolte est érrigée en principe « fun et cool ». Genre « je fais du

C parce que ça fais style de jouer dans la cours des grand, parce que ça fait style de coder avec un langage à la syntaxe cabalistique ». Mais pour concevoir

sereinement, mieux vaut rester tranquille et ne pas s'affoler, et certains langage n'encourage pas à cette retenue (*). Puisque tu parle de ce langage, je

pense qui est à l'origine de la plus grande part des dérapage de l'informatique actuelle. D'ailleurs si tous les nouveaux langage se réclame de cette syntax,

ce n'est pas hasard... c'est pour faire « style ».. et on voit les résultats.

Encore une fois je pense que tu fais fausse route. Le C a, pour moi, une syntaxe à la fois simple, claire et concise. Et je dirais que c'est justement la raison pour laquelle tant de nouveaux langages se sont inspirés de cette syntaxe aux qualités évidentes. Tu peux y être allergique mais cela n'en rendra pas pour autant le C moins sympathique à utiliser.

De même, je ne suis pas d'accord avec le fait que le C fasse "cool et fun". Si j'étais sarcastique, je me poserais même des questions sur ce dénigrement systématique. Des problèmes avec ce langage ?
Plus sérieusement j'ai, comme beaucoup de personnes, une affection particulière envers le C, tout simplement parce que c'est (et de loin) le langage que j'ai le plus étudié et le plus pratiqué. Cela ne veut pas dire que je l'érige en principe universel.

J'ai longtemps programmé des interfaces graphiques en C sous XLib mais avec le recul, je me dis aujourd'hui que j'étais "fou" à l'époque. Si aujourd'hui je veux faire une application de gestion, nul doute que j'utiliserai Java ou C#. Si je veux manipuler des chaînes de caractères, j'irai voir du côté de Perl. Et pour du fonctionnel, j'opterai probablement pour Caml (il y a peut-être mieux). Mais le C (et le C++) présente pour moi l'énorme avantage de pouvoir se plier à presque tout : système, gestion, interfaces graphiques ... Bien sûr ce n'est pas le langage le plus adapté à chaque situation. Mais c'est un bon langage généraliste et je ne connais pas de domaine dans l'informatique dans lequel on ne peut pas utiliser le C pour des raisons techniques.

Bref, je ne vois pas le C comme une mode, un outil de "gourou" comme tu t'en fais l'écho un peu abusivement. Ce serait faire abstraction des énormes qualités de ce langage. C'est également, je te l'accorde, un langage très permissif et dont l'usage inconsidéré peut s'avérer dangereux. Mais on arrive là à la responsabilité de l'informaticien et de la qualité des outils qu'il utilise. On ne peut pas interdire la vente des couteaux sous prétexte que certains s'en servent pour tuer.

L'objectif n'est pas de coder plus vite (c.f. tes remarques sur les fonctions d'éditions semi-automatique), mais de coder mieux et plus

clairement.

Voeu pieux. Aujourd'hui on me demande de coder plus vite. Quitte parfois à ne pas être très propre. J'aimerais pouvoir coder mieux et plus clairement mais dans le cadre du travail c'est parfois difficile. Alors je réserve cela à mes projets personnels.

Et d'expérience, tu apprendra peut-être que les codages les plus clairs sont les plus verbeux, et les plus longs à rédiger, parce que quand on

y reviens, il s'avère bien plus facile à lire.

"tu apprendras peut-être" : Voilà bien le genre de condescendance polie que je remarque chez les "vieux" (et pourtant tu n'es pas très âgé). Je suis tout à fait d'accord avec ce que tu écris ici et j'en ai déjà fait l'expérience. Donc pas d'amalgame. Je ne prône pas un code concis en diable et truffé de raccourcis difficilement lisibles. Mais il faut savoir trouver un juste milieu car un code trop verbeux nuit également à la compréhension. Cela dit, mieux vaut trop que pas assez.

J'ajouterais encore que de devoir taper certaines ligne de code de manière rébarbative n'est pas ce qui peut perturber le plus quelqu'un qui

travaille. Puisque c'est automatiquement, on le tape automatiquement tout en pensant à ce qu'on fait, en anticipant parfois. Bref, il faut prendre le temps

(un contre exemple, par exemple : plus on passe vite sur un code, moins on a de chance de detecter les erreurs et les mauvaises conceptions qu'il

contient).

Sur ce plan, libre à chacun de faire comme bon lui semble. Personnellement, taper des lignes de code rébarbatives ne m'amuse en rien. Et si je dois prendre le temps de réfléchir sur un algorithme, c'est penché sur une feuille, le crayon à la main. Prendre le temps de réfléchir à mon code, oui. Perdre mon temps à écrire des centaines de lignes sans grand sens, non. Si un outil peut le faire pour moi, je l'utilise.

Beh mon/ma chèr(e), c'est tout de même un fait, hein, t'es pas d'accord ?

Absolument pas d'accord.
(et c'est MON CHER, au fait )

on faisait de la prévision météorologique avec des machines qui atteignait à peine à l'époque la puissance des 486 qui sont venu plus tard, et

on est même plus capable de faire tourner un traitement de texte sur des machines 1000 fois plus puissantes que ces anciens Cray. Et quand je dis 1000 fois

plus puissante, ce n'est pas une façon de parler. Excuse moi, mais il y a de quoi se poser des question non ?

Que faisait-on avec ces 386 ? Quelle était la précision des modèles mathématiques ? Quel était le temps de calcul ? A combien de jours était la prévision ?

De même, quelle est l'évolution des fonctions offertes par les traitements de texte ? Pour quel usage et pour qui ? Finalement, toi qui te sers peut-être de Word ou d'OpenOffice.org, as-tu réellement besoin de ces logiciels ? Ne pourrais-tu te contenter d'un simple AbiWord ou autre logiciel "light" tout à fait propre à satisfaire tes besoins alors que tu te sers peut-être à peine de 5% des fonctions offertes par Word ?

On ne peut être objectif si on ne se pose pas toutes ces questions. Je ne dis pas qu'il n'y a pas de gaspillage de "cycles" processeur pour des choses parfois inutiles. Mais passer sous silence l'évolution indéniable des logiciels pour ne pointer que leur gourmandise, c'est être un peu de mauvaise foi. Que je sache, un simple vi et un Latex suffisent à produire des documents de très haute qualité et tout ceci ne requiert guère plus qu'un 486 (et même pas d'interface graphique).

Personnellement j'utilise sur ma machine un Word 95 qui correspond tout à fait à mes modestes besoins. Lorsque mon travail doit être plus classieux et plus léché (rapport, publication), c'est Emacs + Latex. Au boulot j'ai tout l'environnement Office 2003, plus lourd mais plus complet. A chacun de faire son choix.

Peut-être un problème de conception non ?

La conception PEUT être un problème mais n'est pas toujours en cause. Les logiciels offrent souvent plus. Et ce n'est pas parce que tu n'en as pas l'utilité
qu'il faut nier l'évolution.

D'un autre côté, je reconnais que l'utilisation parfois abusive de certains frameworks peut avoir des effets pervers. Utiliser .NET c'est bien mais quand il
faut distribuer son logiciel, il faut inclure tout ou partie du framework dans le package. Ce qui peut induire des dépendances lourdes (et pas toujours justifiées), des lenteurs supplémentaires, etc. J'ai longtemps pesté contre la nécessité d'installer Java pour utiliser OpenOffice ... ce qui fait que je ne l'utilise plus.

Je passais pour lire, je ne pensais pas écrire aujourd'hui, mais en te lisant, ça m'a échapper

Bien venue quand même encore

Merci pour cet accueil en tout cas. J'espère lire ta réponse (et celle d'autres, que je n'aurai pas manqué d'interpeller) très bientôt.

Bonne journée.

[souviron34]

je ne suis pas d'accord,

il y a un autre sens a BDD que Modélisation
il y a aussi le sens ou on veut des data (rien de compliqué comme schema) et pouvoir y acceder de maniere assez simple (SQL, XPATH).

et dans ce cas la question peut se poser. il y a des avantages aux deux, est-ce seulement en lecture ? qui va editer les data ? d'ou viennent les datas ? y a-t-il un export xml natif ? etc ....

tu ne peux pas dire que les autres n'ont rien compris, ils n'ont rien compris de ton point de vue et de ta connaissance, rien d'autre...

Ce que je voulais dire c'est que BDD est un concept, une abstraction, et que ce n'est pas opposable à un outil .

C'est comme si la question était :

A quel moment bascule-t-on d'une BDD à Oracle ?

Aucune réponse possible. Problème mal posé.

Et mon exemple était pour dire que parce que XML est à la mode, on l'enseigne comme étant "La solution miracle", au risque (vu partout, et c'est ce qui rejoignait le débat) de faire confondre le fond et la forme...


La vraie question aurait plutôt été du style :

"Dans quel cas vaut-il mieux utiliser un outil comme Oracle pour gérer une BDD, ou des flats files, ou du XML ?"

[souviron34]

...
snip (avec lequel je suis d'accord pour la plupart )
...

Je dirais, quant à moi, que se poser ce genre de question c'est déjà avoir peur d'être "dépassé". Je dirais également que peut-être contrairement à toi, je n'ai pas peur de me remettre continuellement en question. Cela fait partie de l'informatique telle qu'elle nous est enseignée aujourd'hui et par ailleurs le but est "d'apprendre à apprendre". J'imagine que la perspective de pouvoir se reposer sur des méthodes et des façons de faire inchangées doit être sympathique mais je crains fort que ça ne soit pas ainsi que les choses se passent désormais. D'ailleurs, encore une fois, ce n'est pas le savoir de l'informaticien qui est en cause. C'est plutôt sa faculté d'adaptation. On n'a rien inventé de nouveau (fondamentalement, j'entends) dans l'informatique depuis 20 ans. Et pourtant, certains ont la sensation d'être perdus. Pourquoi ?
....

Je crois que les réactions "négatives", enfin plutôt de non-confiance, ne sont pas dues aux praticiens du métier, quel que soit leur age ou leur expérience, mais plutôt à l'apologie permanente du "tout nouveau" et du "avant c'était de la gnognotte" et du "maintenant c'est mieux", pas forcément de la part des pratriciens, comme je disais, mais bien plutôt de la part des commerciaux et adminsitratifs.

Ce n'est pas la crainte d'être "dépassés", je pense que c'est plutôt la "ringardisation" par ces 2 catégories, qui présupposent que parce que tu n'as pas utilisé ce dernier outil, tu n'es qu'un HasBeen, et donc tu vaux pas la peine.. Je reviens sur le "expert sénior .... moins de 2 ans d'expérience".. qu'on voit partout dans les annonces de grosses SSII..

Je pense que tous autant que nous sommes nous sommes (à quelques exceptions près) intéressés par apprendre de nouvelles choses. Encore faut-il qu'on nous en laisse le loisir... et pas forcément à nos heures perdues... Mais justement sur la base du fait que si on a pratiqué N plateformes, M langages, on peut bien en pratiquer un N+1 ième ou M+1 ième...

Et enfin, je pense que quand dans le débat il y a mention de "jeunes" opposés à "anciens", c'est plus pour la question fondamentale du titre du topic...

C'est simplement par le fait (et il est normal qu'à 24, 27, ou même 32 ou 35 ans, on n'en ai pas encore fait l'expérience, et qu'on ne le ressente pas de cette manière parce qu'on n'a pas la même notion du temps) que quand tu as travaillé 15 ou 20 ans, tu aimerais pouvoir faire partager ton expérience (qui en est une), que de l'eau a coulé sous les ponts certes, mais que les "jeunes" ne sont pas forcément plus "intelligents" ou "meilleurs" que les "vieux" (voir les architectes : les ponts ou amphithéatres romains tiennent toujours 2000 ans après, alors qu'une aile de Roissy ne tient pas 25 ans.. ).

Et que les "anciens" ont vu, se sont cassés la tête, et ont résolus (dans certains cas) des problèmes dont on pense soudainement que "la solution est simple !! Avec cet outil c'est fini"... Quoi qu'on en dise, il en va dans la vie au travail comme dans la vie tout court.. Un pilote d'avion ou de navire est plus à même de faire face aux imprévus si il a 6000 h de vol que 250...

[lichemz]

Je suis d'accord avec souviron34 sur l'utilisation abusive du XML, parfois à tort et à travers.

J'ai travaillé il y a 6 mois sur un projet Java sur lequel on devait se farcir toute une API de gestion du XML ... pour utiliser 3 pauvres fichiers de config de 10 lignes tout au plus qui auraient gagné à être convertis en .properties. Mais non, le client voulait du XML et on n'a jamais réussi à le convaincre qu'avec de simples fichiers properties il ne perdait pas au change, bien au contraire !

Sur ce point je rejoins l'avis de beaucoup ici, à savoir que l'utilisation d'une technologie ne doit pas se faire sur la seule base du discours des commerciaux mais après une mûre réflexion sur son adéquation avec le besoin réel.

[epsilon68]

Quand vaut-il mieux utiliser une BDD plutôt que XML?

désolé tu ne peux pas dire que le mec n'a rien compris.

Perso, Je rencontre souvent des contraintes (infrastructure client, interaction flash, lecture seul, data provenant d'une db exportant du xml natif, etc) qui font que je prefere dans pas mal de cas des fichiers xml à une db. D'autre fois, je passe par une DB intermediaire pour aggreger les data et les manipuler puis re-sortir du xml pour une application.

La personne qui a posé cette question a certainement une expérience différente des DB et des data que toi ou moi ou un autre, il y a tellement de type d'application.

en tous les cas, je peux comprendre ce genre de question.

Quant aux fichiers de config, pour moi ca ne fait pas de difference.
J'ai aussi eu des cas ou les fichiers xml etaient plus pratique a faire evoluer ou a rajouter des options et d'autre cas ou un fichier properties etait tres pratique. Par contre si le client veut de l'xml, pour moi il n'y a pas de probleme, ca ne fait pas grande difference en temps de developpement.

[souviron34]

Pour clore ce point :

en tous les cas, je peux comprendre ce genre de question.

Moi non

xml n'est qu'un moyen de faire une bd.. De même faire une structure de fichiers textes répartis par sous-répertoires. De même faire des tables de relations.

Ce n'est pas opposable au concept Base de Données

Nous sommes scientifiques à la base, les termes ont une signification...

[epsilon68]

Pour clore ce point :
Moi non
xml n'est qu'un moyen de faire une bd.. De même faire une structure de fichiers textes répartis par sous-répertoires. De même faire des tables de relations.
Ce n'est pas opposable au concept Base de Données
Nous sommes scientifiques à la base, les termes ont une signification...

je crois qu'on ne lit pas la question de la meme facon, et qu'on ne la comprend pas non plus pareil. Tu peux nous donner le lien du post pour que je me fasse une meilleure idée du context ?

[souviron34]

je crois qu'on ne lit pas la question de la meme facon, et qu'on ne la comprend pas non plus pareil. Tu peux nous donner le lien du post pour que je me fasse une meilleure idée du context ?

Justement pas de contexte

http://www.developpez.net/forums/sho...d.php?t=378642

[doccpu]

Deux visions de notre métier qui s'affrontent, et ne se rejoindrons jamais.

Une vision presque artistique, comme pour souviron34 et moi; Ce n'est pas pour rien que je parle d'art. Faire un logiciel est un art très complet.

Une vision Time-to-market, productivité, réduction des couts de l'informatique, auquel répondent les nouvelles technologies.

Je reviens sur ce post pour rajouter mon grain de sel.
Pour moi il n'y a qu'une informatique celle qui est pratiqué par des passionné comme moi qui sont tombé dedans quant ils étaient petits (pour mon cas je développais en basic et logo à 7 ans), et puis il à l'informatique commerciale bidon ou le but c'est de faire du chiffre vite et a la vas comme je te pousse au prix d'un effort de maintenance gigantesque par la suite. Exemple flagrants : Firefox et Internet Explorer avec ses SP1,2,...

La première ne dit pas que tout est possible (surtout en termes de délais) mais quant elle fait quelque chose sa tien des décennies et plus important on peux construire dessus de manière fiable (Java1, C++)

La seconde dit que tout est possible (surtout en termes de délais) mais ce qu'elle fait est presque impossible à modifier à faire évoluer, ça tien rarement très longtemps on ne peux pas changer la moindre chose au niveau matériel puisque l'application est dédié la plus part du temps. Comme c'est fais rapidement on a pas de documentations techniques (on a juste le temps de faire les doc utilisateurs)donc dès qui en à 1 développeur qui part plus personne sait faire apart des taré du code comme moi qui arrivent à retrouver les petits parce qu'ils ont pris le temps d''apprendre les bases.

Personnellement je trouve que l'on ne veux plus prendre le temps de se retourner parce que l'on crois que tout est déjà fais, que tout est possible parce que l'on vois une entreprise comme microsoft ou ibm qui peux faire des choses incroyables. Le problème est que ses choses ne sont pas viables parce qu'elle ne sont pas développé pour la durée mais pour le profit(.net Framework 1,2,3,3.5, à quand la 3.6,...,4,...205641546 SP70336 :-p). le pire c'est que les ingénieurs en informatique qui produisent ces softs se sentent obligé de suivre car ils on peur de perdre leurs place.

Au fait vous avez déjà vu un technicien dans des réunions d'avant vente hors mis un ingénieur ? non ? C'est normal un technicien ne sait pas communiquer face a un commercial de l'entreprise cliente. Un ingénieur est la pour dire "Oui monsieur, c'est tant d'euro" et c'est le technicien qui doit faire en sorte que tout fonctionne bien. J'ai rarement vu un ingénieur coder et donc permettre à une carte d'acquisition qui à une tolérance de +/-300 décimal d'avoir des acquisitions d'une précision de +/- 5 décimal au prix d'une perte de temps qu'il faudra rattraper ensuite par une threading, qui vérouillera l'application sur 1 seule plateforme (Licences payantes interdites, puisque un techno n'a pas de pouvoirs d'achat dans une entreprise), qui obligera à développer 256000 versions du même logiciel et tout ça en 1 mois avec 1 développeur. C'est de l'arnaque organisé par les requins de la finances que sont les PDG. Mais bon puisque tous les PDG aiment se faire arnaquer...

A propos des licences :
Cela me parais débile, c'est comme si l'on demandais à un chirurgien neurologue de travailler avec un hachoir parce que ça coûte moins cher qu'un scalpel avec l'argument "Mais pourtant ça coupe autant qu'un scalpel, c'est moins cher et ça coupe même les os!", le problème étant que c'est moins précis et que ca fais plus de déga que ça n'en répare.

Personnellement je m'intéresse depuis longtemps à l'informatique(19ans). Je m'intéresse depuis peu à la programmation système. Je me suis aperçu avec effrois que c'était IBM qui avais fixé les règles du jeux en matière de programmations informatiques et que personne n'a eu le courage (pour rester polis) de faire quelque chose de mieux en matière de logique.

Personne ne c'est dit que mettre l'interruption de la 2ème interface parallèle avant l'interruption de la première avec au milieux l'interruption de la disquette était complètement débile et générateur d'incompréhensions. Mais non, il faut tout compliquer faire en sorte que tout soit vérouillé pour pouvoir déposer des brevets. Pour que personne apart soit même ne soit capable de maintenir le tout. C'est comme le standard IEEE pour les flotants, tout le monde sait que sa sert a rien d'avoir un +0 et un -0, mais eux ils l'ont implémenté. En plus leur format fais des aproximations nuisibles dans les programmes(surtout dans le domaine bancaire) mais maintenant un processeur qui n'implémente pas cette norme est invendable.

Enfin bref, au plus j'en apprend sur l'informatique plus je m'aperçois que la base est une usine à gaz et qu'on ne fait que rajouter des couche d'usine à gaz histoire de la rendre encore plus problématique à comprendre et à maintenir.

A savoir quand même pour nos chers ingénieurs et commerciaux que Ibm et Microsoft remettent tous leur développements à plat à chaque version de leurs logiciels et qu'ils arrivent ainsi à faire des miracles car à chaque fois ils démontent tout et reconstruisent tout. Ensuite il ne sont pas 4 ingénieurs à taper sur 1 seul développeur mais 1 ingénieur pour une dizaine(voir+) de développeurs. C'est ce que l'on appelle le travail en équipe et ça permet une cadence de codage incroyablement plus rapide que nos modèles français actuels.

Cependant cela ne permettra jamais d'avoir 1 enfant en 1 mois avec 9 femme enceintes .

Sous Windows au moins, il n'y en a qu'un, pas besoin de se compliqué la vie

Est-tu vraiment convaincu de ce que tu a dit la ? Non parce que après un rapide petit tour sur les API windows 16 et 32 il me faut vite une capsule acide acétylsalicylique(aspirine, pour les non spécialistes du domaine concerné(débutants en pharmacologie)).

Malheureusement pour nous l'informatique actuellement c'est ca:


Cordialement

[gorgonite]

C'est comme le standard IEEE pour les flotants, tout le monde sait que sa sert a rien d'avoir un +0 et un -0, mais eux ils l'ont implémenté. En plus leur format fais des aproximations nuisibles dans les programmes(surtout dans le domaine bancaire) mais maintenant un processeur qui n'implémente pas cette norme est invendable.

as-tu vraiment regarder de près le format des float dans un CPU intel ?

le format interne n'est pas celui IEEE, et si par malheur tu ajoutes un printf bien placé dans ton code, tu peux faire changer la valeur d'une variable à laquelle tu n'as pas touché !!!

[doccpu]

as-tu vraiment regarder de près le format des float dans un CPU intel ?

le format interne n'est pas celui IEEE, et si par malheur tu ajoutes un printf bien placé dans ton code, tu peux faire changer la valeur d'une variable à laquelle tu n'as pas touché !!!

Extrait de :
Intel® 64 and IA-32 Architectures
Software Developer’s Manual
Volume 1:
Basic Architecture
page : Vol. 1 4-13

4.8 REAL NUMBERS AND FLOATING-POINT FORMATS
This section describes how real numbers are represented in floating-point format in
x87 FPU and SSE/SSE2/SSE3 floating-point instructions. It also introduces terms
such as normalized numbers, denormalized numbers, biased exponents, signed
zeros, and NaNs. Readers who are already familiar with floating-point processing
techniques and the IEEE Standard 754 for Binary Floating-Point Arithmetic may wish
DATA TYPES
4.8.1 Real Number System
As shown in Figure 4-10, the real-number system comprises the continuum of real
numbers from minus infinity (− ∞) to plus infinity (+ ∞).
Because the size and number of registers that any computer can have is limited, only
a subset of the real-number continuum can be used in real-number (floating-point)
calculations. As shown at the bottom of Figure 4-10, the subset of real numbers that
the IA-32 architecture supports represents an approximation of the real number
system. The range and precision of this real-number subset is determined by the
IEEE Standard 754 floating-point formats.
4.8.2 Floating-Point Format
To increase the speed and efficiency of real-number computations, computers and
microprocessors typically represent real numbers in a binary floating-point format.
In this format, a real number has three parts: a sign, a significand, and an exponent
(see Figure 4-11).
The sign is a binary value that indicates whether the number is positive (0) or negative
(1). The significand has two parts: a 1-bit binary integer (also referred to as
the J-bit) and a binary fraction. The integer-bit is often not represented, but instead
is an implied value. The exponent is a binary integer that represents the base-2
power by which the significand is multiplied.
Table 4-5 shows how the real number 178.125 (in ordinary decimal format) is stored
in IEEE Standard 754 floating-point format. The table lists a progression of real
number notations that leads to the single-precision, 32-bit floating-point format. In
this format, the significand is normalized (see Section 4.8.2.1, “Normalized
Numbers”) and the exponent is biased (see Section 4.8.2.2, “Biased Exponent”). For
the single-precision floating-point format, the biasing constant is +127.

[gorgonite]

ben dommage, mais cela c'est le format sous lequel est renvoyé le float, pas celui sur lequel travaille le processeur... qui est sur 80 bits si je me souviens bien


tu peux vérifier : cet exemple est un cas d'école d'application de l'interprétation abstraite