Problème affichage PHP

[grumff]

Sans préjuger du typage des éléments pointés ni d'une éventuelle dérivation de classe :
- en C, un tableau est un pointeur, et réciproquement. Sans plus.
- en C++, c'est un pointeur, associé à une taille dans le cas d'une initialisation dynamique (avec new[]), qui permet de libérer correctement la mémoire (lors du delete[]).

Euuh, à priori il n'y a pas de différence entre du c et du c++. Un tableau c'est un pointeur sur le premier élément. •|

bayl0ck : je suis très sceptique sur l'intérêt réel de la poo en php. Quand on voit déjà le nombre de procédures statiques dans les applis web en J2EE... La poo en php est en plus assez expérimentales, même en php5.

 

[Bladrak]

bayl0ck : je suis très sceptique sur l'intérêt réel de la poo en php. Quand on voit déjà le nombre de procédures statiques dans les applis web en J2EE... La poo en php est en plus assez expérimentales, même en php5.

Ne serait-ce que pour la clareté du code, la POO est quasi-indispensable en PHP, particulièrement sur des gros projets.
Sur du multi-développement, ça permet une facilitation de la répartition des tâches (c'est plus simple de dire à untel "tu me développes telle classe" plutôt que de lui dire "tu me fais un ensemble de fonctions et les bases associées qui font ça, ça, ça, et ça").

Sur des gros projets, ça permet aussi une meilleure gestion des performances il me semble (je suis pas certain de ce point-là).

Et vraissemblablement la POO sera de plus en plus utilisée à l'avenir, donc autant s'y mettre dès maintenant que de faire du procédural

 

[grumff]

Ne serait-ce que pour la clareté du code, la POO est quasi-indispensable en PHP, particulièrement sur des gros projets.
Sur du multi-développement, ça permet une facilitation de la répartition des tâches (c'est plus simple de dire à untel "tu me développes telle classe" plutôt que de lui dire "tu me fais un ensemble de fonctions et les bases associées qui font ça, ça, ça, et ça").

Sur des gros projets, ça permet aussi une meilleure gestion des performances il me semble (je suis pas certain de ce point-là).

Et vraissemblablement la POO sera de plus en plus utilisée à l'avenir, donc autant s'y mettre dès maintenant que de faire du procédural

Je reste sur ce que j'ai déjà dis là dessus, sur un très gros projet, faire du php c'est une aberration.
Une page web c'est tout ce qu'il y a de plus linéaire. Si on commence à faire des objets, ça veut dire gérer des structures de données, qui sont recréées à chaque chargement de page vu que le php n'est qu'un script exécuté au chargement. Sur le concept c'est très bien, on peut commencer à envisager du MVC et des choses un peu plus propres et maintenables. Mais bref, quand on commence à faire ça en php, les performances s'écroulent, et le langage est super mal fichu pour la poo. Bref, déjà pour les performances, tu rêves.


"Et vraissemblablement la POO sera de plus en plus utilisée à l'avenir, donc autant s'y mettre dès maintenant que de faire du procédural"

Pour la centième fois, les choix de développement se font en fonction des nécessités techniques, pas des effets de mode.

 

[Bladrak]

"Et vraissemblablement la POO sera de plus en plus utilisée à l'avenir, donc autant s'y mettre dès maintenant que de faire du procédural"

Pour la centième fois, les choix de développement se font en fonction des nécessités techniques, pas des effets de mode.

Ouais enfin ça ça dépend des boîtes...

Et la POO a des inconvénients par rapport au procédural ? Lesquels ?

 

[PA5CAL]

Euuh, à priori il n'y a pas de différence entre du c et du c++. Un tableau c'est un pointeur sur le premier élément. •|

Oui, réflexion faite tu as raison, j'ai dit une ânerie. Dans le cas du C++, l'information de taille n'est pas rattachée au pointeur mais à la zone de mémoire réservée.

 

[PA5CAL]

Je reste sur ce que j'ai déjà dis là dessus, sur un très gros projet, faire du php c'est une aberration.
Une page web c'est tout ce qu'il y a de plus linéaire. Si on commence à faire des objets, ça veut dire gérer des structures de données, qui sont recréées à chaque chargement de page vu que le php n'est qu'un script exécuté au chargement. Sur le concept c'est très bien, on peut commencer à envisager du MVC et des choses un peu plus propres et maintenables. Mais bref, quand on commence à faire ça en php, les performances s'écroulent, et le langage est super mal fichu pour la poo. Bref, déjà pour les performances, tu rêves.


"Et vraissemblablement la POO sera de plus en plus utilisée à l'avenir, donc autant s'y mettre dès maintenant que de faire du procédural"

Pour la centième fois, les choix de développement se font en fonction des nécessités techniques, pas des effets de mode.

Tout-à-fait d'accord avec toi.

 

[PA5CAL]

Ouais enfin ça ça dépend des boîtes...

Et la POO a des inconvénients par rapport au procédural ? Lesquels ?

Ça ne doit pas dépendre de la boîte, mais du type de projet.

Et on ne doit pas programmer en fonction de ses outils, mais plutôt choisir ces derniers et ses méthodes de développement en fonction des objectifs à atteindre et des contraintes imposées.

La POO est née de la constatation que, dans la vie d'un logiciel, les structures de données avaient souvent un caractère quasi-immuable, et qu'il était de ce fait plus rentable de fonder le projet sur elles puis de venir y associer des traitements. Comparativement, la programmation procédurale repose prioritairement sur ces traitements, ce qui suppose un remaniement plus important du code si ceux-ci devaient être adaptés pour répondre à une modification des spécifications.

Toutefois:
- le développement objet est plus lourd, et son résultat est moins immédiat lorsqu'il ne s'appuie pas sur une bibliothèque d'objets préexistante et en adéquation avec la problématique à traiter ;
- il est souvent moins bien adapté à la réalisation de produits à courte durée de vie dans lesquels les traitements sont clairement définis au départ ;
- sur les petits projets, faire une nouvelle analyse procédurale et une réécriture complète du code est parfois plus rentable que de réadapter un programme objet existant ;
- la programmation avec des langages OO empêche également parfois de répondre à des exigences de performance et d'optimisation ;
- de plus, il arrive que la définition des structures de données reste incertaine pendant la vie du projet, et que l'accent doivent être mis sur le développement des traitements afin que le travail puisse tout de même avancer.


Bref, la POO et la programmation procédurale ont chacune des avantages et des inconvénients. Seul le contexte peut dire laquelle il convient de choisir.

 

[tatouille]

Tout-à-fait d'accord avec toi.

non je ne suis pas d'accord il ya une incomprehension php est bytecode et mis en mem par la vm sur le meme model que java ou python, j'ai dev de tres grosse OO arch avec php qui question perf est bien plus interressant
que du java/jsp, le language je te l'accorde depuis php5 est un peu dobe copier les voisins, alors que php etait c oriente
c'est debile, fallait implemeter un model objet correspondant a ses afinites comme python par exemple ou ruby

mais n'empeche qu avec php le probleme n est pas le language c'est plutot la masse d incompetents utilisant ce language
et mettent pro-php sur leur CV

<?php

define("kFlagType1", 1 << 0);
define("kFlagType2", 1 << 1);
define("kFlagType3", 1 << 2);
define("kFlagType4", 1 << 3);
define("kFlagType5", 1 << 4);
define("kFlagType6", 1 << 5);

function sendFlags($flags) {
    $type1set = ($flags & kFlagType1) ? 1 : 0;
    $type2set = ($flags & kFlagType2) ? 1 : 0;
    $type3set = ($flags & kFlagType3) ? 1 : 0;
    $type4set = ($flags & kFlagType4) ? 1 : 0;
    $type5set = ($flags & kFlagType5) ? 1 : 0;
    $type6set = ($flags & kFlagType6) ? 1 : 0;
    
    printf("type1set %u \n",$type1set);
    printf("type2set %u \n",$type2set);
    printf("type3set %u \n",$type3set);
    printf("type4set %u \n",$type4set);
    printf("type5set %u \n",$type5set);
    printf("type6set %u \n",$type6set);
    
    return (1);
}

sendFlags(kFlagType1 | kFlagType2 | kFlagType4);
     
echo "\n";
     
sendFlags(kFlagType6 | kFlagType2 | kFlagType3);

echo "\n";

sendFlags(kFlagType5 | kFlagType4);

je suis par aileurs en train d'ecrire une bafouille a propos de ca
car ca fait la enieme fois que je corrige des function du type


sendFlags($arrayOfIntOptions), pour moi 80% des gas qui mettent php sur leur CV sont des tanches

noter que l'exemple est vraie ds n'importe quel language, c est du baba binaire, mais coter dev php ...
je crois que c'est les pire codes que l'on peut voir ecris


Je reste sur ce que j'ai déjà dis là dessus, sur un très gros projet, faire du php c'est une aberration.
Une page web c'est tout ce qu'il y a de plus linéaire. Si on commence à faire des objets, ça veut dire gérer des structures de données, qui sont recréées à chaque chargement de page vu que le php n'est qu'un script exécuté au chargement.

c'est une anerie, et une tres mauvaise connaissance de php et de zend

 

[PA5CAL]

Je reste sur ce que j'ai déjà dis là dessus, sur un très gros projet, faire du php c'est une aberration.
Une page web c'est tout ce qu'il y a de plus linéaire. Si on commence à faire des objets, ça veut dire gérer des structures de données, qui sont recréées à chaque chargement de page vu que le php n'est qu'un script exécuté au chargement.

c'est une anerie, et une tres mauvaise connaissance de php et de zend

Je ne vois pas en quoi c'est une ânerie. On dit en substance que PHP n'est pas l'outil adapté pour faire de gros projets.

Côté interface, on génère une page web et on récupère des informations relativement peu nombreuses. Cette partie ne doit de toute manière pas devenir une usine à gaz.

Côté traitement, si l'on doit pondre des centaines de milliers de lignes avec ce langage de script, dont le contenu varie encore au gré des versions (ce n'est pas encore un véritable standard) et dont un certain nombre de fonctionnalités ne sont accessibles qu'au travers de modules externes (à l'avenir souvent incertain) liés à la plateforme, alors on a forcément du soucis à se faire.

