Pourquoi n'y a-t-il pas plus d'applications de bureau écrites avec Qt?
Pour autant que je sache et ai compris dans mon expérience avec Qt, c'est une bibliothèque très bonne et facile à apprendre. Il a une API très bien conçue et est multiplateforme, et ce ne sont que deux des nombreuses fonctionnalités qui le rendent attrayant. Je suis intéressé de savoir pourquoi plus de programmeurs n'utilisent pas Qt. Y a-t-il une lacune qui va à l'encontre de cela? Quelle fonctionnalité rend les autres bibliothèques meilleures que Qt? Le problème est-il lié aux licences?
Je n'ai pas vraiment l'intention que ce soit une réponse bashing, mais ce sont les raisons pour lesquelles je n'utilise pas personnellement Qt. Il y a beaucoup de bonnes choses à dire à ce sujet - à savoir que l'API fonctionne la plupart du temps et qu'elle relie les plates-formes de manière transparente. Mais je n'utilise pas Qt, car:
- Dans certains cas, cela ne ressemble tout simplement pas aux programmes natifs. La conception d'une interface utilisateur unique pour toutes les plates-formes ne sera pas intrinsèquement correcte lors du déplacement d'une machine à l'autre, pour diverses raisons de style visuel. Par exemple, sur les machines Mac, les barres de séparation sont généralement relativement épaisses et les boutons sont petits et arrondis avec des icônes. Sur les machines Windows, les barres de séparation sont généralement étroites et les boutons sont plus textuels, avec des conceptions plus carrées. Ce n'est pas parce que vous pouvez écrire une interface utilisateur pour chaque plate-forme que vous devez le faire pour la plupart des applications.
- Qt n'est pas une bibliothèque C++. Cela nécessite une étape de compilation séparée, ce qui rend le processus de construction beaucoup plus compliqué par rapport à la plupart des autres bibliothèques.
- À la suite de (2), les IDE et les outils C++ peuvent marquer les expressions Qt comme des erreurs, car ils ne comprennent pas les spécificités de Qt. Cela force presque l'utilisation de QtCreator ou d'un éditeur textuel comme
vim. - Qt est une grande quantité de source, qui doit être présente et préinstallée sur toute machine que vous utilisez avant de compiler. Cela peut rendre la configuration d'un environnement de construction beaucoup plus fastidieuse.
- Il n'est disponible que sous LGPL, ce qui rend difficile l'utilisation d'un déploiement binaire unique lorsqu'il est nécessaire de publier sous une licence plus restrictive ou moins restrictive.
- Il produit des binaires compilés extrêmement volumineux par rapport à des "applications natives natives" écrites de façon similaire (à l'exception bien sûr des applications écrites pour KDE).
Comme les gens le disent, chaque outil s'adapte à chaque problème et situation ...
Mais si vous êtes programmeur C++, Qt est votre framework. Aucun rival.
Nous développons une application commerciale d'imagerie médicale complexe et Qt tient bon.
Je ne dis pas que les `` inconvénients '' que les gens en disent sont faux, mais j'ai le sentiment qu'ils n'ont pas essayé Qt depuis longtemps (son amélioration continue sur chaque nouvelle version ...) Et, surtout toutes les questions qu'ils commentent ne sont pas un problème si vous faites attention.
Incohérence de la plate-forme d'interface utilisateur: uniquement si vous utilisez les widgets d'interface utilisateur "tels quels", sans personnalisation ni illustration personnalisée.
Surcharge du préprocesseur Qt: uniquement si vous abusez du mécanisme de fente de signal ou de l'héritage QObject, alors qu'il n'y en a pas vraiment besoin.
Soit dit en passant, nous écrivons toujours des applications en C # .NET, et le faisons depuis longtemps. Je pense donc que j'ai une perspective enouchée.
Comme je l'ai dit, chaque outil pour chaque situation,
mais Qt est sans aucun doute un cadre cohérent et utile.
De toutes les choses que je n'aime pas à propos de Qt, le fait qu'il ne fonctionne pas bien avec les modèles me dérange le plus. Vous ne pouvez pas faire ça:
template < typename T >
struct templated_widget : QWidget
{
Q_OBJECT;
public signals:
void something_happened(T);
};
Il ne fonctionne pas non plus correctement avec le préprocesseur. Vous ne pouvez pas faire ça:
#define CREATE_WIDGET(name,type) \
struct name ## _widget : QWidget \
{ \
Q_OBJECT; \
\
public signals: \
void something_happened(type); \
}
Cela, mélangé au fait que tout ce qui répond à un signal doit être un Q_OBJECT, rend Qt difficile à travailler pour un programmeur C++. Les gens avaient l'habitude de Java ou Python probablement probablement mieux en fait).
En fait, j'ai passé beaucoup de temps et d'efforts à rechercher et à concevoir un moyen de récupérer la sécurité de type et de connecter un signal Qt à n'importe quel objet foncteur: http://crazyeddiecpp.blogspot.com/2011/01/quest-for -sane-signaux-dans-qt-step-1.html
Le genre de chose que je veux y faire est un développement C++ de base quotidien rendu pratiquement impossible par le moc Qt ... qui lui-même est totalement inutile de nos jours, s'il l'a jamais été.
Franchement, je suis coincé avec cela parce que si vous voulez faire des tests d'interface utilisateur automatisés, Qt est à peu près le seul jeu en ville à moins de MFC ... qui est tellement 1980 (ça craint de travailler vraiment dur dans cette merde). Certains pourraient dire WX, mais il a des problèmes encore plus graves. GTKmm aurait été mon premier choix, mais comme il est entièrement dessiné par le propriétaire et ne fait pas d'accessibilité ... ne peut pas être piloté par un logiciel de test standard de l'industrie. Qt est assez difficile à cet égard ( fonctionne à peine lorsque vous modifiez le plugin d'accessibilité).
Une raison de ne pas utiliser Qt est que si vous n'écrivez que pour une architecture, telle que Windows, vous voudrez peut-être utiliser C # /. NET (ou Cocoa sur Mac) car ils pourront invariablement tirer parti des dernières cloches et -siffle de l'OS.
Si vous écrivez des applications multiplates-formes, vous pouvez déjà être fortement investi dans une autre technologie telle que Java (c'est-à-dire que vous travaillez dans une "boutique Java"). Votre choix de technologie peut être dicté par l'écosystème dans lequel vous vous développez, comme les API spécifiques au langage. Dans ce type de cas, la réduction du nombre de technologies peut être bénéfique.
Une troisième raison à laquelle je peux penser est que Qt est basé sur C++, et C++ est un langage relativement difficile/dangereux à programmer. Je pense que c'est un langage pour les professionnels. Si vous avez besoin d'avoir des performances optimales et d'être capable d'être méticuleux, alors C++ est probablement toujours le meilleur jeu en ville. En fait, Qt améliore de nombreux problèmes de gestion de la mémoire si vous configurez les choses pour qu'elles tombent hors de portée. En outre, Qt lui-même fait un bon travail en isolant l'utilisateur de nombreux problèmes C++ désagréables. Chaque langage et cadre a ses avantages et ses inconvénients. C'est un problème très, très compliqué qui peut généralement être résumé par l'addition souvent observée dans les convives: vitesse, qualité et prix (mais vous ne pouvez en choisir que deux).
Bien que les règles disent que je devrais continuer de me concentrer sur la réponse à la question, je veux réfuter certaines des questions soulevées par Billy ONeal, qui, je pense, fait un bon travail résumant les raisons couramment citées de ne pas utiliser Qt:
Qt est en effet une bibliothèque C++/framework/fichiers d'en-tête. Il est augmenté par un macro processeur (moc) qui permet les signaux et les slots, entre autres choses. Il transforme des macro-commandes supplémentaires (telles que Q_OBJECT) afin que les classes aient une introspection et toutes sortes d'autres avantages que vous pourriez considérer comme ajoutant une fonctionnalité Objective-C à C++. Si vous en savez assez sur le C++ pour être offensé par ce manque de pureté, c'est-à-dire que vous êtes un pro, alors 1) n'utilisez pas Q_OBJECT et ses semblables ou 2) soyez reconnaissant qu'il le fasse, et programmez autour des cas d'angle très limités où cela pose problème. Pour les gens qui disent "Utilisez Boost pour les signaux et les slots!" alors je répliquerais que vous échangez un "problème" contre un autre. Boost est énorme, et il a ses propres problèmes fréquemment cités, comme une mauvaise documentation, une horrible API et des horreurs multiplateformes (pensez aux vieux compilateurs comme gcc 3.3 et aux gros compilateurs de fer comme AIX).
Pour le support de l'éditeur, cela découle également de 1, je suis un peu d'accord. En fait, Qt Creator est à mon humble avis le meilleur éditeur graphique C++, point final, même si vous n'utilisez pas le truc Qt. De nombreux programmeurs professionnels utilisent emacs et vim. De plus, je pense qu'Eclipse gère la syntaxe supplémentaire. Ainsi, aucun problème avec les macros Qt (Q_OBJECT) ou les ajouts de signaux/slots. Vous ne trouverez probablement pas ces macros dans Visual Studio, car (je concède) ce sont des ajouts à C++. Mais dans l'ensemble, les utilisateurs de C # /. NET n'utiliseront pas Qt de toute façon, car ils ont beaucoup de fonctionnalités couvertes par leurs propres techniques propriétaires.
Quant à la taille de la source Qt, tant qu'elle se compile du jour au lendemain, qui s'en soucie? J'ai compilé Qt 4 sur mon Macbook dual core en "moins d'une nuit". J'espère certainement que ce n'est pas ce qui motive votre décision d'utiliser ou de ne pas utiliser une technologie particulière. Si c'est vraiment un problème, vous pouvez télécharger les SDK précompilés pour Mac, Linux et Windows depuis le site Web de Qt.
La licence est disponible en trois choix: 1) Licence propriétaire au cas où vous souhaiteriez modifier Qt LUI-MÊME et ne pas partager, ou cacher le fait que l'on utilise Qt et pas disposé à donner l'attribution (pourrait être très important pour l'image de marque et l'image!) 2) GPL et 3) LGPL. Oui, il y a des problèmes avec la liaison statique (rouler tout Qt dans le binaire) - mais je pense que c'est plus parce qu'on ne peut pas jeter un œil à l'intérieur et remarquer que vous utilisez Qt (attribution!). J'ai essayé d'acheter une licence propriétaire de Digia, et ils m'ont dit "pour ce que vous faites, vous n'en avez vraiment pas besoin." Sensationnel. D'une entreprise qui vend des licences.
La taille du binaire/bundle est parce que vous devez distribuer le contenu Qt aux personnes qui ne l'ont pas: Windows l'a déjà? les trucs Visual Studio ou vous devez installer le run-time. Mac est déjà livré avec l'énorme Cocoa et peut être lié dynamiquement. Bien que je ne fasse pas beaucoup de distribution, je n'ai jamais trouvé beaucoup de problème avec la distribution du fichier statique ~ 50 mégaoctets (que je peux rendre encore plus petit avec certains des utilitaires de décapage/compression binaires comme UPX). Je ne m'en soucie pas assez pour le faire, mais si la bande passante était un problème, j'ajouterais une étape UPX à mon script de construction.
Qu'est-ce qui définit le "look and feel natif"? Je pense que "la plupart" conviendraient que Mac se rapproche le plus de l'apparence unifiée. Mais ici, je suis assis, regardant Safari, iTunes, Aperture, Final Cut Pro, Pages, etc. et ils ne se ressemblent pas malgré le fait qu'ils soient fabriqués par le fournisseur du système d'exploitation. Je pense que l'aspect "sentir" est plus pertinent: le style des widgets, la réactivité, etc. Si vous vous souciez de la réactivité, alors voici une bonne raison d'utiliser C++ plutôt que Java, ou un autre langage très dynamique. (L'Objectif C bascule aussi, mais j'essaie de dissiper les mythes sur Qt)
En résumé, c'est une question compliquée. Mais je voudrais souligner qu'il y a moins de raisons de "ne pas utiliser Qt" comme on pourrait le penser en se basant sur des mythes et des informations obsolètes.
Certains octroient des licences. Voir https://en.wikipedia.org/wiki/Qt_ (logiciel) #Licensing pour une partie de l'historique des licences. Jusqu'en 2000, les gens qui se préoccupaient beaucoup de l'open source, n'utilisaient pas Qt. Période. (Ce fut, en fait, la motivation originale pour le développement de Gnome.) Jusqu'en 2005, les gens qui voulaient pouvoir publier des logiciels libres pour Windows n'utilisaient pas Qt. Même après cette date, les gens qui voulaient un logiciel libre sous autre chose que la GPL n'avaient tout simplement pas la possibilité d'utiliser Qt. Ainsi, tout projet de logiciel libre plus ancien que ces dates ne pouvait pas utiliser Qt. Et, bien sûr, les personnes écrivant du code propriétaire devaient payer pour le privilège.
De plus, ce n'est pas comme s'il y avait une pénurie d'autres options. Par exemple WxWidgets , GTK + et Tk sont tous des kits d'outils multiplateformes open source.
De plus, pendant longtemps, Windows a été si dominant sur le bureau que beaucoup de logiciels se contentaient de fonctionner uniquement sur Windows. Si vous installez la chaîne d'outils Microsoft, il est plus facile d'utiliser simplement les éléments propriétaires de Microsoft que de se soucier de quoi que ce soit d'autre, et beaucoup de programmeurs l'ont fait.
Je suis d'accord avec presque toutes les raisons évoquées ci-dessus, mais beaucoup de gens ici ont dit qu'ils n'utiliseraient pas Qt en raison des frais supplémentaires qu'il entraîne. Je ne suis pas d'accord avec cela parce que tous les langages les plus courants aujourd'hui (Java, C # et Python) supportent eux-mêmes un peu de surcharge.
Deuxièmement, Qt rend la programmation avec C++ si simple et directe qu'elle compense les ressources supplémentaires qu'elle utilise. J'ai rencontré pas mal d'applications console écrites en Qt plutôt qu'en C++ standard en raison de la facilité avec laquelle elles peuvent être écrites.
Je dirais que la productivité de Qt est supérieure à celle de C/C++ mais inférieure à celle de langages comme Python.
Ce n'est vraiment pas une tentative de déclencher une guerre des flammes, je voulais juste aborder certains points.
La vraie raison pour laquelle Qt n'est pas plus largement utilisé est probablement qu'il s'agit de C++ et que moins de gens utilisent c ++ pour les applications de bureau.
Qt n'est pas une bibliothèque C++. Cela nécessite une étape de compilation séparée, ce qui rend le processus de construction beaucoup plus compliqué par rapport à la plupart des autres bibliothèques.
L'add-vs pour Visual Studio le fait automatiquement, tout comme le processus de création de la ligne de commande de Qt. Le compilateur de ressources utilisé pour créer les boîtes de dialogue pour MFC est également une étape distincte, mais c'est toujours c ++.
Qt est une grande quantité de source, qui doit être présente et préinstallée sur toute machine que vous utilisez avant de compiler. Cela peut rendre la configuration d'un environnement de construction beaucoup plus fastidieuse.
Il existe un téléchargement binaire pour chaque version de Visual Studio et la génération à partir de la source est une seule commande. Je ne pense pas que la taille de la source du SDK soit si importante de nos jours. Visual studio installe désormais toutes les bibliothèques C++ plutôt que de vous laisser choisir, par conséquent la taille d'installation du compilateur est> 1 Go.
Il n'est disponible que sous LGPL, ce qui rend difficile l'utilisation d'un déploiement binaire unique lorsqu'il est nécessaire de publier sous une licence plus restrictive ou moins restrictive.
La LGPL ne s'applique qu'à la lib, elle n'affecte pas votre code. Oui, cela signifie que vous devez expédier des DLL plutôt qu'un seul binaire (sauf si vous payez), mais dans un monde où vous devez télécharger un Java runtime ou une mise à jour .Net pour une petite utilisation de cette ce n'est pas un gros problème. C'est aussi moins un problème sur les plates-formes avec un seul ABI afin que d'autres applications Qt puissent partager les bibliothèques.
Dans certains cas, cela ne ressemble tout simplement pas aux programmes natifs. La conception d'une interface utilisateur unique pour toutes les plates-formes ne sera pas intrinsèquement correcte lors du déplacement d'une machine à l'autre, pour diverses raisons de style visuel.
Il est censé utiliser des widgets et des thèmes natifs. Je dois admettre que je fais principalement des applications techniques afin que mes utilisateurs ne soient pas trop préoccupés par le style. Surtout sur Windows, la nouvelle mode pour que tout se présente comme un widget de smartphone signifie qu'il y a de moins en moins une norme de toute façon.
La raison est simple: il n'a pas de bonnes liaisons avec toutes les langues courantes et il n'est pas comme par magie toujours approprié pour le travail à accomplir.
Utilisez le bon outil pour le travail. Si j'écris une application en ligne de commande simple, pourquoi voudrais-je gonfler cela avec Qt juste pour le plaisir?
En guise de réponse plus générale (que je peux donner parce que je suis pertinent ici), certains programmeurs ne l'auront jamais essayé et ont décidé de l'utiliser. Dans certains cas, il n'y a pas de raison particulière autre que le programmeur n'en ait jamais trouvé le besoin et n'y ait pas réfléchi.
Des cadres tels que Qt sont appropriés lorsque vous êtes plus concerné par l'aspect de votre produit le même sur toutes les plates-formes que par l'aspect de votre produit à droite sur toutes les plates-formes. De plus en plus souvent de nos jours, ces types d'applications se tournent vers les technologies Web.
Je suis d'accord que Qt est un cadre agréable à utiliser. Pourtant, il y a un certain nombre de problèmes avec moi:
- Il est écrit en C++, qui est un langage de très bas niveau. Le seul fait qu'il s'agisse de C++ rendra chaque programmeur Qt beaucoup moins productif par rapport aux Frameworks écrits dans d'autres langages. Mon principal bœuf avec C++ en tant que langage de développement d'interface graphique est qu'il n'a pratiquement aucune notion de gestion automatique de la mémoire, ce qui rend le processus de développement beaucoup plus sujet aux erreurs. Ce n'est pas introspectif, ce qui rend le débogage beaucoup plus difficile. La plupart des autres grandes boîtes à outils GUI ont une certaine notion de gestion automatique de la mémoire et d'introspection.
- Chaque boîte à outils multiplateforme souffre du problème qu'elle ne peut implémenter que le dénominateur le moins commun de toutes les plates-formes prises en charge. Cela, et les différentes directives d'interface utilisateur sur différentes plates-formes remettent en question de manière très intéressante l'opportunité des interfaces graphiques multiplateformes dans leur ensemble.
- Qt est très centré sur le codage de toute votre interface utilisateur. Même si vous pouvez utiliser QtDesigner pour créer certaines parties de votre interface utilisateur, cela fait sérieusement défaut par rapport, par exemple, à l'interface (Cocoa/Obj-C) Builder ou les outils .Net.
- Même si Qt inclut beaucoup de fonctionnalités d'application de bas niveau, il ne peut pas être comparé à un cadre personnalisé pour une certaine plate-forme. Les bibliothèques natives du système d'exploitation pour Windows et OSX sont nettement plus puissantes que les implémentations de Qt. (Pensez aux frameworks audio, à l'accès au système de fichiers de bas niveau, etc.)
Cela dit, j'adore utiliser PyQt pour le prototypage rapide d'applications ou des applications internes. Utiliser Python pour faire tout le codage apaise les soucis avec C++ et fait de Qt un endroit très agréable.
Modifier, en réponse à certains commentaires:
Quand j'ai écrit que Qt était écrit en C++, je ne me plaignais pas tellement de Qt lui-même, mais plutôt de l'environnement dans lequel il vit. Il est vrai que Qt gère très bien ses propres ressources, mais tous vos liens avec l'interface graphique, mais- Le code not-Qt doit également être écrit en C++. Même là, Qt fournit de nombreux outils Nice, mais en fin de compte, vous devez gérer le C++ à ce niveau. Qt rend C++ supportable, mais c'est toujours C++.
En ce qui concerne l'introspection, je veux dire ceci: les cas les plus difficiles à déboguer sont lorsque vous avez un pointeur vers un objet qui ne se comporte pas comme vous le pensez. Avec C++, votre débogueur peut être en mesure de regarder un peu à l'intérieur de cet objet (s'il se trouve qu'il y a des informations de type à ce point), mais même cela ne fonctionne pas toujours. Prenez en revanche le cacao dans la même situation. Dans Cocoa/Obj-C, vous seriez en mesure d'envoyer des messages ("fonctions d'appel") à un objet directement dans le débogueur. Vous pouvez changer l'état des objets, vous pouvez l'interroger pour ses attributs, vous pouvez lui demander son type et ses noms de fonction ... Cela peut rendre le débogage beaucoup plus pratique. Qt/C++ n'a rien de semblable à cela.
à mon avis, l'apprentissage de la programmation C++ est plus simple que de tomber dans d'autres langages qui cachent leur complexité, et le programmeur ne sait pas ce qui se passe réellement en arrière-plan. Qt, d'autre part, ajoute certains avantages par rapport au C++, pour le rendre plus élevé que le C++ natif. Ainsi Qt C++ est un excellent framework pour qui souhaite développer des tâches de bas niveau, ou de haut niveau, de la même manière. Le C++ est (selon certaines pratiques) un langage complexe et simple. Complexe pour qui ne veut pas contester avec elle, simple pour celui qui l'aime. Ne le laissez pas pour sa complexité!
La chose la plus importante mais non mentionnée. Dans un grand projet, une chose cause tant de problèmes et de code non nécessaire. Les mécanismes de créneau de signal de Qt sont inefficaces. Les widgets Qt ne fournissent pas les signaux nécessaires pour les widgets simples d'événement. Par exemple, vous ne pouvez pas définir de signaux pour onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus et etc. Même le widget le plus complexe tel que QTreeWidget fournit un ou deux signaux inutiles ultra simples.
Oui, vous pouvez utiliser des événements MAIS !!! vous avez créé une nouvelle classe pour chaque widget avec un événement personnalisé. C'est une énorme perte d'efficacité;
- Vous avez réécrit chaque événement d'objet widget personnalisé, il y a de petits changements.
- Vous perdez tous les trucs de Qt Designer. Vous devez promouvoir chaque widget avec des événements personnalisés.
- Le projet est devenu plus grand et difficile à maintenir.
- Vous avez commencé à détester qt à cause de cela. Et commencer à parler de la façon dont .net fournit des délégués, de la façon dont il est beaucoup mieux que le slot de signal, de la manière dont les composants .net (widgets) fournissent généralement chaque événement que vous pouvez imaginer. Et etc.
Un de mes collègues a écrit une nouvelle classe de combo box pour chaque widget combo box car il devait utiliser un événement non signal. Histoire vraie...
Cependant, Qt est le meilleur framework d'interface utilisateur C++ jusqu'à présent avec des hauts et des bas.
J'aime vraiment Qt, mais c'est un peu lourd pour beaucoup d'applications. Parfois, vous n'avez tout simplement pas besoin de ce niveau de complexité. Parfois, vous avez juste besoin de quelque chose de simple sans tous les frais généraux de Qt. Toutes les applications n'ont pas besoin d'être pilotées par les événements et C++ fournit un ensemble raisonnable de modèles. Boost fournit un autre très bon ensemble et comprend beaucoup de fonctionnalités de bas niveau (fichier, socket, pointeurs gérés, etc.) que QT fait.
D'autres applications ont des exigences de licence qui ne jouent pas à Nice avec GPL, LGPL ou la licence commerciale de Qt. La GPL est inappropriée pour les logiciels commerciaux. La LGPL est inappropriée pour les logiciels liés statiquement et la licence commerciale coûte de l'argent - quelque chose que beaucoup ne veulent pas payer.
Certains ont des considérations de sécurité ou de stabilité qui n'autorisent pas les bibliothèques complexes comme Qt.
Vous devez exécuter moc pour prétraiter vos sources. Ce n'est pas un gros problème, mais cela peut être intimidant pour le nouvel utilisateur. Beaucoup de programmeurs pensent que vous avez besoin d'utiliser qmake avec Qt, mais c'est un terme impropre. Il est possible de connecter Qt à d'autres systèmes de build assez facilement.
Certaines cibles sont très limitées en mémoire ou en CPU.
Il contient quelques pièges spécifiques à la plate-forme. La plupart de ces pièges sont sans papiers. Construisez une application suffisamment grande et vous les rencontrerez et vous vous demanderez ce qui se passe (avertissement, la dernière fois que j'ai utilisé Qt en colère était il y a plus de 18 mois, donc il se peut qu'il se soit amélioré).
C'est C++ uniquement. D'autres liaisons de langage existent, mais elles ont tendance à masquer ou à exposer mal une grande partie des fonctionnalités pour lesquelles vous souhaiteriez Qt.
Il y a beaucoup de raisons de ne pas utiliser Qt, c'est pourquoi il existe des alternatives. Si tout ce que vous avez est un marteau, chaque problème ressemblera à un clou.
La raison réelle n'est pas technique.
Les gens sont différents. Leurs choix aussi. L'uniformité n'est pas une caractéristique humaine.