Mon expérience me dit qu'il ne faut pas trop te baser sur un langage, la plupart peuvent être utilisés sur la plupart des OS, mais sur des API indépendants de l'OS.
En fait le principal soucis vient de l'interface graphique, et là il y a 2 écoles :
- même code pour toutes les plateformes :
- avantages : 100% portable, diminue le boulot du programmeur
- inconvénients : malgrès ce que evulent faire croirent leurs concepteurs, il est impossible d'avoir à la fois un toolkit graphique portable et puissant qui utilise toutes les possibilités de l'OS cible : bien que visuellement corrects lorsqu'ils utilisent directement les API graphique de l'OS cible, ils leurs manquent soient des fonctionnalités (parcque il fau prendre les facteurs communs), soit émulés (beaucoup moins classs déjà) et surtout ils ne sont pas du tout intégrés à l'environnement (parcque si c'était juste une histoire de skin je verrais vraiment pas l'intérêt d'avoir conçu pleins de toolkit différents, de charte graphique, ou tout simplement d'environnement)
- exemples : Java, Python+Qt, Perl+GTK, etc.
- même code pour l'application, mais pas pour la couche graphique :
- avantages : tu garanties l'intégration visuelle et ergonomique de ton application, ce qui est beaucoup plus "professionnel", notamment pour des applications desktop destinées à monsieur-tout-le-monde.
- inconvénients : il faut bien séparer l'interface graphique du reste de l'application (mais à vrai dire celà ne fera qu'augmenter la qualité de l'architecture de l'appli) et bien sûr il faut réécrire l'interface pour chaque environnement, ce qui est plus long à programmer et à maintenir si l'interface est amenée à changer.
- exemples : N'importe quel langage "portable" + toolkit spécifique pour chaque plateforme Qt/Gtk/WinForms/Cocoa
Mes conseils :
Il est intéressant de noter que tu peux envisager la deuxième solution en utilisant un toolkit "portable" comme Qt ou GTK que l'on retrouve sur de nombreuses plateforme, ce qui te permet d'obtenir une application dans un premier temps 100% portable même si elle n'est pas intégrée. Tu pourras dans un 2nd temps réécrire l'interface spécifique. Utilise au passage un langage "portable" , soit interprété (Python, Perl, Ruby, etc.), soit utilisant un code intermédiaire (Java, C#).
C++ peut être une solution mais tu devras recompiler pour chaque plateforme, le code binaire n'étant pas vraiment portable, surtout lorsque tu changes d'architecture (par exemple sur Mac).
Par contre je vois pas trop l'intérêt de PHP qui a pour objectif d'être utilisé dans le cadre d'une application web. Je ne te conseillerai XUL et tout ce qui va avec seulement si ton application est là encore orientée web, parcque pour le moment les API sont un peu limité si on sort de ce cadre.
Perso j'utilise Mono et une couche graphique différence pour chaque plateforme.
# mon avis
Posté par TImaniac (site web personnel) . En réponse au journal Développement multi-plateformes. Évalué à 7.
En fait le principal soucis vient de l'interface graphique, et là il y a 2 écoles :
- même code pour toutes les plateformes :
- avantages : 100% portable, diminue le boulot du programmeur
- inconvénients : malgrès ce que evulent faire croirent leurs concepteurs, il est impossible d'avoir à la fois un toolkit graphique portable et puissant qui utilise toutes les possibilités de l'OS cible : bien que visuellement corrects lorsqu'ils utilisent directement les API graphique de l'OS cible, ils leurs manquent soient des fonctionnalités (parcque il fau prendre les facteurs communs), soit émulés (beaucoup moins classs déjà) et surtout ils ne sont pas du tout intégrés à l'environnement (parcque si c'était juste une histoire de skin je verrais vraiment pas l'intérêt d'avoir conçu pleins de toolkit différents, de charte graphique, ou tout simplement d'environnement)
- exemples : Java, Python+Qt, Perl+GTK, etc.
- même code pour l'application, mais pas pour la couche graphique :
- avantages : tu garanties l'intégration visuelle et ergonomique de ton application, ce qui est beaucoup plus "professionnel", notamment pour des applications desktop destinées à monsieur-tout-le-monde.
- inconvénients : il faut bien séparer l'interface graphique du reste de l'application (mais à vrai dire celà ne fera qu'augmenter la qualité de l'architecture de l'appli) et bien sûr il faut réécrire l'interface pour chaque environnement, ce qui est plus long à programmer et à maintenir si l'interface est amenée à changer.
- exemples : N'importe quel langage "portable" + toolkit spécifique pour chaque plateforme Qt/Gtk/WinForms/Cocoa
Mes conseils :
Il est intéressant de noter que tu peux envisager la deuxième solution en utilisant un toolkit "portable" comme Qt ou GTK que l'on retrouve sur de nombreuses plateforme, ce qui te permet d'obtenir une application dans un premier temps 100% portable même si elle n'est pas intégrée. Tu pourras dans un 2nd temps réécrire l'interface spécifique. Utilise au passage un langage "portable" , soit interprété (Python, Perl, Ruby, etc.), soit utilisant un code intermédiaire (Java, C#).
C++ peut être une solution mais tu devras recompiler pour chaque plateforme, le code binaire n'étant pas vraiment portable, surtout lorsque tu changes d'architecture (par exemple sur Mac).
Par contre je vois pas trop l'intérêt de PHP qui a pour objectif d'être utilisé dans le cadre d'une application web. Je ne te conseillerai XUL et tout ce qui va avec seulement si ton application est là encore orientée web, parcque pour le moment les API sont un peu limité si on sort de ce cadre.
Perso j'utilise Mono et une couche graphique différence pour chaque plateforme.