Pour un usage professionnel, l'usage de PHP sur un gros projet serait tout bonnement suicidaire. Ce n'est pas tant un problème de programmation ou d'exécution qu'un problème de gestion des risques liés au développement et à la pérennisation du système.

Pour moi, PHP c'est un peu comme le dBaseIII d'il y a vingt ans. On voit ce qu'il en reste aujourd'hui.

 

[grumff]

non je ne suis pas d'accord il ya une incomprehension php est bytecode et mis en mem par la vm sur le meme model que java ou python, j'ai dev de tres grosse OO arch avec php qui question perf est bien plus interressant

Sauf que dans 90% des cas la compilation (si on peut appeler ça compilation) est faite à la volée. Et contrairement à Java tu n'as pas un programme qui tourne en permanence, mais des pages qui sont rechargées de 0. Ça signifie que si tu as une grosse structure de données qui est utilisée par toutes les pages, au lieu d'être chargée une fois au démarrage du logiciel elle est rechargée à chaque exécution. Sur un gros projet c'est un gâchis de perfs monstrueux. Ça génère aussi une occupation de mémoire gigantesque. Bref, je ne peux pas te laisser dire que le php ou le Python ont les mêmes perfs que du Java dans des gros projets. Sans parler des autres problèmes que le langage occasionne dont Pa5cal a déjà fait un bon résumé.
Le php c'est un excellent langage pour des sites web de petite ou moyenne envergure que l'on souhaite développer rapidement, et on adopte alors les méthodes de développement qui conviennent à ce type de projets. Pour des gros systèmes d'information, il faut y réfléchir à 3x avant de faire ce choix.

 

