Plus précisément 57 ans, j'ai écrit mon premier programme, en Fortran, lors de mes études d'ingénieur, en 1965.
L'évolution des langages de programmation ?
Pas grand chose à en dire, on peut programmer comme un goret* (c'est hélas souvent le cas) avec n'importe quel langage et faire les choses bien également avec n'importe quel langage, cela dépend essentiellement de la personne qui programme.
Je dirais qu'un tournant important a été fait avec Algol** (le langage de programmation, pas l'étoile), il apportait la récursivité, la structure en blocs, le typage, bref, tout ce qu'il fallait pour faire de la programmation structurée. C'est le précurseur académique de C, Pascal, Modula, Ada etc.
Je ne suis pas un fanatique des langages objets, dans la mesure où c'est un oreiller de paresse, on peut parfaitement programmer avec le paradigme "objet" en C, par exemple, aucun problème pour implémenter la notion d'héritage en C, on crée une hiérarchie de fonction, ce n'est pas automatique, il faut le coder, mais on y gagne beaucoup en performances, comme je l'ai montré dans un benchmark C <-> C++.
J'ai tâté de la programmation logique avec Prolog, intéressant sur le plan scientifique et intellectuel, mais pas vraiment utile dans mon domaine.
APL, langage où l'élément d'information est un tableau sans dimension prédéfinie aussi intéressant sur le plan intellectuel, plaît aux matheux purs et durs (on programme une inversion de matrice en une ligne). À l'opposé des matheux, on peut l'utiliser pour du prototypage, pour valider rapidement un algorithme, que l'on reprend ensuite dans un langage plus adapté.
Pour conclure, je dirai que ce qui a le plus changé, ce sont les outils mis à disposition pour programmer : éditeur, debuger, environnement de programmation, etc.
Outils que je n'utilise pratiquement pas. J'utilise un éditeur que j'ai écrit en C; au début des années 80, avec le souci de portabilité et, depuis près de 40 ans, je le transporte de plateforme en platforme. Avec l'avantage que, quelle que soit la plateforme, j'ai le même éditeur. Ce sera sans doute mon premier programme "sérieux" en Rust le portage de mon éditeur.
Pour les debuger, Je suis de la vieille école, celle où la compilation de 200 lignes de Fortran prenait 10 minutes et où on n'avait pas accès directement à la machine et où l'on pouvait, au mieux, avoir trois passages par jour en machine. Alors, je peaufine soigneusement le source avant de compiler et tester et je n'ai pas trop besoin de debuger, dans les cas rétifs***, je parsème le code de "display" de certaines variables et cela me suffit amplement.
Mon environnement de programmation est simple : sous Linux, un grand écran, 3 consoles ouvertes : une contenant l'édition du source, une autre le lancement de la compilation (ou de l'assemblage) et une troisième pour le test. C'est simple et efficace.
.
.
.
. * Avant ma retraite, j'enseignais la programmation embarquée dans une école d'ingénieurs, je disais souvent à mes étudiants lors des TP (travaux pratiques) : "profitez d'être à l'école pour bien faire les choses, vous aurez tout le temps dans l'industrie de faire de la saloperie".
** Algol précédait d'une dizaine d'années mon premier programme, ce n'est que plus tard, une dizaine d'année après que j'en ai compris l'importance.
*** Le cas le plus rétif que j'ai eu dans toute ma carrière, c'était, en fin des années 1960, sur un programme assembler pour l'IBM 1620. J'avais écrit comme code opération TF (transfert arrêté par un flag d'une position mémoire à une autre position) à la place de TFM (transfert à une position mémoire du deuxième opérande de l'instruction). Impossible de faire une analyse post-mortem de la mémoire, le bug mettait toute la mémoire à zéro. Alors je faisais le cheminement à la main, j'arrivais sur le TF fautif, je disais je fais le transfert d'adresse (raisonnement évidemment faux), cela a duré pratiquement une semaine. Et cela m'a marqué profondément, la preuve, je m'en souviens en détail plus de 50 ans après.
[^] # Re: C'est officiel...
Posté par abgech . En réponse au journal Rust dans Linux, ça démarre fort!. Évalué à 10.
Plus précisément 57 ans, j'ai écrit mon premier programme, en Fortran, lors de mes études d'ingénieur, en 1965.
L'évolution des langages de programmation ?
Pas grand chose à en dire, on peut programmer comme un goret* (c'est hélas souvent le cas) avec n'importe quel langage et faire les choses bien également avec n'importe quel langage, cela dépend essentiellement de la personne qui programme.
Je dirais qu'un tournant important a été fait avec Algol** (le langage de programmation, pas l'étoile), il apportait la récursivité, la structure en blocs, le typage, bref, tout ce qu'il fallait pour faire de la programmation structurée. C'est le précurseur académique de C, Pascal, Modula, Ada etc.
Je ne suis pas un fanatique des langages objets, dans la mesure où c'est un oreiller de paresse, on peut parfaitement programmer avec le paradigme "objet" en C, par exemple, aucun problème pour implémenter la notion d'héritage en C, on crée une hiérarchie de fonction, ce n'est pas automatique, il faut le coder, mais on y gagne beaucoup en performances, comme je l'ai montré dans un benchmark C <-> C++.
J'ai tâté de la programmation logique avec Prolog, intéressant sur le plan scientifique et intellectuel, mais pas vraiment utile dans mon domaine.
APL, langage où l'élément d'information est un tableau sans dimension prédéfinie aussi intéressant sur le plan intellectuel, plaît aux matheux purs et durs (on programme une inversion de matrice en une ligne). À l'opposé des matheux, on peut l'utiliser pour du prototypage, pour valider rapidement un algorithme, que l'on reprend ensuite dans un langage plus adapté.
Pour conclure, je dirai que ce qui a le plus changé, ce sont les outils mis à disposition pour programmer : éditeur, debuger, environnement de programmation, etc.
Outils que je n'utilise pratiquement pas. J'utilise un éditeur que j'ai écrit en C; au début des années 80, avec le souci de portabilité et, depuis près de 40 ans, je le transporte de plateforme en platforme. Avec l'avantage que, quelle que soit la plateforme, j'ai le même éditeur. Ce sera sans doute mon premier programme "sérieux" en Rust le portage de mon éditeur.
Pour les debuger, Je suis de la vieille école, celle où la compilation de 200 lignes de Fortran prenait 10 minutes et où on n'avait pas accès directement à la machine et où l'on pouvait, au mieux, avoir trois passages par jour en machine. Alors, je peaufine soigneusement le source avant de compiler et tester et je n'ai pas trop besoin de debuger, dans les cas rétifs***, je parsème le code de "display" de certaines variables et cela me suffit amplement.
Mon environnement de programmation est simple : sous Linux, un grand écran, 3 consoles ouvertes : une contenant l'édition du source, une autre le lancement de la compilation (ou de l'assemblage) et une troisième pour le test. C'est simple et efficace.
.
.
.
. * Avant ma retraite, j'enseignais la programmation embarquée dans une école d'ingénieurs, je disais souvent à mes étudiants lors des TP (travaux pratiques) : "profitez d'être à l'école pour bien faire les choses, vous aurez tout le temps dans l'industrie de faire de la saloperie".
** Algol précédait d'une dizaine d'années mon premier programme, ce n'est que plus tard, une dizaine d'année après que j'en ai compris l'importance.
*** Le cas le plus rétif que j'ai eu dans toute ma carrière, c'était, en fin des années 1960, sur un programme assembler pour l'IBM 1620. J'avais écrit comme code opération TF (transfert arrêté par un flag d'une position mémoire à une autre position) à la place de TFM (transfert à une position mémoire du deuxième opérande de l'instruction). Impossible de faire une analyse post-mortem de la mémoire, le bug mettait toute la mémoire à zéro. Alors je faisais le cheminement à la main, j'arrivais sur le TF fautif, je disais je fais le transfert d'adresse (raisonnement évidemment faux), cela a duré pratiquement une semaine. Et cela m'a marqué profondément, la preuve, je m'en souviens en détail plus de 50 ans après.