La normalisationqui est le fait d'établir des normes et standards industriels, c'est-à-dire un référentiel commun et documenté destiné à harmoniser l'activité d'un secteur.. C et Ada sont normalisés auprès de l'ISO. Java à sont propre comité, le JCP. Pour python je ne connais pas suffisamment les détails. Savoir lequel des processus de l'ISO ou du JCP sont le plus ouvert est laissé en exercice aux lecteurs. Dans tout les cas les spécifications existes.
Je ne sais pas pour python, mais pour Java un bug dans l'implémentation de référence est un bug. C'est très simple tu as une spec. À partir de cette spec une suite de test (TCK) est faite, une implémentation est conforme si elle passe la suite de test.
L'implémentation de ces normes par les compilateurs et la disponibilité des bibliothèques standard sur des plateformes moderne. Ce n'est pas par ce que le C89 ou Ada83 sont normalisés à l'ISO que du code de cette époque est toujours compilable. C'est le choix des compilateur de toujours supporter les anciens standards. Gcc pourrait très bien décider de ne plus supporter le C89 un jour. Avoir une norme est un prérequis mais n'est pas suffisante.
Notons que la partie syntaxique/lexicale du langage n'est qu'une toute petit partie de l'iceberg. L'évolution des bibliothèques standard est tout aussi importante. Si des changements non backward compatibles sont fait aux bibliothèques standard ca devient un peu plus compliqué à gérer les anciens standards. Du coup cela peut impliquer de se trimbaler des API merdiques et totalement délirantes pendant 30+ années (qui à parlé de la libc ?).
Et enfin tu as les bugs des implémentations. Ton programme peut tomber en marche à cause d'une zone floue dans la spec ou tout simplement d'un bug présent dans une release donnée du compilateur/libs. En passant sur une autre implémentation, il va exploser en vol. Dans un monde parfait ca ne devrait pas exister, dans le monde réel si. Toutes les implémentations sont buggées et toutes les specs ont des zones floues.
J'aimerai que tu me démontres en quoi Java se préoccupe moins de la pérennité du code legagy que C ou Ada. C'est presque ce qu'on leur reproche...
[^] # Re: Merci pour l'information
Posté par ckyl . En réponse au journal Explorez les richesses du langage Python. Évalué à 3.
La normalisationqui est le fait d'établir des normes et standards industriels, c'est-à-dire un référentiel commun et documenté destiné à harmoniser l'activité d'un secteur.. C et Ada sont normalisés auprès de l'ISO. Java à sont propre comité, le JCP. Pour python je ne connais pas suffisamment les détails. Savoir lequel des processus de l'ISO ou du JCP sont le plus ouvert est laissé en exercice aux lecteurs. Dans tout les cas les spécifications existes.
Je ne sais pas pour python, mais pour Java un bug dans l'implémentation de référence est un bug. C'est très simple tu as une spec. À partir de cette spec une suite de test (TCK) est faite, une implémentation est conforme si elle passe la suite de test.
L'implémentation de ces normes par les compilateurs et la disponibilité des bibliothèques standard sur des plateformes moderne. Ce n'est pas par ce que le C89 ou Ada83 sont normalisés à l'ISO que du code de cette époque est toujours compilable. C'est le choix des compilateur de toujours supporter les anciens standards. Gcc pourrait très bien décider de ne plus supporter le C89 un jour. Avoir une norme est un prérequis mais n'est pas suffisante.
Notons que la partie syntaxique/lexicale du langage n'est qu'une toute petit partie de l'iceberg. L'évolution des bibliothèques standard est tout aussi importante. Si des changements non backward compatibles sont fait aux bibliothèques standard ca devient un peu plus compliqué à gérer les anciens standards. Du coup cela peut impliquer de se trimbaler des API merdiques et totalement délirantes pendant 30+ années (qui à parlé de la libc ?).
Et enfin tu as les bugs des implémentations. Ton programme peut tomber en marche à cause d'une zone floue dans la spec ou tout simplement d'un bug présent dans une release donnée du compilateur/libs. En passant sur une autre implémentation, il va exploser en vol. Dans un monde parfait ca ne devrait pas exister, dans le monde réel si. Toutes les implémentations sont buggées et toutes les specs ont des zones floues.
J'aimerai que tu me démontres en quoi Java se préoccupe moins de la pérennité du code legagy que C ou Ada. C'est presque ce qu'on leur reproche...