Reprise du message précédent :

 
ok : tu vas donc mes faire un connecteur SAP-Websphere en ASM

dis moi alors ce que c leur droit de regard?
je comprends pas trop ou tu veux en venir, dis moi comment tu choisi un langage pour tel ou tel projet je vois pas.
 
Ton boss va pas te dire tiens prends du java j'ai lu sur ZDNet que ct le pied ce truc lol

Une maitrise d'ouvrage n'acceptera peu ou jamais un developpement dans un langage trucmuche proprietaire a une boite (a l'exception des progiciels... mais la en general y accord avec d'autres boites de prestation pour qu'elles aient un centre de compétences sur ce langager proprio).
 
Pourquoi? la maintenance et l'evolutivité de l'application

tu aimes l'ASM lol
 
Tu as déjà vu un ASM tout nu?

 
Mais carrément, les contraintes liées d'une part à l'existant, d'autre part à l'évolutivité, font que tu as assez rarement le choix des technos - et heureusement, à mon avis, même si c'est parfois contraignant.

 
t'as déjà fait un stage ou bossé dans une boite qui avait un service info conséquent ??
la démarche normalement c : les buts du projet (rapidité, convivialité, utilisateurs spécialisés ou non, durée du projet.....) et en fonction de ça, on choisi le matos en lien avec les outils de développement.

pour ce qui est des boites conséquente oui.
 
Tu confirme ce que je dis, tu as un cahier des charges fournit par tel ou tel direction et donc tu y réponds (choix matos,langage,contraintes associé etc...)

ok mais tu dois expliquer tout ça. et le cahier des charges c svt le service qui le fait.
"dis moi alors ce que c leur droit de regard? " => c eux qui te paye tout simplement. tu dois leur rendre des comptes et leur montrer que les choix que tu as fait sont les meilleurs, et croies moi que certains sont très difficiles à convaincre

 
nan mais je sais qu'un truc code en asm c imbouffable

Les lgges propriétaires c le mal

 
Attends le cahier des charges est fait par le service demandeur toi tu y réponds, c tout.
 
En ce qui concerne le droit de regard, dans les sociétés qui possèdent une DSI, c elle qui à ce fameux droit de regard et donc en général c pas trop dur de justifié tes choix car c un peu leur boulot lol

bah si c une refonte du système info, le cahier est établi par le service info pour le service info !!
mais le dirigeant du service n'est pas forcément informaticien, hé oui, va voir dans un hopital, c'est un médecin qui a des compétances informatiques. tu lui explique à lui et après il se débrouille avec les grands chefs pour débloquer des fonds. donc c pas si facile de se justifier qd tu as qq1 en face de toi qui est moins calé.

Déjà la refonte de tout un sytème je crois pas que tout les informaticiens fassent ça tout les 4 matins    
 

 
Oui bah normalement c toi l'expert et il te fais confiance, sinon je vois pas à quoi on servirait.

non mais c souvent des projets sur plusieurs années et qui débloque des sommes d'argent colossales.
et même si c toi l'expert, si de ton avis dépend un investissement énorme, on va pas te filer un chèque de plusieur millions d'euros en te disant : vas y mon pti gars, fait cke tu veux avec, dans trois ans on veut que ça marche

Oui je la-dessus je suis bien d'accord.
C pour ça que souvent tu dois convaincre ta DSI et après c eux qui confirme à la direction général que ta solution et la bonne.
 
Bah en fait on étét d'accord

ouaip ! moi j'avais halluciné le prix des trucs pendant mon stage, genre le prix d'un serveur, le prix des formations internes à faire.... j'ai compri du coup pourquoi les banques gardaient tout en cobol : elles ont pas les fonds pour refaire tout leur système de toutes leurs agance en même temps, ça coute moins cher de faire de la maintenance sur un vieux truc.

kler surtout si le sytème marche bien.
CT le même principe à La Poste.

 
 
mais vraiment là je me tient plus !
 
C++ >>> Java en vitesse de 10 à 100 fois plus rapide. Bon par contre évidament quand on utilise les bibliothéques ultra optimisées C++/ASM de JAVA c normal que ca carbure
 
 

 
Sur du code fait en java (pas utilisant la marchine vituelle pour les bibliothéques), java va environ 10 fois moins vite (testé moi meme et vérifié sur pas mal de sites)
 
 
Java utilise aussi de 5 à 20 fois plus de memoire pour arriver à la meme chose ce qui est pas top. Les seuls truc qui m'ont sorti Out of memory c des programme Java. En plus la moindre application JAVA mais du temps à se charger....
Pourtant j'ai un 3000+ A64, 1Go de RAM (2Go de memoire virtuelle), un R9800 Pro... donc je crois pas avoir un PC trop merdique non plus. Pourtant les programme JAVA (pas ceux que j'ai fait mais des programmes que j'utilise pour programmer en JAVA par exemple) rament beaucoup. Plus que des EDI aussi complexe d'il y à 4-5 ans sur des machines 10 fois moins puissantes.
 
 
Je trouve que JAVA est bien pour le fait que c connus, beaucoup utilisé, bibliothéques fournies, pour la programmation WEB et le ramasse mietes. Par contre le code est aussi peu lisible qu'en C/C++, beaucoup plus gourmand en mémoire, beaucoup plus lent. J'aime pas vraiment JAVA vous l'aurez compris. Pourtant je me suis payé pas mal de projet avec.
 
Sinon dans bien des cas on choisis pas le langage, on utilise ce qui correspond logiquement a ce qu'on veut faire et qui est compatible avec l'existant et sincére le mieux avec.
 
 
Pour ceux qui demandent je dirais C/C++, JAVA à connaitre. Avoir au moins vu un langage type prolog,un type CAML, un assembleur. Avoir vu comment le compilateur fonctionne aide bien à comprendre les rouages et le fonctionnement interne du programme pour debugger c cool. Le lambda calcul est assez interessant aussi meme si complement inutile en pratique. Connaitre 2/3 langage script est assez bien vu aussi (Perl, python...).
Aprés peu etre que si dans une anonce un langage tordu est annoncé s'entrainer avant d'y aller, pour connaitre le langage puis y aller en disais qu'on connais qu'on a programmé des truc dans son temps libre dessu peu le faire.

Haskel

Plantouillé quand voulu modifier un truc ... dsl

t'es pas oblige de les poster en double tes messages...

+365

c'est bon on la voit ma connerie maintenant

z'êtes a fond sur la vitesse d'execution...mais ça ne représente pas entierement un langage !
 
Le coût de développement, la maintenabilité, etc est aussi un facteur important !  
 
Je pense qu'une entreprise peut choisir un (des) langage(s) autrement que pour sa (leurs) rapidité(s) !
 
Donc pour revenir au sujet :  
Quels langages indispensables dans une formation informatique : aucun, car c'est plus interessant de savoir comment programmer dans l'optique d'un langage (ce que je veux dire : il faut savoir faire du procedure, & de l'objet..)
 