[tatouille]

http://search.picturetank.com/

faite une recherche (8 tera de photos)

Sauf que dans 90% des cas la compilation (si on peut appeler ça compilation) est faite à la volée. Et contrairement à Java tu n'as pas un programme qui tourne en permanence, mais des pages qui sont rechargées de 0.

et non

Côté traitement, si l'on doit pondre des centaines de milliers de lignes avec ce langage de script, dont le contenu varie encore au gré des versions (ce n'est pas encore un véritable standard) et dont un certain nombre de fonctionnalités ne sont accessibles qu'au travers de modules externes (à l'avenir souvent incertain) liés à la plateforme, alors on a forcément du soucis à se faire.

java est un language de script bytecode, la vm Zend et Java on les meme tares, j 'ai 10 ans d 'exp sur LAMP arch (tres grosse arch tel que 9 telecom, CEA defense... j'en passe ),
je vois pas le probleme, surtout par rapport a Java qui a fait pire coter conformite...


concernant python ca met de loin la fesser en terme de perf a java
c est que tu n'as jamais essaye..

 

[PA5CAL]

[/I]java est un language de script bytecode, la vm Zend et Java on les meme tares, j 'ai 10 ans d 'exp sur LAMP arch (tres grosse arch tel que 9 telecom, CEA defense... j'en passe ),
je vois pas le probleme, surtout par rapport a Java qui a fait pire coter conformite...

De mon point de vue, Java a effectivement les mêmes tares que PHP. Tout cela manque encore de sérieux pour des projets d'ampleur dont l'échec pourrait sérieusement menacer l'invertisseur et/ou le bénéficiaire.


Pour avoir également travaillé dans les télécoms et pour la défense, mais aussi pour d'autres gros établissements, je peux témoigner que rien n'empêche les grosses boîtes qui en ont les moyens de faire d'énormes bourdes en terme d'investissements techniques et de développement, comme cela arrive souvent bizarrement lorsque c'est le grand public qui paie au bout du compte.

Du côté des prestataires de services et développeurs, c'est tout bénéfice lorsque le sujet n'est pas trop compliqué, et ils ne vont pas s'en plaindre. Sur des sujets techniquement pointus (quand ça sort de la bureautique, du réseau, du multimédia ou de la base de données), il arrive que cela débouche sur des impasses techniques (et là les prestataires peuvent tirer leur révérence) ou sur l'implantation d'énormes "verrues" logicielles qu'il faudra par la suite longtemps traîner et payer (mais ça peut redonner du boulot aux prestataires plus tard, et ils y gagnent encore).

Et comme ça ne semble pas gêner ces boîtes de devoir payer deux fois le prix au final (il faut dire que bien souvent, sur la durée, personne ne s'en aperçoit), elles ne sont pas près de s'arrêter.


En revanche, pour les boîtes qui font des investissements en R&D importants (relativement à leurs moyens), et dont la survie dépend de la pérennité des outils qu'elles développent et utilisent, et sur lesquels elles fondent une bonne partie de leur activité (c'est le cas le plus général dans les PME hi-tech), un tel comportement pourrait leur porter un coup fatal.


J'ai bossé dans quelques boîtes qui exploitent, entretiennent et améliorent des outils métier, dont certains datent de plus de vingt ans et dont l'utilisation et parfois la vente de licences génère plus de la moitié de leur chiffre d'affaire. Autant dire qu'elles tremblent à chaque mise-à-jour de l'OS et à chaque changement de matériel. Mais les choix techniques faits au départ étaient bons, et ça continue encore à tenir.

En comparaison, les logiciels qu'elles ont développés en script ou dans des langages propriétaires sont tous allés croupir au fond d'un placard après quelques années d'utilisation, faute de système pour les faire tourner ou de moyen pour les maintenir (c'était plus rentable de les refaire entièrement). Cela a représenté beaucoup de travail et des dépenses en pure perte.

Depuis quelques temps, elles se traînaient justement quelques modules en script, assortis d'inévitables "verrues", que des rigolos avaient tout de même réussi à implanter dans leurs gros logiciels "parce que c'est moderne, que c'est performant et que c'est l'avenir"... La présence de ces scripts et de ces "verrues" a ralenti l'évolution des outils et a posé des problèmes lors de chaque mises-à-jour du système. Leurs efforts ont donc porté (et pour certaines portent encore actuellement) sur l'élimination de ces scripts et de ces "verrues".

 

[p4bl0]

en quoi PHP est moins pérenne que Java ?

Les deux sont libres (complètement depuis récemment il me semble pour Java), et donc pas possible que le développement s'arrête du jour au lendemain.

Y a pas de raisons si ?

 

[PA5CAL]

Je vais répondre pour PHP, mais pas sur la comparaison avec Java.

C'est justement le fait que les développements de PHP ne soient pas arrêtés qui pose un problème de pérennité.

On m'a récemment soumis des problèmes dans l'agglomération de programmes écrits dans différentes versions de PHP. Le fait est que si de nouvelles fonctions sont apparues, d'autres ont en revanche disparu. De plus, les modules externes (obligatoires quand on attaque les choses sérieuses) n'étaient pas présents sur toutes les plateformes, ou bien pas exactement dans les mêmes formes.

Et puis ce n'est pas un « arrêt du jour au lendemain » de l'outil qui est à craindre (personne n'y croit), mais plutôt l'accumulation des délais et des dépenses inutiles pour continuer à faire vivre le logiciel produit.

On ne peut raisonnablement pas baser un projet d'envergure sur l'utilisation d'un outil dont le contenu ou le comportement ne sera pas garanti dans quelques années. Quant à la possibilité de le reprendre entièrement à son compte à partir des sources actuelles (argument souvent avancé en faveur de l'open-source, et qui constitue un atout indéniable dans d'autres circonstances), cela ne présente strictement aucun intérêt, puisqu'il ne s'agit que d'une sur-couche logicielle afin d'implémenter un langage particulier. Dans ces conditions, autant prendre dès le départ un autre langage, véritablement standard et portable (comme le C par exemple).

 

[grumff]

De mon point de vue, Java a effectivement les mêmes tares que PHP. Tout cela manque encore de sérieux pour des projets d'ampleur dont l'échec pourrait sérieusement menacer l'invertisseur et/ou le bénéficiaire.


Pour avoir également travaillé dans les télécoms et pour la défense, mais aussi pour d'autres gros établissements, je peux témoigner que rien n'empêche les grosses boîtes qui en ont les moyens de faire d'énormes bourdes en terme d'investissements techniques et de développement, comme cela arrive souvent bizarrement lorsque c'est le grand public qui paie au bout du compte.

Du côté des prestataires de services et développeurs, c'est tout bénéfice lorsque le sujet n'est pas trop compliqué, et ils ne vont pas s'en plaindre. Sur des sujets techniquement pointus (quand ça sort de la bureautique, du réseau, du multimédia ou de la base de données), il arrive que cela débouche sur des impasses techniques (et là les prestataires peuvent tirer leur révérence) ou sur l'implantation d'énormes "verrues" logicielles qu'il faudra par la suite longtemps traîner et payer (mais ça peut redonner du boulot aux prestataires plus tard, et ils y gagnent encore).

Je ne peux pas te laisser dire ça là, je bosse dans une SSII dans les telecoms justement. On est bien d'accord que tous les choix techniques qui sont fait sont rarement judicieux. Bon déjà la mode là dedans c'est plutôt le tout Java. C'est pas un langage performant, mais là on est clairement dans des contextes où le php ne conviendrait pas, pas à cause des perfs ou des qualités du langage (encore que vu le code de porc qu'on récupère j'imagine pas ce que ça donnerait en php).
Mais bref, du côté des prestataires, on ne cherche pas à encrasser les logiciels pour faire payer plus en suite. Du moins pas chez nous. On n'est pas chez Micro$oft, il n'y a pas de consignes de nos chefs là dessus, les seules consignes c'est de satisfaire le client. Et le client, la seule chose qui l'intéresse, c'est que ce soit pas cher. Et il n'est jamais capable d'avoir une vision à plus d'un an. Il n'y a rien de plus désagréable pour nous que de bosser sur des logiciels mal conçus avec du code encrassé. On passe notre temps à essayer de vendre des évos pour rééecrire les parties qui relèvent de l'aberration technique. Mais on se fait rembarrer à chaque fois. Le nombre de fois où on leur à proposé de réécrire en C/pro*c un traitement qui dure 3H et qui pourrait se faire en moins de 3 minutes, où on leur a proposé de refondre certaines parties de code pour leur dire que ça baisserait de 30% les coups de développement futur, ils ne veulent rien entendre, ça ne rentre pas dans les budgets de l'année... Dans certains cas on peut prendre ces devs à notre charge, pour faire du gain plus tard, mais ça suppose que l'on soit sûr de garder le projet suffisamment longtemps, ce qui n'est presque jamais le cas, mais chaque fois que ça l'est, soit sûr qu'on le fait. Le problème de base c'est que personne n'a une vision à plus d'un an. On veut juste faire au moins cher, aujourd'hui on ne parle plus que de délocalisation pour faire baisser les coûts. Et j'ose pas imaginer ce que ça va coûter dans 10 ans quand ça va revenir et que ce sera devenu complètement immaintenable.

Pour en revenir au débat php/java, peut-être que l'aspect perfs est un mauvais débat. Mais pour en revenir au point de départ, pour faire de la poo, je maintiens toujours qu'on a intérêt à passer au Java. Parce que c'est un langage 100% orienté objet. Parce qu'il impose un certain nombre de contraintes pour le développeur et que ça évite l'encrassage du code. D'autant plus avec l'utilisation de frameworks qui imposent certaines contraintes (struts, jsf, hibernate, springs, ...). Bref on rentre dans des contextes où le php n'apporte plus d'avantages avec sa souplesse, où il faut mieux en venir à du J2EE où les frameworks feront gagner un temps certain.

 

[Bladrak]

Bon, OK, je vais tout développer en AS3 ça sera plus simple

 

[PA5CAL]

Je ne peux pas te laisser dire ça là

Peut-être me suis-je mal exprimé ou mal fait comprendre. Je ne vois pas en quoi ton point de vue, auquel je souscris totalement par ailleurs, entre en contradiction avec ce que j'ai dit.

Je n'ai pas dit que les développeurs faisaient exprès d' « encrasser le code » (j'en ai bien vu quelques-uns le faire, mais ils ne représentent qu'une minorité, et tu n'as pas à te sentir visé). Mais il leur arrive tout de même d' « encrasser le code », généralement en toute bonne fois, soit parce que le client leur a expressément demandé de faire ainsi et/ou que les contraintes (délais, budget) le leur imposent, soit parce qu'ils ne savent pas faire autrement (cas typique des SSII qui forment des débutants sur le terrain). Au bout du compte ça donne du boulot supplémentaire aux SSII, qu'on leur paye et tant mieux pour elles (elles ne l'ont pas volé, c'est le donneur d'ordres qui décide que je sache).

De plus tu évolues, comme tu le dis toi-même, dans un milieu qui n'a pas de vision au-delà d'une année, et qui refuse de ce fait les conseils de bon aloi que tu prodigues. C'est une explication de plus au fait que les grosses boîtes ont l'habitude de faire des bourdes dans leurs choix technologiques. Nous ne sommes pas en contradiction.

Et on en arrive à la même conclusion que le PHP ne convient pas dans les cas évoqués.


Concernant Java, et plus généralement tous les langages "incomplets" ou de "haut niveau", tu conviendras que leur simple choix oblige à se limiter aux librairies disponibles, et à fonder la pérennité du produit sur l'espoir que ces dernières auront un avenir dans les versions suivantes de l'OS et de l'outil de développement et qu'elles seront disponibles sur les plateformes futures sur lesquels le logiciel devra éventuellement être porté.

Dans les domaines d'activité où l'on ne peut pas se contenter des librairies standards (réseau, multimédia, base de données...), on en arrive fatalement à devoir acheter ou développer par d'autres moyens des modules que le langage n'est pas capable de produire, ce qui cause des délais, des surcoûts et des risques techniques supplémentaires pour le développement et/ou la pérennité du produit. Pour de gros projets, le mauvais choix de départ peut se payer très cher.


Alors soit, Java peut être le meilleurs choix possible dans certains cas, et PHP également dans un autre domaine. Mais pour les cas qui correspondent à mon expérience et que j'ai évoqués dans la deuxième partie de mon précédent post, ni l'un ni l'autre ne conviennent.

 

[grumff]

Tu dis quand même que la situation profite au final aux SSII et qu'elles s'en satisfont. Ce n'est pas le cas, là dessus je ne suis pas d'accord. D'abord financièrement parlant c'est pas forcément une bonne affaire, ça fait 1 mois que je debug des problèmes d'écrasement mémoire en C d'un projet récupéré d'une autre boîte peu scrupuleuse, c'était pas prévu dans nos budgets. D'autant que les SSII n'ont pas besoin de ça pour avoir du boulot. On ne se satisfait jamais de bosser sur des architectures pourries ou du code mal écrit. C'est pas vraiment plaisant et rarement rentable parce que ça ajoute de gros facteurs de risque qui ne sont pas évident à chiffrer.
Enfin bref, il y a un point sur lequel on est d'accord, c'est que les entreprises n'ont aujourd'hui que des visions à court terme et que c'est la cause de bien des problèmes dont ils payeront le prix fort dans quelques années.

Je partage pas ton avis sur les langages de haut niveau. Les library java sont au contraire très riches et tout est standardisé et de plus en plus opensource. Ce n'est pas le cas en C. Il y a peu de risques pour la pérénité. Java a déjà fait ses preuves sur la durée. Ce sont des langages de haut niveau qui permettent des développements rapides. Faire du développement web en c ce n'est même pas imaginable. Ils ne sont pas performants par contre, ça c'est clair. Dans certains cas la puissance des machines peut le compenser, dans d'autres cas non.

Enfin, on en revient toujours à une question de contexte. Et on commence à beaucoup s'écarter du sujet initial. Je pense qu'on est quand même globalement du même avis, à quelques détails prêt. L'important est de tomber sur un bon architecte...

 

[PA5CAL]

Mouais... Quand je disais «profiter», je ne parlais pas d'exploiter honteusement une situation, mais de tirer normalement profit d'une activité, comme n'importe quelle entreprise. Il n'y avait rien de péjoratif là-dedans.

Et les SSI se satisfont quand même d'avoir une activité rentable (même quand c'est assez indirectement), sinon elles l'abandonneraient dans le cas contraire. Je ne parle pas des développeurs qu'elles emploient, qui ne tirent pas toujours de satisfaction de cette situation (mais on ne leur demande pas leur avis, hein).


Pour le Java, je maintiens que tout n'est pas réalisable en langage de haut niveau, sinon par l'adjonction de modules supplémentaires qui, eux, présentent des dangers en terme de pérennité. Ce problème n'existe pas en C.

Si je dois par exemple porter une telle application de Windows vers Unix, toute la partie Java sera effectivement transplantée directement love: super !) ... Mais je devrai également re-développer les modules supplémentaires pour lesquels il n'existe pas encore de version Unix, avec un handicap énorme lorsqu'il s'agit de modules propriétaires achetés .

Je parle en connaissance de cause : la situation s'est déjà présentée, et il a été jugé plus rentable de réécrire l'application... en C. Deux années.hommes de travail fichues en l'air. Mais la version re-développée a pu être re-portée sans soucis sur la plateforme d'origine.


Je dois peut-être aussi rappeler que dans les domaines où les codes sources renferment des savoir-faire métier, l'open-source n'est pas de mise, et c'est plutôt le secret industriel qui l'emporte. Les modules les plus importants ne sont donc pas disponibles à volonté.

Et puis les langages de plus haut niveau permettent peut-être de développer plus rapidement (j'admet que dans ce que je fais on développe en moyenne deux fois plus vite en Java qu'en C), mais à «seulement» 50€ de l'heure de développement, ce point de vue ne peut pas être pris en compte quand l'investissement global sur le produit est de plusieurs millions d'euros. On préfère payer des gens à «pisser de la ligne» comme au temps de grand-papa plutôt que de risquer de voir le projet bloqué ou le produit mourir à moyen terme. Quand on dispose d'un outil plein de promesses... on a surtout des promesses.


Bref, c'est un problème de réduction des risques de développement et de pérennité du produit dans son ensemble. Que le code Java soit pérenne tout seul dans son coin, ce n'est pas suffisant.



Bon, on bavarde, on bavarde, mais là je crois qu'on a bien plombé le sujet de UU-YouYou-UU... :rose: