Une chose me fera d'ailleurs toujours rire, chez les détracteurs du paradigme objet, et tout particulièrement chez les dev C haineux du C++:
Un programme (ou une librairie d'ailleurs), c'est:
_ des variables internes globales (pas obligatoires, certes)
_ un point d'entrée vers une fonction précise
_ un jeu de fonctions ayant accès aux variables globales
_ une interaction avec l'environnement, que ce soit en utilisant des "fonctions globales" ayant accès au système, ou en utilisant stdin, stdout et stderr
Lors de l'exécution d'un programme, le système commence par:
_ charger le code en mémoire
_ initialiser les variables globales (cette étape est la même que le chargement du code en mémoire dans certains langages, bien que j'imagine qu'il faille de toute façon initialiser les accès vers les 3 flux standards: stdout, stdin, stderr)
_ exécuter le point d'entrée, en lui passant les paramètres de la ligne de commande, qui permettent de manipuler le programme d'une façon précise
_ nettoyage des ressources du programme (parce que sinon, fermer/tuer un programme avec des memory leaks ne viderait pas la mémoire… payes ta galère!)
La remarque intéressante, qui me fait rire, maintenant:
les étapes de l'exécution d'un programme sont exactement les mêmes que pour l'exécution d'un objet: on crée un espace mémoire, on initialise (appel du constructeur) les données, on utilise différents moyens de manipuler l'objet, puis quand on a finit de l'utiliser, on nettoie les ressources qu'il à utilisées (destructeur, ou garbage collector, selon le langage)
Au final, un programme, c'est une classe… sauf que:
_ le système doit initialiser la mémoire à chaque manipulation, puisque la mémoire est vidée entre chaque appel
_ comme la mémoire est vidée entre chaque appel, le concepteur du programme doit permettre une mécanique pour sérialiser/désérializer les données: sauvegarde sur fichier, souvent, qui, comme tout le monde le sait, implique un accès disque, particulièrement lent. Ce point est nécessaire si on veut effectuer plusieurs manipulations différentes permises par un programme sur un même jeu de données.
Du coups, moins de performances.
Autre point négatif, la spécialisation d'un programme en plusieurs déclinaisons est plus complexe a écrire.
D'ailleurs, ce même point me fait également rire chez les fanatiques du tout objet comme JAVA, ou C#, mais en sens inverse:
il est très drôle de constater qu'il faille créer une "classe programme", ayant une méthode statique main, qui ne peut donc pas accéder aux données de l'instance du programme: cette méthode main doit instancier la "classe programme" :D
Si les concepteurs de ce langage avaient été jusqu'au bout de leur délire, le résultat aurait pu être intéressant: considérer qu'un programme c'est l'instanciation d'une classe, puis l'appel à une méthode précise aurait été plus logique, et sûrement plus orienté objet, que d'imposer l'utilisation de méthodes statiques…
Donc, je te rejoins entièrement quand tu dis que le mono paradigme n'est pas parfait.
C'est d'ailleurs la raison qui fait que j'apprécie C++, puisqu'il permet l'utilisation de plusieurs paradigmes à la fois: impératif, objet, générique… pas le fonctionnel, ni la programmation par contrat, ni la programmation logique, malheureusement.
Cela dis, si j'ai bien compris ce que sont les programmations par contrat et fonctionnelle, il intègre quelques outils permettant de s'en rapprocher (via l'utilisation du mot-clé const qui garantit l'immutabilité d'une donnée).
Si un jour un langage implémentait tout ces paradigmes, je pense qu'il serait celui qu'on pourrait le plus considérer comme langage absolu.
Dommage qu'il serait probablement encore plus complexe à maîtriser que C++…
[^] # Re: Vive le fonctionnel
Posté par freem . En réponse à la dépêche Publication de la nouvelle norme Ada 2012. Évalué à 5.
Une chose me fera d'ailleurs toujours rire, chez les détracteurs du paradigme objet, et tout particulièrement chez les dev C haineux du C++:
Un programme (ou une librairie d'ailleurs), c'est:
_ des variables internes globales (pas obligatoires, certes)
_ un point d'entrée vers une fonction précise
_ un jeu de fonctions ayant accès aux variables globales
_ une interaction avec l'environnement, que ce soit en utilisant des "fonctions globales" ayant accès au système, ou en utilisant stdin, stdout et stderr
Lors de l'exécution d'un programme, le système commence par:
_ charger le code en mémoire
_ initialiser les variables globales (cette étape est la même que le chargement du code en mémoire dans certains langages, bien que j'imagine qu'il faille de toute façon initialiser les accès vers les 3 flux standards: stdout, stdin, stderr)
_ exécuter le point d'entrée, en lui passant les paramètres de la ligne de commande, qui permettent de manipuler le programme d'une façon précise
_ nettoyage des ressources du programme (parce que sinon, fermer/tuer un programme avec des memory leaks ne viderait pas la mémoire… payes ta galère!)
La remarque intéressante, qui me fait rire, maintenant:
les étapes de l'exécution d'un programme sont exactement les mêmes que pour l'exécution d'un objet: on crée un espace mémoire, on initialise (appel du constructeur) les données, on utilise différents moyens de manipuler l'objet, puis quand on a finit de l'utiliser, on nettoie les ressources qu'il à utilisées (destructeur, ou garbage collector, selon le langage)
Au final, un programme, c'est une classe… sauf que:
_ le système doit initialiser la mémoire à chaque manipulation, puisque la mémoire est vidée entre chaque appel
_ comme la mémoire est vidée entre chaque appel, le concepteur du programme doit permettre une mécanique pour sérialiser/désérializer les données: sauvegarde sur fichier, souvent, qui, comme tout le monde le sait, implique un accès disque, particulièrement lent. Ce point est nécessaire si on veut effectuer plusieurs manipulations différentes permises par un programme sur un même jeu de données.
Du coups, moins de performances.
Autre point négatif, la spécialisation d'un programme en plusieurs déclinaisons est plus complexe a écrire.
D'ailleurs, ce même point me fait également rire chez les fanatiques du tout objet comme JAVA, ou C#, mais en sens inverse:
il est très drôle de constater qu'il faille créer une "classe programme", ayant une méthode statique main, qui ne peut donc pas accéder aux données de l'instance du programme: cette méthode main doit instancier la "classe programme" :D
Si les concepteurs de ce langage avaient été jusqu'au bout de leur délire, le résultat aurait pu être intéressant: considérer qu'un programme c'est l'instanciation d'une classe, puis l'appel à une méthode précise aurait été plus logique, et sûrement plus orienté objet, que d'imposer l'utilisation de méthodes statiques…
Donc, je te rejoins entièrement quand tu dis que le mono paradigme n'est pas parfait.
C'est d'ailleurs la raison qui fait que j'apprécie C++, puisqu'il permet l'utilisation de plusieurs paradigmes à la fois: impératif, objet, générique… pas le fonctionnel, ni la programmation par contrat, ni la programmation logique, malheureusement.
Cela dis, si j'ai bien compris ce que sont les programmations par contrat et fonctionnelle, il intègre quelques outils permettant de s'en rapprocher (via l'utilisation du mot-clé const qui garantit l'immutabilité d'une donnée).
Si un jour un langage implémentait tout ces paradigmes, je pense qu'il serait celui qu'on pourrait le plus considérer comme langage absolu.
Dommage qu'il serait probablement encore plus complexe à maîtriser que C++…