Discussion :

[epsilon68]

J'accorde une grande importance a la portabilité,
a la maison j'utilise C++ / Qt / Boost
au boulot c'est different, nos clients sont sur Windows uniquement donc le plus productif est C#.NET.
Dans quelques cas, servers unix alors c'est du Java.
si c'est une appli web alors c'est fonction du client, Java JSP est employé tres souvent par nos clients.

Voila

[souviron34]

pour moi je dirais portabilité d'abord pour 2 raisons :

• économique
• temps (lié à économique)

Je programme jamais à titre privé. Toujours professionnel. Scientifique, donc depuis longtemps plateformes *nix, mais avant DEC VMS, et HP.

Il m'est arrivé d'avoir en 4 ans de suite à re-programmer 4 fois la même bibliothèque graphique de 5000 lignes, car pas même langage (HP1000, Vax, puis PDP 11 et MicroVax)...

Ca m'a appris

Depuis j'essaye d'être au plus près de la portabilité (fonctions standards).

Langage C.

En graphique j'étais d'abord sous GKS (norme de tracé de segments) , puis sous XWindow/Motif, qui était portable sous toutes les machines existant en scientifiques. Maintenant je dirais que j'irais vers Java, sauf qu'en général les applications sur lesquelles je travaille ont une limite non négligeable de temps de réponse, donc malheureusement pour la partie graphique, vu que X a l'air peu à peu abandonné, j'irais plutôt vers des GUI natifs (VC++, etc..)..

Sur le fond :

La portabilité n'implique absolument pas la lisibilié, ni la propreté du code.
Par contre, pour moi la portabilité est de n'avoir RIEN à modifier dans le code, et uniquement chercher les bons flags de compil. Mais comme l'a dit je ne sais plus qui au dessus, cela permet également de faire ressortir des bugs ou bugs potentiels, les compilos n'ayant pas les mêmes tolérances...

[mchk0123]

Je vais jeter de l'huile sur le feu du débat, mais bon ...

Pour moi la portabilité d'applications n'est qu'une invention marketing initiée par Java pour justifier son existance, un besoin non fondamental et pire une utopie pour les gros projets.

Dans les faits, qui à vraiment besoin d'applications portables ?

Pour les applications développées pour un client, je veux bien croire qu'il désire ardamment que son application soit "portable" (comme son ordinateur soit dit en passant), mais est il si rationnel dans sa décision ? Depuis la naissance des PC (cela date de maintenant de 40 ans), pas vraiment d'évolution côté des micros, pas de disparition massive de dinosaures, donc quelles craintes à avoir sur l'avenir ? Et puis en 50 ans, les programmes viellissent tout simplement.

Pour les gros projets, la question ne se pose même pas puisque de retard en retard dans la date de livraison, il ne reste rarement que trés peu de temps pour se pencher sur la portabilité.

Reste plus que les petites applications personelles, et là la portabilité tiens du gadget.

La seule raison valable de vouloir faire de la portabilitée est de vouloir mettre à la disposition du plus grand nombre une librairie de code qui soit la star dans son domaine. Sinon ça n'a aucun intérêt, on se retrouve vite à vouloir jouer "au clair de la lune" sur tous les instrument de musique du monde tout en se proclamant musicien.

[souviron34]

....
Pour les gros projets, la question ne se pose même pas puisque de retard en retard dans la date de livraison, il ne reste rarement que trés peu de temps pour se pencher sur la portabilité.
.....
La seule raison valable de vouloir faire de la portabilitée est de vouloir mettre à la disposition du plus grand nombre une librairie de code qui soit la star dans son domaine. Sinon ça n'a aucun intérêt, on se retrouve vite à vouloir jouer "au clair de la lune" sur tous les instrument de musique du monde tout en se proclamant musicien.

En gros je suis d'accord avec toi, sauf sur le 1er paragraphe cité.

Au contraire, plus le projet est gros, plus le temps de développement est important, donc plus ça coûte cher. Faire quelque chose de portable est donc économiser du temps, des efforts, et de l'argent.

