Un joli troll de haut niveau a été lancé sur ce journal, pour fêter le vendredi comme il se doit (faut dire que c'est inévitable avec un journal posté le jeudi soir).
Tout d'abord, ne vous en prenez pas à mes connaissances, ce n'est pas "parce que je ne sais rien faire d'autre" que j'ai utilisé Qt. Simplement, je suis le seul codeur, et j'aime le code lisible. Prenez un gestionnaire de paquets pas trop complexe, genre la libalpm (utilisé par Pacman, le gestionnaire de paquets de Arch Linux), et regardez.
Il y a pas mal de code dedans, dont un qui gère le protocole HTTP, un le HTTP, un les différents types de compression, un un système de queue, etc. Au final, quand on veut résoudre un bug sans connaître le code, on prend plus de temps à trouver le fichier et la fonction incriminée qu'à corriger le code.
Qt permet de factoriser le code, et est un avantage technologique. Déjà il permet de ne pas tout recoder (on a la gestion du réseau dedans, la gestion des fichiers de configuration, la gestion du XML, etc). Ensuite, les signaux et les slots peuvent être utiles (par exemple dans la gestion des téléchargements en parallèle, un téléchargement fini déclanchant l'installation de son paquet), et certains modules, comme QtScript, sont un simple bonus.
Logram n'est absolument pas une distribution à vocation serveur. Sur un serveur, installez une Debian, une Red Hat, ou tout autre. Logram, c'est du bureau, du vrais (donc pas un truc comme Ubuntu qui se dit "desktop" parce que ça fait bien, mais qui fournit également une version serveur "parce que ça fait bien aussi").
D'ailleurs, dans le monde du desktop, nous avons Mandriva, qui utilise la suite URPM ... codé en Perl. Ça alors, un langage de script, qui nécessite tout Perl. Même pas une lib, non non, tout un langage. Il faut vraiment leur dire que ça pue, que c'est pas bien, que le C99 juste au dessus de la LibC c'est mieux, non ?
Et bien non. Si l'utilisation d'une bibliothèque de haut niveau permet de sortir un programme de qualité, ou du moins qui a la possibilité de devenir de qualité, on en profite. Rien ne dépend de X, Qt s'installe en quelques secondes, ça occupe 10Mio de disque dur, quelques Mio de RAM, donc c'est rien. Profitons que nous avons un OS correctement conçu qui permet d'installer des bibliothèques sans encrasser une base de registre et ralentir le tout (on est vendredi).
Sinon, je veux bien qu'on fork Setup. Vous allez simplement passer 6 mois à corriger les bugs dans votre implémentation de ce que Qt fournit, comme par exemple les tables de Hash, très utilisées, les listes, les threads, les signaux, la synchronisation, etc.
Ou alors, vous allez utiliser trente six mille bibliothèques, à la manière des applications C générales, pour avoir la même chose. Ce sera plein de dépendances, mais personne ne va s'en plaindre.
# Raison de l'utilisation de Qt
Posté par steckdenis . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 10.
Un joli troll de haut niveau a été lancé sur ce journal, pour fêter le vendredi comme il se doit (faut dire que c'est inévitable avec un journal posté le jeudi soir).
Tout d'abord, ne vous en prenez pas à mes connaissances, ce n'est pas "parce que je ne sais rien faire d'autre" que j'ai utilisé Qt. Simplement, je suis le seul codeur, et j'aime le code lisible. Prenez un gestionnaire de paquets pas trop complexe, genre la libalpm (utilisé par Pacman, le gestionnaire de paquets de Arch Linux), et regardez.
Il y a pas mal de code dedans, dont un qui gère le protocole HTTP, un le HTTP, un les différents types de compression, un un système de queue, etc. Au final, quand on veut résoudre un bug sans connaître le code, on prend plus de temps à trouver le fichier et la fonction incriminée qu'à corriger le code.
Qt permet de factoriser le code, et est un avantage technologique. Déjà il permet de ne pas tout recoder (on a la gestion du réseau dedans, la gestion des fichiers de configuration, la gestion du XML, etc). Ensuite, les signaux et les slots peuvent être utiles (par exemple dans la gestion des téléchargements en parallèle, un téléchargement fini déclanchant l'installation de son paquet), et certains modules, comme QtScript, sont un simple bonus.
Logram n'est absolument pas une distribution à vocation serveur. Sur un serveur, installez une Debian, une Red Hat, ou tout autre. Logram, c'est du bureau, du vrais (donc pas un truc comme Ubuntu qui se dit "desktop" parce que ça fait bien, mais qui fournit également une version serveur "parce que ça fait bien aussi").
D'ailleurs, dans le monde du desktop, nous avons Mandriva, qui utilise la suite URPM ... codé en Perl. Ça alors, un langage de script, qui nécessite tout Perl. Même pas une lib, non non, tout un langage. Il faut vraiment leur dire que ça pue, que c'est pas bien, que le C99 juste au dessus de la LibC c'est mieux, non ?
Et bien non. Si l'utilisation d'une bibliothèque de haut niveau permet de sortir un programme de qualité, ou du moins qui a la possibilité de devenir de qualité, on en profite. Rien ne dépend de X, Qt s'installe en quelques secondes, ça occupe 10Mio de disque dur, quelques Mio de RAM, donc c'est rien. Profitons que nous avons un OS correctement conçu qui permet d'installer des bibliothèques sans encrasser une base de registre et ralentir le tout (on est vendredi).
Sinon, je veux bien qu'on fork Setup. Vous allez simplement passer 6 mois à corriger les bugs dans votre implémentation de ce que Qt fournit, comme par exemple les tables de Hash, très utilisées, les listes, les threads, les signaux, la synchronisation, etc.
Ou alors, vous allez utiliser trente six mille bibliothèques, à la manière des applications C générales, pour avoir la même chose. Ce sera plein de dépendances, mais personne ne va s'en plaindre.
Désolé pour le post un peu long, dure journée.