Oublie les bindings pour une "grosse" applis, ils sont toujours bloated (documentation inexistante, lents ou buggés, toujours en retard avec la version de la lib, migration impossible ...)
Du coup il te reste deux choix: Java/Swing ou C++/QT-QML. Et la ton choix devrait êtres vite fait suivant tes goûts pour Java ou C++. (oublie SWT: ca ne vaut pas le coup par rapport à Swing)
Moi le C++ ça me saoule un peu (à part pour certains projets critiques ou "bas niveau"): gérer les .h/.cpp, les #ifdef #include, la compilation (-longue-), les versions de dll ... c'est juste un boulot ingrat et inutile (on pourrait garder le même langage et supprimer tout ce bordel).
Et puis quand ton programme pète tu n'a pas une belle stacktrace, il faut implémenter le destructeur, ne pas oublier le mot clef 'virtual' (ils ont vraiment choisi la pire convention ...), la réutilisation de lib est contraignantes (l'une utilise la stl, l'autre QT, d'autres leurs propres implémentation de string voir juste char* ...).
Oui, Java c'est un peu plus lent au démarrage, mais au moins:
* Il existe une librairie pour quasiment tout: des composants graphiques à la génération de PDF.
* Toutes les libs utilisent les mêmes conteneurs, le même type String, unicode par defaut, le même type pour les sockets/l’accès au net, le même type pour l’accès au fichier, pour les regexp, ...
* La compilation et très rapide et faite avec des outils "sains"; Les projets sont facilement modulables.
* Swing ça reste "joli/correct" avec le thème qui va bien (sauf sous Ubuntu ...)
Si tu veut êtres "bleeding edge", tente JavaFx (successeur de Swing), mais du coup tu te prive de l'immense bibliothèque de composants déjà créé en Swing ...
Note: Java c'est quand même bien loupé sur plusieurs choses: Le type "Date" tout pourris, l'absence de "multimedia" (manipulation et lecture de fichiers videos ou de musicaux), pas de type "Tuple<>" super pratique pour le retour de fonction, toujours pas de lambda/closure/... mais bon c'est déja des considération "haut niveau" par rapport à C++.
# Oublie les bindings
Posté par thecat . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 5.
Oublie les bindings pour une "grosse" applis, ils sont toujours bloated (documentation inexistante, lents ou buggés, toujours en retard avec la version de la lib, migration impossible ...)
Du coup il te reste deux choix: Java/Swing ou C++/QT-QML. Et la ton choix devrait êtres vite fait suivant tes goûts pour Java ou C++. (oublie SWT: ca ne vaut pas le coup par rapport à Swing)
Moi le C++ ça me saoule un peu (à part pour certains projets critiques ou "bas niveau"): gérer les .h/.cpp, les #ifdef #include, la compilation (-longue-), les versions de dll ... c'est juste un boulot ingrat et inutile (on pourrait garder le même langage et supprimer tout ce bordel).
Et puis quand ton programme pète tu n'a pas une belle stacktrace, il faut implémenter le destructeur, ne pas oublier le mot clef 'virtual' (ils ont vraiment choisi la pire convention ...), la réutilisation de lib est contraignantes (l'une utilise la stl, l'autre QT, d'autres leurs propres implémentation de string voir juste char* ...).
Oui, Java c'est un peu plus lent au démarrage, mais au moins:
* Il existe une librairie pour quasiment tout: des composants graphiques à la génération de PDF.
* Toutes les libs utilisent les mêmes conteneurs, le même type String, unicode par defaut, le même type pour les sockets/l’accès au net, le même type pour l’accès au fichier, pour les regexp, ...
* La compilation et très rapide et faite avec des outils "sains"; Les projets sont facilement modulables.
* Swing ça reste "joli/correct" avec le thème qui va bien (sauf sous Ubuntu ...)
Si tu veut êtres "bleeding edge", tente JavaFx (successeur de Swing), mais du coup tu te prive de l'immense bibliothèque de composants déjà créé en Swing ...
Note: Java c'est quand même bien loupé sur plusieurs choses: Le type "Date" tout pourris, l'absence de "multimedia" (manipulation et lecture de fichiers videos ou de musicaux), pas de type "Tuple<>" super pratique pour le retour de fonction, toujours pas de lambda/closure/... mais bon c'est déja des considération "haut niveau" par rapport à C++.