Si le langage laisse des libertés au compilateur, à l'implémentation, au système d'exploitation, c'est pour de bonnes raisons : c'est au développeur de décider ce qui est important. Certains développements ont besoin de fiabilité, d'autres d'être prédictifs, d'autres rapides, d'autres peu gourmand en ressources, et certains exigent de la précision là où d'autres se contente d'une approximation grossière.
Un bon exemple est la différence entre les nombres décimaux et les nombres à virgule flottante. Tu n'es pas sans savoir que, de base, C++ ne fournit pas de nombres décimaux. Car non, les nombres à virgule flottante ne sont pas des nombres décimaux. Ce sont des nombres binaires composites, qui contiennent un entier et un exposant (éventuellement un signe de positivité). Les calculs sur ces nombres sont approximatifs et ne sont pas fiables. Par exemple, on ne compare jamais un flottant à 0., mais quelque chose dans ce genre :
Dans une application de jeu vidéo en 3D, c'est bienvenue, car les calculs sur les flottant sont rapides. Y substituer des nombre décimaux en créant un type Decimal serait très malvenu. A contrario, dans une application bancaire, où la précision prime sur la rapidité d'exécution, on utilisera évidement des nombres décimaux.
Ensuite, on peut parler du scandaleux comportement de Linux, qui pratique l'overcommit memory. Encore une fois pour de basses considérations sur les performances, le noyau répond au processus qu'il a réservé la mémoire parce qu'il le peut. Mais jusqu'à ce que l'utilisation de la mémoire par l'application ne soit véritablement effectuée, Linux ne lui en réserve pas. Du coup, si dans le temps entre le moment où l'application a réservé de la mémoire, et le moment où elle écrit dedans, Linux n'a plus de mémoire à distribuer, elle tue le processus. Et là, ce n'est même pas une largesse qu'offre à Linux le C, POSIX, ou que sais-je comme autre norme : c'est une optimisation système qui privilégie la rapidité à la fiabilité.
Et nous finirons par évoquer la grande guerre des bases de données. Depuis quelques années, on a vu l'émergence d'une « nouvelle » race de base de données : les noSQL. Il y a dans ces technologies récentes plusieurs éléments qui les distingues des SGBDR dites classiques : elles renient SQL (car parser du SQL, ça prend du temps), elles ne garantissent plus le succès d'une opération et ne communiquent pas sur les échecs (ou de manière étrange, comme dans MongoDB, où on est averti de l'échec de la précédente opération). Là encore, il y a eu des compromissions avec la sécurité des données.
Je pourrais longuement continuer le catalogue des compromis effectués dans toutes ces technologies. J'ai longtemps été très rétif à toutes ces largesses. Mais depuis que j'ai touché à des architectures ou la scalabilité était primordiale, je me suis rendu compte à quel point c'était une posture idéologique en conflit avec la réalité.
C'est pour ça que je défends le choix des concepteurs de C++ de laisser le choix aux développeurs : on ne peut pas tout prévoir, et quand on essaye, on ferme des portes. Avec Java, l'exemple qui m'est le plus criant, c'est la GUI historique : certes, c'est a priori une bonne idée, mais dans les faits, on se coltine des interfaces laides et non-intégrées dans l'environnement graphique de l'hôte. Et surtout, il n'est pas possible de créer des éléments originaux puisqu'on a pas accès à la sous-couche de manière portable.
[^] # Re: Y'a-t-il encore besoin de nouveaux langages "bas niveau"?
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Le langage D. Évalué à 1.
Et pourquoi ne le devrait-il pas ?
Si le langage laisse des libertés au compilateur, à l'implémentation, au système d'exploitation, c'est pour de bonnes raisons : c'est au développeur de décider ce qui est important. Certains développements ont besoin de fiabilité, d'autres d'être prédictifs, d'autres rapides, d'autres peu gourmand en ressources, et certains exigent de la précision là où d'autres se contente d'une approximation grossière.
Un bon exemple est la différence entre les nombres décimaux et les nombres à virgule flottante. Tu n'es pas sans savoir que, de base, C++ ne fournit pas de nombres décimaux. Car non, les nombres à virgule flottante ne sont pas des nombres décimaux. Ce sont des nombres binaires composites, qui contiennent un entier et un exposant (éventuellement un signe de positivité). Les calculs sur ces nombres sont approximatifs et ne sont pas fiables. Par exemple, on ne compare jamais un flottant à 0., mais quelque chose dans ce genre :
Dans une application de jeu vidéo en 3D, c'est bienvenue, car les calculs sur les flottant sont rapides. Y substituer des nombre décimaux en créant un type Decimal serait très malvenu. A contrario, dans une application bancaire, où la précision prime sur la rapidité d'exécution, on utilisera évidement des nombres décimaux.
Ensuite, on peut parler du scandaleux comportement de Linux, qui pratique l'overcommit memory. Encore une fois pour de basses considérations sur les performances, le noyau répond au processus qu'il a réservé la mémoire parce qu'il le peut. Mais jusqu'à ce que l'utilisation de la mémoire par l'application ne soit véritablement effectuée, Linux ne lui en réserve pas. Du coup, si dans le temps entre le moment où l'application a réservé de la mémoire, et le moment où elle écrit dedans, Linux n'a plus de mémoire à distribuer, elle tue le processus. Et là, ce n'est même pas une largesse qu'offre à Linux le C, POSIX, ou que sais-je comme autre norme : c'est une optimisation système qui privilégie la rapidité à la fiabilité.
Et nous finirons par évoquer la grande guerre des bases de données. Depuis quelques années, on a vu l'émergence d'une « nouvelle » race de base de données : les noSQL. Il y a dans ces technologies récentes plusieurs éléments qui les distingues des SGBDR dites classiques : elles renient SQL (car parser du SQL, ça prend du temps), elles ne garantissent plus le succès d'une opération et ne communiquent pas sur les échecs (ou de manière étrange, comme dans MongoDB, où on est averti de l'échec de la précédente opération). Là encore, il y a eu des compromissions avec la sécurité des données.
Je pourrais longuement continuer le catalogue des compromis effectués dans toutes ces technologies. J'ai longtemps été très rétif à toutes ces largesses. Mais depuis que j'ai touché à des architectures ou la scalabilité était primordiale, je me suis rendu compte à quel point c'était une posture idéologique en conflit avec la réalité.
C'est pour ça que je défends le choix des concepteurs de C++ de laisser le choix aux développeurs : on ne peut pas tout prévoir, et quand on essaye, on ferme des portes. Avec Java, l'exemple qui m'est le plus criant, c'est la GUI historique : certes, c'est a priori une bonne idée, mais dans les faits, on se coltine des interfaces laides et non-intégrées dans l'environnement graphique de l'hôte. Et surtout, il n'est pas possible de créer des éléments originaux puisqu'on a pas accès à la sous-couche de manière portable.