Après, que ce soit Java, ou C++, ça change rien ! Pour faire une gestion de porte feuille qui sert a rien, c'est pas important. (dans le cadre de la formation)
 
Sur le marché du travail, ça ne doit pas faire de mal de connaître Java et C++, et de connaître leurs points forts & faibles pour savoir lequel est adapté au projet.  
 
(mais tout ça a déjà été dis je crois)
 
- moi je dis ça...vous en faites ce que vous voulez après -

J'ai fait du Eiffel en fac

Eiffel est un très bon langage
Langage à objet super secure, avec un bon compilo gnu http://smarteiffel.loria.fr
GOGO EIFFEL !

moi g fais du basic sur mon CPC6128  
 

Ce sujet me fait penser aux offres d'emploi actuelles dans l'informatique, ils sont sans cesse à demander comme pré requis de maitriser tous les langages "à la mode" ainsi que d'avoir une expérience similaire dans un emploi précédent et le poste en question faisant appel à des systèmes dont tu n'as jamais soupçonné l'existence.

Tu ne pourra jamais connaitre tous les langages.
Par contre tu pourra quasiment maitriser tous les concepts (ou au moins les plus importants).
Tu pourra ensuite appliquer ces concepts dans la pluspart des languages. Il faut dépasser le stade de la syntaxe et de la mise en place. Une infrastructure ne doit pas te limiter.
 