Donc, dans un gros projet, on devrait baser son développement sur ton dernier paragraphe, c'est à dire que le projet devrait être constitué principalement de bibliothèques.

Tout dépend en fait du but, et du "client" : si le client possède plusieurs types de machines, plusieurs OS, ou envisage d'en avoir, alors la portabilité est essentielle. Si par contre le matériel, les OS, et leurs prévisions, ou la durée de vie du logiciel sont restreints, alors cela l'est beaucoup moins..

Mais par contre je suis entièrement d'accord avec toi (et je ne crois pas que ce soit jeter de l'huile sur le feu) que la "mode" est à la portabilité, pour 250 000 trucs non nécessaires, et même au contraire restreignants (temps de réponse , ressources beaucoup trop gourmandes)..

[mchk0123]

Tu as raison, cela mérite précision sur mon idée :

Ce que je veux dire par là c'est que dés que l'on intégre la portabilité comme un élément du cahier des charges d'un projet informatique, on peut le faire de 2 façons possibles :

1 - portabilité comme un axe prioritaire
2 - portabilité comme une possibilité future intéressante qu'il convient de
ménager

L'attitude 1 amène souvent à une pression opérationnelle supplémentaire, et inutile, sur le projet par un besoin non primoridial et induit bugs supplémentaires, risques sur le planning, tensions dans les équipes, ...

L'attitude 2 consistant à intégrer le portabilitée dans la phase de conception, mais pas celle du développement. Sa mise en oeuvre est retardée en fin de projet quand le coeur de l'application est déjà en place, testé, le stress passé.

En résumé avoir en tête, dés le design et la conception, qu'il faut éviter les impasses connues à la portabilité, mais retarder en fin de projet sa mise en oeuvre opérationnelle.

Ceci étant, mon point de vue peut être biaisé par mon expérience de gros projets mais avec une petite équipe (ou chaque spécification du cahier des charges étaient traitées séquentiellement).
Pour les gros projets avec une équipe nombreuse, (expérience que je n'ai pas), il se peut que l'on détache (en parallèle) quelques ressources dédiées uniquement à la portabilitée.

[siplusplus]

Je me penche plus sur la portabilité entre différents langages.
C'est pourquoi une très bonne analyse permettra de coder dans
n'importe quel langage (idéalement).
Ainsi, quel que soit l'architecture, le langage, la portabilité à
augmenté d'un niveau.

[darksybesis]

Je pense que la portabilité est importante. Vous parlez de portabilité entre plateforme, Mais vous oubliez la portabilité inter plateforme.

Construire un modele de conception qui laisse place a la portabilité du code est probablement la meilleur chose a faire.

De un: le model
De deux:le code pour une plateforme particuliere
De trois: le portage du code vers les autres plateforme

Je pense a Dx10 non fonctionnel sur winxp par exemple. Et au compagnie de jeu qui privilégie le directX a OpengL.

Malgré le fait qu'opengl soit portable sur tout comparativement au jeu dx10 qui pourront pas fonctionner sur un winxp aussi performant.

Donc oui, je pense que la portabilité est hyper importante. La perte de perfomance au niveau de la portabilité est présente simplement si on utilise une virtual machine quoique java est quand meme tres tres rapide. Si on pense au projet Jake2 qui est capable d'atteindre des performance similiaire même supérieur à du natif.

[etranger]

Lors ce que je parle de perte de performance, je ne parle pas forcement que de la vitesse d'execution, par exemple,pour reprendre ton exemple sur Dx10 et oppenGl :

Si je voulais programmer un jeux (ou toute autre logiciel 3D) que pour windows, j'utiliserait Dx10, qui d'apprès se que j'ai peu entendre, permet de faire des choses que opengl ne peu pas faire.

Si je voulais que mon code soit portable j'utiliserait opengl, ce qui pourait m'imposer certainne limites, ou encore onpengl + Dx , ce qui me pousserait égualement à perdre du temps au niveau du developpement, et me forserait à adapter mon code pour utiliser 2 Apis différente.

D'allieure, si la portabilité n'entrainait pas de complication, je ne voit pas pourquoi les éditeurs de jeux/logiciel s'en priverait la plupar du temps.