• [^] # Légèreté --> langage interprété ? (Python ici)

    Posté par . En réponse au journal De l'inéluctable progrès de l'informatique, ou pas.. Évalué à 8.

    Y'a que moi qui fait un buffer overflow en lisant que tu râles après la performance merdique des softs modernes et que derrière tu estimes que python est un meilleur choix que C++/Qt?
    Faut m'expliquer la…

    Bon, pour le reste, je pense qu'effectivement ton dev à commis une erreur: le framework graphique devrait se limiter aux graphismes. Maintenant, Qt, c'est presque un langage en soi (et devinez pourquoi j'aime pas…)

    Après, ça dépends aussi des spéc que tu demandais. La cible était windows only? Ben, utiliser l'API win32 aurait permis une compatibilité pour les années à venir, et elle est plutôt complète.
    Ah, ça devait être portable? Hum, la, c'est un fait, c'est tout de suite plus dur de trouver quelque chose qui ne bouge pas en fonction des OS sur lesquels ça marche.

    Après, problème dû à un changement de version? As-tu tenté de compiler la version de Qt d'origine? Ben oui, quand on passe des version X.a.b aux versions Y.c.d ça implique traditionnellement que l'on casse l'API publique, c'est bien connu et la plupart des dev suivent cette méthode. A noter que souvent, le 3ème chiffre permet de conserver la compatibilité binaire, chose qui n'arrive que rarement avec le 2nd.

    Et pour le fait de retoucher des trucs qui marchent, je trouve ça normal. Sur une appli que je fais (stade alpha, certes), j'ai un code crado pour le menu, intimement lié aux plug-ins. Ben ça rend la maintenance plus chère, alors je suis en train de réécrire ça (et de tenter de dissimuler mon incompétence de l'époque derrière un flot de commit XD).
    Donc, une telle modification à un rôle (au choix, droit de sélectionner plusieurs résultats): booster la perf, faciliter la maintenance, diminuer le couplage avec d'autres composants…
    Dans le cas de Qt, il semble que la dernière option ait été un objectif majeur de la version 3 à la 4.

    Et je vais finir par la référence au code orienté objet.
    Ca me fait définitivement marrer d'estimer qu'un code orienté objet est plus lourd/lent. Pourquoi? Parce que dans les code C, faits par ceux qui aiment pas les classes, on trouve, entres autres:

    struct FooBar
{
 ...
};
FooBar* createFooBar(...);
void deleteFooBar(FooBar *);
int getFooXPosition(FooBar *);

    Et, je suis navré de vous le dire, mais c'est du code objet, version illisible. A part ne pas utiliser le mot-clé class (et devoir se taper le passage du 1er argument de façon systématique, avec risque de merder sur l'allocation mémoire, bien sûr), il n'y a aucune différence… Enfin, si on adopte un langage dont la mentalité est de pas faire payer pour les trucs qu'on demande pas explicitement (je ne citerai pas de noms pour éviter de déclencher plus de trolls).
    L'objet n'alourdit pas le code, il le rend lisible. Et ce n'est pas lié au langage, mais à la façon de penser du dev. De toute façon, tout finit en assembleur, alors rien n'est objet, pas vrai?