Maintenant pour l'argument. Un mec qui vient du C, qui se palluche la mémoire, les pointeurs dès le départ parce qu'il n'a pas d'autre choix est largement plus poilu qu'un gentil developpeur Java qui vit dans son monde de bisounours. Il est sensibilisé au système dès le départ. Point.
Qui a dit le contraire ? Un programmeur C est confronté au problème de la mémoire dès la phase de programmation et le dev Java s'en soucie moins pendant cette même phase, c'est une évidence. En revanche, il est clairement obligé de le prendre en compte pendant les phase de tests et d'optimisation (les memory leaks existent aussi en Java). En ça il est sensibilisé au problème et une bonne connaissance de la structure mémoire de la JVM est indispensable.
Autre chose, par exemple, les conteneurs Java ne sont pas tous thread-safe et les programmeurs Java doivent toujours prendre en compte l'aspect multi-thread dans le choix de ces conteneurs. La mémoire joue ici aussi un rôle important puisque certains conteneurs sont très rapides en lecture et écriture mais induisent la création d'index pour accelerer les accès et peuvent donc poser des problèmes lorsque les collections contiennent une grande quantité d'objets. Les OutOfMemoryException ce n'est pas seulement dans les cauchemards.
Bref ce que je te reproche c'est de sortir des lieux communs sur Java sans véritablement prendre en compte le fait que pour bien connaitre et utiliser Java il faut nécessairement comprendre les notions de threads, de mémoire et de processeur.
Les mecs en C sont plus balaises et ont une culture informatique largement plus étendues
Puisqu'apparemment l'expérience personnelle a ici valeur de preuve, je vais moi aussi y aller de mon expérience. Je travaille sur les parties backend d'un gros projet J2EE, en gros MQseries, Moniteur transactionnel CICS, DB2 etc. Je cotoie donc 2 mondes :
- Celui des programmeurs COBOL capables de te dire la différence de réprésentation mémoire entre S9(4) COMP et S9(4). Je fais partie de ces gens-là aussi puisque j'ai écris des programmes COBOL.
- Celui des devs Java pour qui les notions d'encapsulation, d'objet sont importantes. J'en fais aussi partie puisque comme je le disais j'ai écris la partie Java de connexion MQ, d'envoi et de création des messages.
Et bien, il n'y a pas pour moi de grosses différence de culture entre ces 2 mondes. Pour la simple et bonne raison que aucun des devs Java n'a fait que du Java dans sa vie de programmeur. Et bien que j'ai quitté le monde des écoles d'ingénieurs depuis un petit bout de temps, je ne crois pas que les étudiants n'apprennent que du Java durant leurs études.
Je crois moi que tu as une culture "bas niveau" et que donc tu "idolatres" les programmeurs C parce qu'il correspondent à ta conception de l'informatique, c'est un droit mais laisse moi douter de ton objectivité lorsque tu parles des dev Java.
"Ha ouais, super, J2EE et tout. On va prendre ce FrameWork de la mort qui tue et on va leur montrer aux minus d'UNIX comment qu'on fait des applis pour les end-user...". Désolé ça m'énerve.
Le serveur d'application IBM WebSphere fonctionne très bien sous AIX ... je vois vraiment pas où tu as pu entendre ça. D'autant que ça ne veut presque rien dire J2EE c'est plutôt du client/serveur avec des conteneurs et il n'y a pas de notions purement "Unix" équivalente . Java et Unix ne sont pas antinomique. OK Java a mauvaise presse du coté de Linux pour des raisons de licence mais IBM contribue à améliorer Java pour les plateformes Unix.
Finalement si les gens prenaient le temps de connaitre vraiment les technos, on aurait probablement une meilleure collaboration à tous les niveaux, entendre "Haha on va leur expliquer la mémoire à ces tapettes de programmeurs Java ..." c'est énervant aussi.
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par bleh . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 6.
Qui a dit le contraire ? Un programmeur C est confronté au problème de la mémoire dès la phase de programmation et le dev Java s'en soucie moins pendant cette même phase, c'est une évidence. En revanche, il est clairement obligé de le prendre en compte pendant les phase de tests et d'optimisation (les memory leaks existent aussi en Java). En ça il est sensibilisé au problème et une bonne connaissance de la structure mémoire de la JVM est indispensable.
Autre chose, par exemple, les conteneurs Java ne sont pas tous thread-safe et les programmeurs Java doivent toujours prendre en compte l'aspect multi-thread dans le choix de ces conteneurs. La mémoire joue ici aussi un rôle important puisque certains conteneurs sont très rapides en lecture et écriture mais induisent la création d'index pour accelerer les accès et peuvent donc poser des problèmes lorsque les collections contiennent une grande quantité d'objets. Les OutOfMemoryException ce n'est pas seulement dans les cauchemards.
Bref ce que je te reproche c'est de sortir des lieux communs sur Java sans véritablement prendre en compte le fait que pour bien connaitre et utiliser Java il faut nécessairement comprendre les notions de threads, de mémoire et de processeur.
Les mecs en C sont plus balaises et ont une culture informatique largement plus étendues
Puisqu'apparemment l'expérience personnelle a ici valeur de preuve, je vais moi aussi y aller de mon expérience. Je travaille sur les parties backend d'un gros projet J2EE, en gros MQseries, Moniteur transactionnel CICS, DB2 etc. Je cotoie donc 2 mondes :
- Celui des programmeurs COBOL capables de te dire la différence de réprésentation mémoire entre S9(4) COMP et S9(4). Je fais partie de ces gens-là aussi puisque j'ai écris des programmes COBOL.
- Celui des devs Java pour qui les notions d'encapsulation, d'objet sont importantes. J'en fais aussi partie puisque comme je le disais j'ai écris la partie Java de connexion MQ, d'envoi et de création des messages.
Et bien, il n'y a pas pour moi de grosses différence de culture entre ces 2 mondes. Pour la simple et bonne raison que aucun des devs Java n'a fait que du Java dans sa vie de programmeur. Et bien que j'ai quitté le monde des écoles d'ingénieurs depuis un petit bout de temps, je ne crois pas que les étudiants n'apprennent que du Java durant leurs études.
Je crois moi que tu as une culture "bas niveau" et que donc tu "idolatres" les programmeurs C parce qu'il correspondent à ta conception de l'informatique, c'est un droit mais laisse moi douter de ton objectivité lorsque tu parles des dev Java.
"Ha ouais, super, J2EE et tout. On va prendre ce FrameWork de la mort qui tue et on va leur montrer aux minus d'UNIX comment qu'on fait des applis pour les end-user...". Désolé ça m'énerve.
Le serveur d'application IBM WebSphere fonctionne très bien sous AIX ... je vois vraiment pas où tu as pu entendre ça. D'autant que ça ne veut presque rien dire J2EE c'est plutôt du client/serveur avec des conteneurs et il n'y a pas de notions purement "Unix" équivalente . Java et Unix ne sont pas antinomique. OK Java a mauvaise presse du coté de Linux pour des raisons de licence mais IBM contribue à améliorer Java pour les plateformes Unix.
Finalement si les gens prenaient le temps de connaitre vraiment les technos, on aurait probablement une meilleure collaboration à tous les niveaux, entendre "Haha on va leur expliquer la mémoire à ces tapettes de programmeurs Java ..." c'est énervant aussi.