Le débat lancé par GT est très juste. C'est une question à laquelle j'ai souvent réfléchi ces dernières années.
L'assembleur, c'est de
l'artisanat, nous en sommes tous convancus, mais est-ce de
l'art?
GT Turbo (qui cîte Zappy) :
le seul moyen -d'arriver au but recherché: le programme parfait, maîtrisé de A à Z, qui ne gaspille pas un seul cycle,
Là, on est dans
l'artisanat...
GT Turbo (qui finit de cîter Zappy) :
juste pour la beauté du code. Oui, la beauté!
Et ici, on est dans le domaine de
l'art!
(un art fondé de surcroît sur un postulat paradoxal, puisqu'il associe la beauté au code assembleur, qui habituellement semble indigeste!)
La difficulté, c'est que le code, ce n'est pas le produit fini. Dans le produit final, on se fiche pas mal de la beauté du code. Tout comme l'auditeur du début du siècle se fichait pas mal des commentaires humoristiques qu'Erik Satie (le compositeur) mettait sur ses partitions de piano!... et qui de fait, n'avait pour seul lecteur que le pianiste!
Nous c'est pire! Notre code assembleur, il a pour seul lecteur un micro-processeur! Pour la reconnaissance de la beauté de notre "geste", c'est pas gagné!
GT Turbo :
Et dire que ce langage est un morceau de l'histoire de l'informatique et on va le passer a la trappe sans protester Arghhh !!
Très juste! Car en tout état de cause, si nous sommes effectivement en face d'un patrimoine qui a une certaine valeur, doit-on alors le laisser mourir? laisser tomber dans l'oubli cet artisanat (ou cet art) sans essayer d'en préserver quoi que ce soit?
(vous comprenez le pourquoi de WikiPendium, maintenant?
)
GT Turbo :
Ca me brise le coeur, fini les optimisations 'polonaises', bientot on aura oublié qu'un micro processeur possèdes des registres 
Oui, car on peut parler de "l'art" d'optimiser, surtout quand c'est juste pour la beauté du code (comme le souligne si bien Zappy)!
Et vous tous le savez bien, vous programmeurs en assembleur (devrait-on dire
créateurs en assembleur?), qui avez vécu comme moi cette expérience où l'on prend soudain conscience de cette forme de beauté, de perfection qui se dégage du code...
C'est une expérience un peu mystique en fin de compte : il faut l'avoir vécue pour la comprendre. Les arts Zen, également fondés sur de telles expériences, sont pour leur part longtemps restés hors de portée des occidentaux. Jusqu'à ce que certains s'y initie et vivent l'expérience de la "plénitude" à travers la pratique d'un art Zen (tir à l'arc par exemple). En fin de compte, le résultat de notre expérience est comparable : un expérience de satisfaction intense devant le résultat qu'on a réussi à obtenir.
Dans une démo, c'est le beau (du code) qui est caché derrièrer le beau (de la démo). Mais comment faire connaître aux gens ce beau? En tout cas, si on trouve une réponse, il faudra en parler à Erik Satie
(son génie n'a jamais été reconnu de son vivant).
Autre point d'écueil, c'est que cette satisfaction est en vérité double, et cela est une source d'ambiguité : le code
est beau et il
produit le résultat attendu. C'est ambigü parce qu'on peut mettre l'accent sur l'un ou l'autre des deux aspects (soit je cherche à ce que ça marche, quitte à écrire comme un cochon, soit je fais un truc élégant, quitte à ce qu'il ne marche pas bien dans tous les cas), mais au final, il restent liés, car il est difficile d'en écarter complètement un pour ne garder que l'autre.
Par exemple, les entreprises se focaliseraient volontiers sur le seul résultat (vis-à-vis de leurs clients, c'est la seule chose qui compte), mais (mêmes elles!) elles ne peuvent le faire totalement au détriment de tout le reste. On peut peut-être même voir sous cet angle ce qui est arrivé à MS avec Win95. Puristes dans leur démarche, ils voulaient peut-être ne se focaliser que sur le résultat, mais la réalité les aura rattrappé, car le code de mauvaise qualité ne produisait pas le résultat attendu! Il leur a donc fallu se soucier
aussi de la gueule du code.
GT Turbo :
Merci a tous les constructeurs de micro-ordinateur, qui au lieu de laisser certaines personnes optimisé leur code font une pitoyable et commercial course de puissance sur leur machine. RaZ m'a donné un PC mais je vous avoues qu'après quelques jours passé dessus, j'ai l'impression que le TOS est quand meme mieux fini que Windows.....
Ils ne sont pas dans le même domaine. Ils sont bien loin de l'artisanat, et donc encore plus loin de l'art. Ils sont dans la
production commerciale, les volumes de masse, l'efficacité, l'attention au résultat. Rien de mal à cela (ça donne du pain à manger à plein de gens!) mais il n'empèche que ça n'a rien à voir avec une démarche attentive à la beauté du "geste". Ca ne part pas sur les mêmes bases, c'est un autre objectif, c'est autre chose tout simplement.
Kochise :
(i++=1, en fait i+=1 qui est la simplification de i=i+1, comme en basic).
Ce que voulait dire GT, c'est que en C, l'instruction i++=1 est valide, mais son résultat est indéfini. Le C ne dit pas si ça retourne 1 ou 2. Personne ne peut le prédire, et c'est le compilateur qui décide ce que ça va retourner.
(c'est un exemple classique, cité par tous les détracteurs du C
)
Mais tout cela n'enlève rien du génie absolu du C : créer une couche d'abstraction pour favoriser la portabilité (une idée toute con, mais géniale quand même!). Linux existerait-il sans le C? Sur combien de plateformes on arrive à faire tourner Linux? N'est-ce pas là un tour de force?
Zerosquare :
- des programmeurs compétents en assembleur, on n'en voit plus beaucoup
Des artistes du code assembleur non plus
Zerosquare :
- il n'y a pas de mystère, au niveau productivité pure y'a pas photo. À moins d'être un dieu, ça va quand même plus vite de bidouiller un truc en C que d'optimiser un code en assembleur. Et comme la tendance actuelle est de sortir les trucs le plus vite possible, quitte à ce que ça bouffe des ressources hardwares démesurées, le calcul est vite fait pour les entreprises.
Ce qui veut bien dire qu'on est passé d'un monde à l'autre : de l'artisanat/art à la production de masse.
Orion_ :
l'asm est mort depuis bien longtemps déja
Ca dépend de quoi on parle. Mort pour les entreprises, peut-être, mais mort pour nous autres artisans, je ne pense pas
Orion_ :
ça me motive plus de coder comme ça une fois arriver a la maison, c'est pour ça que en hobby j'ai decider maintenant de m'eloigner le plus possible des PC et autres machines d'aujourd'hui pour m'orienter vers du oldschool avec du bon vieux code et bidouille d'époque, donc asm 
mais ça reste parceque je suis passioné d'oldschool
bien d'accord, et c'est normal. La logique d'entreprise est bonne pour le développement de l'entreprise, mais pas forcément en accord avec le développement de l'individu. Quand tu rentres chez toi, tu t'occupes avant tout de toi, et le "oldschool" est plus satisfaisant pour toi (comme pour moi d'ailleurs
), c'est plus positif pour ton développement personnel (pour le mien aussi), pour ta vie à toi quoi.
non?
En conclusion de ce post très philo, je propose qu'on rédige un jour un manifeste
et on l'appellera le "manifeste des
créateurs en assembleur" !
(et si j'ai dit plein de conneries, faites m'en part, mais tapez pas trop fort
)
)
) et second atout de l'assembleur les programmes en sorti sont beaucoup plus court, actuellement on veut le contraire car cela fait vendre de la ram et des disques durs.....
!
)
Assembleur
)
il faut avoir la bonne bibliothèque et zou !!! soit il y en a une qui affiche ça avec un bête circle(x,y,r); soit il faut le faire point par point, comme en asm 
). Même une appli complète de A à Z, si vous en avez envie.
(son génie n'a jamais été reconnu de son vivant).
)
et on l'appellera le "manifeste des créateurs en assembleur" !