Si tu veux te mettre à un langage réfléchi à celui qui pourra produire la plus importante valeur ajoutée pour ton CV sur du moyen terme et ton salaire suivra.

 
Ca m'etonnerait que le C++ soit tres adapté à de l'informatique de gestion

 
En rien.  
Et pour preuve, une petite recherche avec le mot clef "java" m'apporte 250 réponses sur Yahoo Emploi, contre 41 pour "delphi"
 
Il serait temps que certains comprennent que pour un langage il n'y a pas que la puissance qui compte... si tel était le cas on coderait tous directement en assembleur et personne ne s'enmerderait à créer des nouveaux langages
 
A chaque langage convient une utilisation..

Il suffit de faire du prolog pour ce rendre compte de ce que signifie lenteur.
Pourtant ce qu'on peut faire avec prolog en 5 lignes il faudrait des dizaines de lignes pour le faire dans un autre langage.

Va falloir que je t'explique deux-trois choses sur le sujet ...

Bien plus que pas mal de choses ...

Bien ske je pensais ... aucune expérience réelle en Java ...
Et ça se permet de critiquer ...

Concernant les sockets, je te donnerai des cours ... toutes mes applis serveurs Java basées sur des sockets fonctionnent sans aucune recompil sur Sparc/Solaris, Wintel, et Linux ... et sans modif de comportement ...
 
Concernant les perfs, avec "un peu d'investissement personnel", on arrive à des trucs très sympas ... pis bon côté serveur, HotSpot se débrouille plutot bien ... Ta remarque concernant Java et le bytecode n'est plus tout à fait vraie avec Hotspot ...    
 
En bref, tes "connaissances" sur Java sont comme tu disais : Très "jolies" dans la théorie, mais à chier dans la pratique ...

 
Hey, tu connais le JIT? Si tu cherches les performances tu compiles ton appli java en code natif (ASM de la machine cible). Les performances sont bien plus importantes puisque ca ne passe plus par un interpréteur jvm standard. Vas sur google et met "java just in time" en mots clé tu vas en apprendre des choses.
 
Maintenant on y perd l'intérêt de la portabilité...
 

 
Si tu veux jouer au test, j'ai fait une comparaison en terme de rapidité C++ - Java sur un serveur Sun 12-processeurs sous environnement unix. C'est ballot, Java battait C++...
 
Concernant la consommation de mémoire, c'est vrai que c'est un problème... mais pour une architecture n tiers a client léger, tu t'en tapes cordialement.  
 

 
Le code C++ est carrément moins lisible si tu ajoutes les surcharges d'opérateurs, les héritages multiples, les bibliothèques standards, les classes amies et j'en passe des meilleurs...
Un code C++ est carrément plus difficile à maintenir (en rajoutant les fuites de mémoires, pointage sur une adresse non utilisée).  
 
Java est un langage plus haut niveau que C++. En conséquence, il y a des plus et des moins : plus gourmand en mémoire car l'absence des pointeures (en fait il est possible de les déclarer et de courtcircuiter le GC mais personne le fait), mais plus maintenable, plus exploitable, le developpement se fait plus rapidement.

 
Le coût de maintenance sont les plus élevés du cycle logiciel, donc si tu développes en ASM la quantité de travail sera plus importante qu'en Java, donc plus de temps => plus de coûts, et ça l'entreprise ne s'en fout pas.

 
Pour la vitesse oui on peut compiler. Pourtant les fonction Inline, le code assembleur intégré, la possibilité d'utiliser des instructions optimisées pour chaque processeur font que :
 
