Si tu veux parler d'une séparation frontend/backend, ou client/serveur, ça existe quand même depuis très très longtemps sous une diversité de formes impressionnate. D'une manière générale, je pense que peu de gens contestent l'utilité de séparer les algorithmes du logiciel et l'interface utilisateur.
Après, qu'il faille recompiler la partie UI ou modifier le code pour modifier l'interface, ça dépend un peu du type de logiciel, mais ça ne me semble pas forcément primordial. J'ai du mal à voir ce que ça change en termes de maintenabilité du code, par exemple. Si tu as un code super-complexe qui te génème une interface graphqiue à partir de fichiers XML super complexes, tu vas avoir des bugs de partout, et il est très improbable de motiver les gens à apprendre le "framework". Typiquement, pour un logiciel libre, ça veut dire que tu te coupes de la possibilité de recevoir des patches ; un utilisateur ne va pas passer plusieurs mois à se former sur ton framework pour corriger un bug.
L'isolement technologie a un coût, spécialement pour du logiciel libre. Si tu utilises un binding gtk pour perl, tu as de grandes chances que beaucoup de bricoleurs puissent en un coup d'œil comprendre ce que tu fais. Par ailleurs, être capable de faire tourner ton soft sans passer 3 jours à installer l'environnement de travail peut aussi aider. Au contraire, si le saut technologique est important, cette première étape est rédibitoire. Par exemple, j'ai été faire un tour sur ton github, juste pour cliquer sur quelques fichiers C++ au hasard. Clairement, ton code C++ n'est pas du C++, c'est une sorte de dialecte du C++ qui repose sur des appels de macro dans tous les sens. C'est peut-être justifié, mais ma réaction, c'est "qu'est-ce que c'est que ce bordel, c'est même pas du C++ ce truc". Entre ça et le code généré, j'ai l'impression que comprendre la logique de ton framework nécessite plusieurs semaines de travail. Si en plus tu n'arrives pas à expliquer l'intérêt d'utiliser ce type de technologie, tu vas galérer pour trouver une base d'utilisateurs à mon avis.
Répondre de manière semi-agressive aux commentaires ne risque pas forcément d'aider non plus, d'ailleurs. Tu t'attendais peut-être à ce que les gens te répondent "c'est génial ton truc, comment personne n'y a jamais pensé avant", mais visiblement, s'ils te disent qu'ils n'ont pas compris et que ça ne leur paraissait pas spécialement nouveau ni même intéressant, ça n'est pas dans le but de te blesser. Si tu es dans l'état d'esprit de répondre "vous êtes tous des cons qui n'y connaissez rien", ça ne va pas être très constructif. Il ne faut pas non plus que ça bride ton entousiasme, si tu penses que ton truc vaut le coup, fonce. Mais n'oublie pas "eat your own dog food": Si ta techno permet de développer sans effort des logiciels super facilement, alors le mieux est de fournir ces logiciels toi-même, jusqu'à ce que les gens se demandent "mais comment ce type peut-il maintenir autant de softs de qualité?", ce qui les amènera sur le côté technique. L'approche inverse me semble au contraire très risquée, pusiqu'il est normal pour quelqu'un de sain mentalement de rejeter une nouvelle technologie sans avoir une bonne raison de s'y intéresser.
[^] # Re: Troll
Posté par arnaudus . En réponse au journal 'Epeios organizer' : le commencement. Évalué à 4.
Si tu veux parler d'une séparation frontend/backend, ou client/serveur, ça existe quand même depuis très très longtemps sous une diversité de formes impressionnate. D'une manière générale, je pense que peu de gens contestent l'utilité de séparer les algorithmes du logiciel et l'interface utilisateur.
Après, qu'il faille recompiler la partie UI ou modifier le code pour modifier l'interface, ça dépend un peu du type de logiciel, mais ça ne me semble pas forcément primordial. J'ai du mal à voir ce que ça change en termes de maintenabilité du code, par exemple. Si tu as un code super-complexe qui te génème une interface graphqiue à partir de fichiers XML super complexes, tu vas avoir des bugs de partout, et il est très improbable de motiver les gens à apprendre le "framework". Typiquement, pour un logiciel libre, ça veut dire que tu te coupes de la possibilité de recevoir des patches ; un utilisateur ne va pas passer plusieurs mois à se former sur ton framework pour corriger un bug.
L'isolement technologie a un coût, spécialement pour du logiciel libre. Si tu utilises un binding gtk pour perl, tu as de grandes chances que beaucoup de bricoleurs puissent en un coup d'œil comprendre ce que tu fais. Par ailleurs, être capable de faire tourner ton soft sans passer 3 jours à installer l'environnement de travail peut aussi aider. Au contraire, si le saut technologique est important, cette première étape est rédibitoire. Par exemple, j'ai été faire un tour sur ton github, juste pour cliquer sur quelques fichiers C++ au hasard. Clairement, ton code C++ n'est pas du C++, c'est une sorte de dialecte du C++ qui repose sur des appels de macro dans tous les sens. C'est peut-être justifié, mais ma réaction, c'est "qu'est-ce que c'est que ce bordel, c'est même pas du C++ ce truc". Entre ça et le code généré, j'ai l'impression que comprendre la logique de ton framework nécessite plusieurs semaines de travail. Si en plus tu n'arrives pas à expliquer l'intérêt d'utiliser ce type de technologie, tu vas galérer pour trouver une base d'utilisateurs à mon avis.
Répondre de manière semi-agressive aux commentaires ne risque pas forcément d'aider non plus, d'ailleurs. Tu t'attendais peut-être à ce que les gens te répondent "c'est génial ton truc, comment personne n'y a jamais pensé avant", mais visiblement, s'ils te disent qu'ils n'ont pas compris et que ça ne leur paraissait pas spécialement nouveau ni même intéressant, ça n'est pas dans le but de te blesser. Si tu es dans l'état d'esprit de répondre "vous êtes tous des cons qui n'y connaissez rien", ça ne va pas être très constructif. Il ne faut pas non plus que ça bride ton entousiasme, si tu penses que ton truc vaut le coup, fonce. Mais n'oublie pas "eat your own dog food": Si ta techno permet de développer sans effort des logiciels super facilement, alors le mieux est de fournir ces logiciels toi-même, jusqu'à ce que les gens se demandent "mais comment ce type peut-il maintenir autant de softs de qualité?", ce qui les amènera sur le côté technique. L'approche inverse me semble au contraire très risquée, pusiqu'il est normal pour quelqu'un de sain mentalement de rejeter une nouvelle technologie sans avoir une bonne raison de s'y intéresser.