Ce que tu dis est intéressant.
D'un autre côté, ne peut-on pas considérer que nous sommes à une période de l'industrie informatique où les développeurs sont davantage conscients des nécessités de l'intéropérabilité?
Il fut une époque où tout le monde programmait en assembleur. A cette époque, le terme même "intéropérable" ne devait avoir aucun sens. Puis on a commencé à utiliser des langages plus haut niveau, mais comme de toutes façons, il n'y avait pas encore vraiment d'historique important de la programmation, avec des "bons usages de la programmation", ou tout simplement les principes de librairies, de module, en somme de réutilisabilité du code, ben pas non plus grande intéropérabilité...
De nos jour par contre, les programmes sont de plus en plus complexes, imposants, voire inhumains au niveau code. Les programmeurs savent que pour des programmes commerciaux d'envergure (les jeux en sont particulièrement), ils ne peuvent plus se contenter de bidouiller. Il leur faut des bases solides. Ils veulent pouvoir réutiliser le code d'un projet à l'autre. Ils ne veulent pas avoir à réécrire 100 fois les mêmes lignes de code très bas niveau (et donc peu compréhensible après coup). Ils veulent éviter à tout prix d'être dépendant du matériel (à la limite du système d'exploitation, mais carrêment d'éléments disparates de la machine, c'est un vrai bordel!), et donc de réécrire 10 fois plus de code pour la même chose, en fonction du matos. En d'autres termes: les développeurs veulent des briques de bases intéropérables, et réutilisables, ils veulent donc des librairies, et en particulier qui constituent des normes.
A l'heure actuelle, cette boîte est la seule à faire des PPU (à ce que j'ai compris), mais quand il commencera à y en avoir 2, 3, puis 4... à ce moment les développeurs pourraient commencer sérieusement à hésiter à devoir les prendre en compte (car s'ils en prennent un en compte, la question se pose de savoir lequel, et pourquoi pas tous?), étant donné la surcharge multiplicative de travail que cela risque de créer. Je pense sincèrement que le monde du développement de logiciel a évolué, et est moins bordélique qu'à une certaine époque. J'espère avoir raison, et aussi que ces constructeurs de PPU s'en rendront compte. Ce serait bête de reproduire 2 fois de suite la même erreur pour finalement se retrouver au même point d'intéropérabilité, mais quelques années après (donc retard).
Donc d'après moi, je me dis qu'à l'heure actuelle, ce n'est pas la même chose qu'à l'époque des 3dfx, et autres nombreuses interfaces diverses.
Ensuite je peux me tromper. Peut-être les mêmes erreurs vont se reproduire encore et encore... J'en sais rien, on verra bien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Questions sur la normalisation
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Les PPU !!. Évalué à 2.
D'un autre côté, ne peut-on pas considérer que nous sommes à une période de l'industrie informatique où les développeurs sont davantage conscients des nécessités de l'intéropérabilité?
Il fut une époque où tout le monde programmait en assembleur. A cette époque, le terme même "intéropérable" ne devait avoir aucun sens. Puis on a commencé à utiliser des langages plus haut niveau, mais comme de toutes façons, il n'y avait pas encore vraiment d'historique important de la programmation, avec des "bons usages de la programmation", ou tout simplement les principes de librairies, de module, en somme de réutilisabilité du code, ben pas non plus grande intéropérabilité...
De nos jour par contre, les programmes sont de plus en plus complexes, imposants, voire inhumains au niveau code. Les programmeurs savent que pour des programmes commerciaux d'envergure (les jeux en sont particulièrement), ils ne peuvent plus se contenter de bidouiller. Il leur faut des bases solides. Ils veulent pouvoir réutiliser le code d'un projet à l'autre. Ils ne veulent pas avoir à réécrire 100 fois les mêmes lignes de code très bas niveau (et donc peu compréhensible après coup). Ils veulent éviter à tout prix d'être dépendant du matériel (à la limite du système d'exploitation, mais carrêment d'éléments disparates de la machine, c'est un vrai bordel!), et donc de réécrire 10 fois plus de code pour la même chose, en fonction du matos. En d'autres termes: les développeurs veulent des briques de bases intéropérables, et réutilisables, ils veulent donc des librairies, et en particulier qui constituent des normes.
A l'heure actuelle, cette boîte est la seule à faire des PPU (à ce que j'ai compris), mais quand il commencera à y en avoir 2, 3, puis 4... à ce moment les développeurs pourraient commencer sérieusement à hésiter à devoir les prendre en compte (car s'ils en prennent un en compte, la question se pose de savoir lequel, et pourquoi pas tous?), étant donné la surcharge multiplicative de travail que cela risque de créer. Je pense sincèrement que le monde du développement de logiciel a évolué, et est moins bordélique qu'à une certaine époque. J'espère avoir raison, et aussi que ces constructeurs de PPU s'en rendront compte. Ce serait bête de reproduire 2 fois de suite la même erreur pour finalement se retrouver au même point d'intéropérabilité, mais quelques années après (donc retard).
Donc d'après moi, je me dis qu'à l'heure actuelle, ce n'est pas la même chose qu'à l'époque des 3dfx, et autres nombreuses interfaces diverses.
Ensuite je peux me tromper. Peut-être les mêmes erreurs vont se reproduire encore et encore... J'en sais rien, on verra bien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]