Le C++ permet sans probléme d'avoir un bon niveau d'abstraction en utilisant les methodes sans se restreindre (les appels si long des methodes justement sont inexistant avec les appels direct inline vu qu'il n'y à plus d'appel de fonction).
 
 
La lisibilité :
Je suis d'accord que le C++ n'est pas forcément lisible mais :
 
Le fait que dés qu'on déclare une variable on écris 2 fois plus de code:
JAVA : ObjetCoco Obj = new ObjetCoco (params);
C++  : ObjetCoco Obj(params);
 
Le fait qu'en Java les exception doivent etre Toujour encadré ce qui au point de vue concept est stupide. Souvant c quelque chose que l'on désire eviter, et laisser se propager l'exeption serais bien plus futé (à cette couche... on ne sait pas gérer cette exception par exemple). C faisable bien sur de relancer l'execption mais le code deviens bien moins lisible.
 
Justement la surcharge des opérateur !!!.  
Pour multiplier 2 matrices en C++ et l'affecter à une troisiéme j'écris :
Matrix A,B,C;
[...]
A = B*C;
 
En java j'écris un truc du genre :
Matrix A,B = new Matrix(),C = new Matrix();
[...]
A = Matrix.matrixMultiply(B,C);  
 
En admetant bien sur que ce soit la methode adoptée pour multiplier.
 
on peut penser aussi ecrire :
Matrix A,B = new Matrix(),C = new Matrix();
[...]
A = new Matrix(B);
A.matrixMultiply(C);
 
Dans tout les cas d'un coté en JAVA on à un code lourd ILLISBLE comparé a celui du C++. Bien sur en JAVA on voit mieux la réelle opération effectuée je suis daccord. Par contre c bien plus long à écrire et dés qu'on a une vrai opération un peu complexe ou un code un peu long en JAVA ca devient un calvaire a comprendre (ca peut requerir 20 ligne bien longue en JAVA, pour 1/2 ligne en C++) du coup je dirais pas que JAVA gagne coté lisibilité.
 
Comme deja dit avec les fonction inline aussi bien le code de multiplication de matrix se fait sans pile voire meme en code optimisé pour chaque type de processeur. Diminuant drastiquement les temps de calcul tout en étant plus lisible.
 
 
En java l'heritage multiple est impossible on utilise soit des interface (existe aussi en C++) soit des moyen détournés (existe aussi en C++ bien sur). En C++ (ou en python) c permis. Si l'heritage multiple est parfois délicat (pas de probléme si on a une bonne conception dériere et de bon diagrammes pour illustrer ca) les avantages sont importants : bien moins de code à écrire, bien moins de copié collé débile ou une architechture de classe plus simple, donc plus facile a comprendre et maintenir. Et je dirais meme bien souvant les 2 !!!. En java on se retrouve souvant avec 50 classes contenant toujours le meme code copié collé bêtement. En C++ le plus souvant on peut eviter ca.
 
Et quand il sagit de faire une Enumération en java, ou des type entier restreint (cas d'école classique) Alors la je suis mort de rire. Là ou en C++ et beaucoup de langage c 1 ligne, En JAVA il en faut 30 ou 50.
 
Bien souvant l'objet est plus handicant qu'autre chose. En C++ on peut l'éviter. En java NON. (enfin de toute façon la facon de gérer les opérateur en JAVA est plus fonctionnelle que objet vu qu'on doit utiliser des fonction plutot que les redéfinir et choisir le bon par polymorphisme).
 
 
Je pense donc dire JAVA>C++ c un peu rapide. Je viens de montrer qu'a mon sens JAVA a besoin de murir, de proposer plus de choses pour etre aussi puissant que C++. C++ est clairement un langage de plus haut niveau (hormis la gestion de la mêmoire) car il permet d'ecrire les chose de façon plus consise et plus abstraite avec des notion que JAVA n'as pas. Par contre java à l'avantage d'une bibliothéque standard trés fournie et la portabilité ce qui fait croire qu'il est de plus haut niveau si on reflechis pas plus loin mais au point de vue notion et programmation objet/fonctionnelle java est bien moins puissant que le C++. (enfin bon C++ c portable quand JAVA est compilé, C++ est à égalité, et toutes les plate formes ont un compilateur C++ ou presque) cela en fait un bon langage pour le web.  

Un débat sur les différents langages est complètement hors-sujet ...