Ces pages tout comme celles consacrées aux autres sujets (architecture, système d'exploitation, maintenance) sont autant un aide-mémoire pour moi-même que des informations que je mets à la disposition de tout qui voudrait y chercher des renseignements.
Au cours de ma carrière en tant qu'ingénieur informaticien (de 1977 à 2002) j'ai utilisé bon nombre d'environnements de programmation. Les langages de programmation qui me sont les plus familiers sont l'assembleur, le C et le C++. J'ai bien sûr testé d'autres langages (Prolog parce qu'il fut un temps où c'était la mode, Visual Basic pour les applications Microsoft, JavaScript et PHP pour mes pages WEB et Python par curiosité) mais ne puis prétendre avoir avec ces derniers langages autant d'expérience qu'avec le C ou le C++.
Autant le préciser de suite, les métiers de la programmation évoluent. J’ai cessé de programmer au niveau professionnel en 2002. Ces notes ne sont donc pas destinées à ceux qui sont à la recherche des dernières nouveautés en matière de programmation. J’essaie par contre de garder à jour des outils de programmation anciens qui peuvent toujours servir. Un peu comme une nostalgie des métiers d’antan. C’est vrai que les programmeurs en assembleur appartiennent au passé comme les allumeurs de réverbères. Mais si ces façons anciennes de programmer vous intéressent, vous trouverez dans ces pages comme sur une série d’autres sites de passionnés, de quoi vous amuser.
Seuls ces compilateurs anciens et les librairies associées qui fonctionnaient à l'époque du DOS ou de Windows 9x fournissent des fonctions capables d'interagir directement par des fonctions "in" et "out" avec les ports d'entrées/sorties. Choses qui ne sont plus autorisées avec les versions actuelles de Windows mais qui restent possibles et fort intéressantes par exemple pour "bidouiller" des petits montages à brancher sur le port parallèle.
Vous trouverez sur ce site des notes qui font référence à des environnements de développement déjà anciens, de très anciennes versions des EDI de Borland par exemple. De tels environnements de développement ne conviennent pas pour écrire des applications graphiques sous Windows mais suffisent tout à fait pour ceux qui voudraient s'essayer à la programmation en C ou en assembleur et qui n'auraient pas à leur disposition des outils plus récents. De toute façon ce qui en programmation est intéressant c'est la logique de programmation, pas l'outil de développement en lui-même.
Il n'y a pas de réponse objective à cette question. C'est un peu comme si on demandait "Quel sport me conseilleriez-vous pour en avoir le plus de plaisir ?" ou "Quel instrument de musique dois-je apprendre pour devenir un bon musicien ?" Si je parle d'assembleur, de C ou de C++ dans ces pages, c'est parce que j'ai utilisé ces langages pendant 25 ans à raison de huit heures par jour. Je ne dis pas que ce sont les meilleurs ni ceux qui vous conviendront le mieux.
Ce sont seulement ceux que je connais le mieux. Quant au sport, celui qui vous donnera le plus de plaisir est celui dans lequel vous aurez acquis le plus d'habilité, une réponse analogue pourrait être donnée pour les instruments de musique et pour les langages de programmation.
En recherchant toujours la solution la plus simple. En la matière, mieux vaut être trivial que génial. Faites vos programmes en pensant que dans quelques mois il faudra savoir les modifier et donc les relire et les comprendre. Pensez qu'à ce moment vous serez probablement dans de mauvaises conditions. C'est alors que vous maudirez les soi-disant traits de génie que vous avez eu, le manque de commentaire ou les labels qui ne veulent rien dire ou qui parfois même signifient autre chose que ce qu'ils représentent, ça arrive !
Un programme compliqué même s'il "marche" est un mauvais programme.
Les bons programmes sont simples et c'est toujours possible même pour résoudre des problèmes complexes.
L'art, le vrai celui qui a du mérite, est de simplifier le problèmes pas de les gonfler !
Les ordinateurs ne lisent pas vos codes source. Il n'auront jamais aucune estime pour vos prouesses subtiles mais inintelligibles et, si c'est votre manière de travailler, vos collègues de travail préfèreront réécrire vos programmes que d'essayer de les comprendre. En matière de programmation, c'est comme pour la conduite automobile, il faudrait toujours respecter ces règles : prudence et courtoisie. C'est plus sympa pour les autres et vous verrez que pour vous même vous vous simplifierez la vie.
C'est comme pour le sport ou la musique : par la pratique.