Reprends mon exemple à la fin du commentaire. Tes objections, dans ce contexte, sont respectivement:
1) dire que les modules B5 et B6 peuvent être écrit en C++, c'est du blabla théorique, rien de concret.
2) si tu fais du code en python et en C++, il t'est impossible de recoder les modules B5 en B6 en C++ plutôt qu'en python, puisque dans un premier temps, tu les as codé en python. Cela fait des années que les développeurs de B se focalisent sur les modules B1, B2, B3 et B4, donc, c'est bien la preuve qu'ils ne pourront jamais optimiser les modules B5 et B6.
3) Tu dis "si on remplace les modules B5 et B6 par de modules en C++". Mais tu utilises un "si". Donc, c'est bien la preuve que ce sont juste des hypothèses fumeuses.
(sinon, oui, je crois que s'orienter serveur plutôt que desktop implique une qualité de code différente:
soit on a un gros logiciel serveur, auxquels cas on s'adresse à des clients qui eux-même sont fortement bidouilleurs -> on a intérêt à leur permettre de soumettre leur code. Résultat: peu de développement standardisé (même si niveau vitesse de développement, c'est mieux) -> code de moins bonne qualité (tout en restant de bonne qualité ( code de moins bonne qualité.
Si par contre on s'orientait niveau desktop, on aura plus souvent une entreprise qui fournit sa propre validation de sa propre version, parfois avec très peu de patchs extérieurs acceptés, car là, on s'adresse à un public qui ne fournira pas de retour et on y gagne en cohérence. C'est d'ailleurs en partie ce que fait Canonical.
Donc oui, s'orienter "plutôt serveur" ou "plutôt desktop" a une influence sur la politique de création communautaire du code et donc sur sa qualité.)
[^] # Re: Pourquoi faire ?
Posté par j-c_32 . En réponse au journal Contre la phobie du root. Évalué à 1.
Reprends mon exemple à la fin du commentaire. Tes objections, dans ce contexte, sont respectivement:
1) dire que les modules B5 et B6 peuvent être écrit en C++, c'est du blabla théorique, rien de concret.
2) si tu fais du code en python et en C++, il t'est impossible de recoder les modules B5 en B6 en C++ plutôt qu'en python, puisque dans un premier temps, tu les as codé en python. Cela fait des années que les développeurs de B se focalisent sur les modules B1, B2, B3 et B4, donc, c'est bien la preuve qu'ils ne pourront jamais optimiser les modules B5 et B6.
3) Tu dis "si on remplace les modules B5 et B6 par de modules en C++". Mais tu utilises un "si". Donc, c'est bien la preuve que ce sont juste des hypothèses fumeuses.
(sinon, oui, je crois que s'orienter serveur plutôt que desktop implique une qualité de code différente:
soit on a un gros logiciel serveur, auxquels cas on s'adresse à des clients qui eux-même sont fortement bidouilleurs -> on a intérêt à leur permettre de soumettre leur code. Résultat: peu de développement standardisé (même si niveau vitesse de développement, c'est mieux) -> code de moins bonne qualité (tout en restant de bonne qualité ( code de moins bonne qualité.
Si par contre on s'orientait niveau desktop, on aura plus souvent une entreprise qui fournit sa propre validation de sa propre version, parfois avec très peu de patchs extérieurs acceptés, car là, on s'adresse à un public qui ne fournira pas de retour et on y gagne en cohérence. C'est d'ailleurs en partie ce que fait Canonical.
Donc oui, s'orienter "plutôt serveur" ou "plutôt desktop" a une influence sur la politique de création communautaire du code et donc sur sa qualité.)