Niklaus WirthTyomitch, Copyrighted free use, via Wikimedia Commons

Niklaus Wirth, inventeur du Pascal et lauréat du prix Turing, est décédé

Niklaus WirthTyomitch, Copyrighted free use, via Wikimedia Commons

On doit à Niklaus Wirth plusieurs langages de programmation, notamment EULER, Pascal et son évolution Modula. On lui doit également la loi de Wirth, formulée en 1995 dans son « Plaidoyer pour des programmes légers ». Elle dit que « les programmes ralentissent plus vite que le matériel n'accélère », en opposition donc à la Loi de Moore.

Dans les années 60, il était professeur à Stanford, avant de revenir en Suisse, à l’École polytechnique fédérale de Zurich où il était professeur d’informatique jusqu’en 1999. En 1984, il est le lauréat du prix Turing, que l’on compare régulièrement au Nobel de l’informatique.

Il est décédé ce 1ᵉʳ janvier 2024, à l’aube de ses 90 ans. L’École polytechnique fédérale de Zurich consacre un long article à sa carrière.

Commentaires (18)


RIP :(

Je n'ai personnellement jamais utilisé ce langage ou ses dérivés, mais je pense qu'il a marquè beaucoup de monde.
:pleure:
J'ai appris la programmation avec Pascal et Modula.

PS: Il marche chez vous le lien vers l'EPFZ ?
Non, le voilà en attendant : https://ethz.ch/en/news-and-events/eth-news/news/2024/01/computer-pioneer-niklaus-wirth-has-died.html
Il risque pas, car il est vide.
BEGIN
(...)
END

http://ctp.mkprog.com/en/pascal/block_statement/

Le langage était utilisé en prépa scientifique, à la fin des années 80/début 90, comme introduction à la programmation. Un peu grâce à Borland et son Turbo-Pascal il faut bien le dire!

Ensuite en école d'ingé c'est le C qui régnait déjà, avec le C++ qui commençait à prendre (bien poussé par les interfaces graphiques qui se généralisaient).
Modifié le 05/01/2024 à 09h30
ce turbo pascal était génial.... et ce bleu/jaune me manque :)
Rha je suis content d'avoir échappé au Pascal (par contre j'ai pas échappé au Cobol ...)
Et surtout, j'ai réussi à éviter Delphi, très mauvais héritier de Pascal

Sinon Wirth a tout à fait raison concernant la lourdeur des logiciels qui croît avec la puissance des machines, c'est lié au "creeping featurism" qui engloutit des ressources pour rien ...
en gros t'as échappé au meilleur des trois , c'est dommage :D
Perso, je retiens surtout la loi de Wirth qui se vérifie encore malheureusement et tant que la montée en puissance du matériel permet encore de masquer le manque de qualité des programmes.

J'aimerais tellement que l'on puisse un jour faire mentir cette loi.

J'aimerais tellement que l'on puisse un jour faire mentir cette loi.


Pas certain ce que ce soit forcément une bonne idée.

Dans le cas ou le ralentissement relatif est causé par l'ajout bloatware marketing, ok.
Vivement qu'on arrête l' enshittification

Mais ce ralentissement c'est souvent le prix a payer pour la modularité/abstraction.
Et si l'informatique évolue aussi vite, c'est qu'on peut concevoir de nouveaux programmes en assemblant des packages, bibliothèques et modules. Docker for the win \o/

127.0.0.1

J'aimerais tellement que l'on puisse un jour faire mentir cette loi.


Pas certain ce que ce soit forcément une bonne idée.

Dans le cas ou le ralentissement relatif est causé par l'ajout bloatware marketing, ok.
Vivement qu'on arrête l' enshittification

Mais ce ralentissement c'est souvent le prix a payer pour la modularité/abstraction.
Et si l'informatique évolue aussi vite, c'est qu'on peut concevoir de nouveaux programmes en assemblant des packages, bibliothèques et modules. Docker for the win \o/
Docker for what??? Si l'intérêt des conteneurs peut se justifier dans certains cas, quand il s'agit de faire tourner des trucs codés à la va vite plein de dépendances qui auraient pu être évitées et dont la satisfaction avec l'environnement/OS utilisateur tient tellement de l'alignement des planètes qu'il faut coller cela en conteneur pour que ca tourne, niquant au passage une partie de l'intérêt de la mémoire virtuelle pour mutualiser, je n'appelle pas vraiment cela une victoire.

Le concept de conteneur se justifie pour border des trucs offrant une confiance relative ou faire tourner des vieux trucs qu'on ne sait plus maintenir (par exemple car leur source date d'avant la généralisation des outils de gestion de code/versions), mais pour faire tourner de la merde codée quick&dirty moi j'appelle cela violer le concept.

yl

Docker for what??? Si l'intérêt des conteneurs peut se justifier dans certains cas, quand il s'agit de faire tourner des trucs codés à la va vite plein de dépendances qui auraient pu être évitées et dont la satisfaction avec l'environnement/OS utilisateur tient tellement de l'alignement des planètes qu'il faut coller cela en conteneur pour que ca tourne, niquant au passage une partie de l'intérêt de la mémoire virtuelle pour mutualiser, je n'appelle pas vraiment cela une victoire.

Le concept de conteneur se justifie pour border des trucs offrant une confiance relative ou faire tourner des vieux trucs qu'on ne sait plus maintenir (par exemple car leur source date d'avant la généralisation des outils de gestion de code/versions), mais pour faire tourner de la merde codée quick&dirty moi j'appelle cela violer le concept.
Ce qui viole le concept c'est de confondre conteneur (docker), application portable et machine virtuelle.
Non ? :roll:

127.0.0.1

Ce qui viole le concept c'est de confondre conteneur (docker), application portable et machine virtuelle.
Non ? :roll:
Une application portable inclut l'essentiel de ses dépendances (liées statiquement généralement) et une VM c'est pour un OS complet. Docker devient hélas surtout utilisé pour faire de la merde, tout particulièrement de développeurs web tombant dans l'applicatif à la faveur d'un navigateur qui devient de plus en plus une VM avec un OS-bis, lié à leurs habitudes de vite fait mal fait à coups de frameworks divers, vu la durée de vie moyenne d'un site et la pression du ttm. Ce qui tombe en plein dans la loi de Wirth.

127.0.0.1

J'aimerais tellement que l'on puisse un jour faire mentir cette loi.


Pas certain ce que ce soit forcément une bonne idée.

Dans le cas ou le ralentissement relatif est causé par l'ajout bloatware marketing, ok.
Vivement qu'on arrête l' enshittification

Mais ce ralentissement c'est souvent le prix a payer pour la modularité/abstraction.
Et si l'informatique évolue aussi vite, c'est qu'on peut concevoir de nouveaux programmes en assemblant des packages, bibliothèques et modules. Docker for the win \o/
Il y a un monde, à mon avis, entre le passage de codes anciens à du code maintenable et le grossissement inutile actuel avec l'inclusion de bibliothèques entières et les mauvaises pratiques de codage rapide et sale.

Quand il ne sera plus rentable de faire comme cela, les programmeurs auront enfin la possibilité de justifier de passer le temps qu'il faut pour faire bien.

wanou

Il y a un monde, à mon avis, entre le passage de codes anciens à du code maintenable et le grossissement inutile actuel avec l'inclusion de bibliothèques entières et les mauvaises pratiques de codage rapide et sale.

Quand il ne sera plus rentable de faire comme cela, les programmeurs auront enfin la possibilité de justifier de passer le temps qu'il faut pour faire bien.

Je préfère un logiciel qui intègre une bibliothèque de crypto connue et maintenue, plutôt qu'un logiciel avec une fonction de crypto minimaliste codée par 3 gars dans un garage. idem pour un client TCP, ou un serveur web, ou... ou a peu près n'importe quoi en fait.

Il a fallu des années a certaines bibliothèques pour arriver a un haut degré de stabilité et sécurité. Je suis certain qu''un dev seul peut faire un code plus rapide et moins lourd... Mais aussi stable et sécurisé ?

127.0.0.1

Je préfère un logiciel qui intègre une bibliothèque de crypto connue et maintenue, plutôt qu'un logiciel avec une fonction de crypto minimaliste codée par 3 gars dans un garage. idem pour un client TCP, ou un serveur web, ou... ou a peu près n'importe quoi en fait.

Il a fallu des années a certaines bibliothèques pour arriver a un haut degré de stabilité et sécurité. Je suis certain qu''un dev seul peut faire un code plus rapide et moins lourd... Mais aussi stable et sécurisé ?

Ce n'est pas ce que j'avais en tête et je peste moi même contre ceux qui réinventent perpétuellement les choses déjà existantes pour de mauvaises raisons.

Je pense entre autre aux mêmes exemples que toi avec des gens qui se sentent capables de faire mieux qu'apache ou nginx avec un proof of concept pondu par une IA célèbre, pour une api accessible publiquement.

Dans mon précédent post, je faisais référence au code mort lié à l'inclusion de bibliothèques entières au lieu de sélectionner ce qu'il faut, quand cela est possible.
Merci pour cette triste brève et donner ainsi un peu de visibilité à ce grand monsieur pas assez connu... et la Loi de Wirth

Pour comprendre cette loi, il suffit de regarder du code des années 80/90 encore utilisé très largement aujourd'hui car d'une incroyable efficacité. Quelques exemple ? grep, sed, awk...

On doit aussi à Niklaus Wirth le P-code, du code semi-compilé, interprété pour exécution, ce qui permettait d'avoir un compilateur unique et un interpréteur de P-code par plateforme matérielle.

Ce concept sera repris dans... Java !

J'ai beaucoup programmé en Pascal sur Macintosh, un langage clairement pensé pour avoir de bonnes pratiques de programmation (toutes les variables sont typée et déclarées en début de fonction).

Souvenir aussi d'heures passées à lire son livre "Algorithmes et structures de données", qui est encore dans mon bureau !
Oui, un grand monsieur.

Le Pascal a été créé pour être un langage d'enseignement.

J'ai longtemps gardé le listing sur papier de son compilateur Pascal, écrit bien sûr lui-même en Pascal. Il n'a pas survécu à mon dernier déménagement.
Fermer