A-t-on besoin d'apprendre la programmation pendant 10 ans avant d'être un développeur accompli ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

15/05/2018, 15h02
Michael Guilloux

A-t-on besoin d'apprendre la programmation pendant 10 ans avant d'être un développeur accompli ?
A-t-on besoin d'apprendre la programmation pendant 10 ans avant d'être un développeur accompli ?
Partagez votre expérience

Le développement informatique fait sans doute partie des métiers les plus convoités aujourd'hui, surtout que de certains avis, il y a une forte demande sur le marché qui ne peut être absorbée par l'offre actuelle de développeurs. Initialement réservé à des formations en informatique de 4 ou 5 ans en général, le marché de l'emploi voit donc de plus en plus l'arrivée de candidats issus de formations intensives de courte durée.

Mais pour Peter Norvig, directeur de recherche chez Google, la programmation est quelque chose qu'on devrait normalement apprendre sur une période assez longue, 10 ans par exemple. C'est ce qu'il expliquait d'ailleurs dans un billet publié il y a quelques années et intitulé « Teach Yourself Programming in Ten Years ». Dans ce billet, il critiquait notamment les bouquins avec des titres comme « Apprendre X en Y heures/jours », par exemple « Teach Yourself C++ in 24 Hours ». Il disait avoir fait une recherche avancée sur Amazon pour répertorier les livres avec des titres de ce genre qui ont été publiés depuis l'année 2000. Et il en avait trouvé 512. Le point remarquable est que 9 des 10 premiers étaient des livres de programmation.

« Soit les gens sont pressés d’apprendre la programmation, soit la programmation est en quelque sorte fabuleusement plus facile à apprendre que toute autre chose », a-t-il conclu. Bien sûr, il pense que c'est plutôt parce que les gens sont pressés d'apprendre la programmation, mais il avertit qu'on ne peut rien apprendre de bon dans de courts délais, peu importe les techniques pédagogiques utilisées : « une mauvaise programmation est facile, les idiots peuvent l'apprendre en 21 jours, même s'ils sont des nuls », dit-il en citant des auteurs d'un bouquin en informatique.

Ses raisons sont évidentes. Dans un court délai, vous n'aurez pas le temps d'écrire plusieurs programmes significatifs, et d’apprendre de vos succès et échecs. Vous n'aurez pas non plus le temps de travailler avec un programmeur expérimenté et de comprendre ce que c’est de vivre dans cet environnement. En résumé, vous n’aurez pas le temps d’apprendre vraiment. Vous allez vous familiariser à la programmation ou au langage en question, sans avoir de connaissance approfondie. C'est ce.qu'il exprime par une citation du poète anglais Alexander Pope : « a little learning is a dangerous thing », ce qui peut se traduire en français par : « un peu d'apprentissage est une chose dangereuse ».

https://www.developpez.com/public/im...ter-norvig.jpg
Peter Norvig, directeur de recherche chez Google

Cela dit, pour avoir du succès en tant que développeur, Peter Norvig propose, entre autres, de :
- s'intéresser avant tout à la programmation, et le faire parce que c’est agréable. Du moins, cela doit être suffisamment agréable de sorte que vous désiriez vouloir y consacrer 10 ans ;
- apprendre la programmation par la pratique ;
- échanger avec d’autres programmeurs et lire d'autres programmes. C’est, selon lui, plus important que n’importe quel livre ou cours ;
- suivre une formation informatique de 4 ans ou plus, ce qui va vous donner une compréhension plus approfondie du domaine et un accès à des emplois qui nécessitent des qualifications. Sinon, Peter Norvig pense que vous pouvez aussi suivre le chemin de l'autodidacte, pour acquérir des compétences similaires, mais estime que l'apprentissage par les livres ne sera pas suffisant ;
- travailler sur des projets avec d’autres programmeurs, en tant que numéro un pour certains projets et à la dernière place dans d'autres projets. A la tête d'un projet, vous allez tester vos habiletés à mener un projet, et à inspirer les autres par votre vision. Dans l'autre cas, vous allez apprendre ce que font les leads et apprendre ce qu’ils n’aiment pas faire (parce qu’ils vous le donneront à faire) ;
- travailler sur des projets après d’autres programmeurs, par exemple prendre le temps de comprendre un programme écrit par quelqu’un d’autre. Cela devrait vous permettre d'avoir une idée de l’effort nécessaire pour le comprendre et le corriger lorsque les programmeurs initiaux ne sont plus là. Cela devrait en outre vous faire réfléchir à la manière de concevoir vos programmes de manière à faciliter la vie de ceux qui vont les maintenir par la suite ;
- apprendre au moins une demi-douzaine de langages de programmation, y compris un langage qui supporte l’abstraction de classe (comme Java ou C++), un qui supporte l’abstraction fonctionnelle (comme Lisp ou Haskell), un qui supporte l’abstraction syntaxique (comme Lisp), un qui supporte les spécifications déclaratives (comme Prolog ou les templates C++) et un qui supporte le parallélisme (comme Clojure ou Go) ;
- toujours se rappeler que l’ordinateur fait partie intégrante de l’informatique. Peter Norvig estime en effet que vous devez savoir combien de temps cela prend à votre ordinateur pour exécuter une instruction, lire un mot dans la mémoire (qu’il soit déjà dans la mémoire cache ou pas), lire des mots consécutifs à partir du disque ;
- s'impliquer dans un projet de standardisation d’un langage. Il pourrait s'agir d'un projet de standardisation international ou juste de décider si votre style de codage local aura des indentations de 2 ou 4 espaces. De toute manière, Peter Norvig pense que cela va vous permettre de connaitre ce que les autres aiment dans un langage, à quel point ils y tiennent, et peut-être un peu sur leurs raisons.
Source : Peter Norvig

Et vous ?

:fleche: Qu'en pensez-vous ?
:fleche: Faut-il remplir toutes les conditions citées ici par Peter Norvig pour être un développeur expérimenté ou accompli ?
:fleche: Quelles conditions sont les plus nécessaires ?
:fleche: Vous considérez-vous comme un développeur accompli ou expérimenté ? Si oui, combien d'années cela vous a-t-il pris ?

Voir aussi :

:fleche: Comment devenir un meilleur développeur ? La formation et l'expérience sont-elles suffisantes ? Vous êtes invités à partager votre avis
:fleche: Que faire pour minimiser l'impact des interruptions sur l'activité de développement de logiciels ? Appliquer les méthodes Agile ?
:fleche: Y a-t-il une corrélation entre diplôme et succès en tant que développeur de logiciels ? Un acteur de la sphère donne son avis
:fleche: Pourquoi réécrire un projet en partant de zéro ? Parce que l'ancien code est un fatras ou qu'il est plus facile d'écrire que de lire un code ?
:fleche: Que pensez-vous des formations intensives en programmation ? Sont-elles plus efficaces que les formations classiques en informatique ?
16/05/2018, 10h22
Matthieu76

Citation:

échanger avec d’autres programmeurs et lire d'autres programmes. C’est, selon lui, plus important que n’importe quel livre ou cours ;

Citation:

travailler sur des projets avec d’autres programmeurs, en tant que numéro un pour certains projets et à la dernière place dans d'autres projets.

Je suis entièrement d'accord, en développant en équipe avec des programmeurs expérimentés j'ai rapide appris des choses que je n'aurais jamais su même en 20 ans de programmation en solo.
16/05/2018, 10h35
Invité

Je pense que tout dépend le domaine d'activité dans lequel on va se situer... et ce que la/les boite(s) où on va travailler vont réclamer.

Ca ne peut en effet fonctionner que lorsqu'on travaille sur des technos ou langages plutôt stables dans le temps; avec peu d'évolutions (ou alors des évolutions logiques, comme on peut en voir par exemple en C++).

Pour avoir bossé pendant 10 ans dans une boite qui est passé d'un EDI vers java jee, je peux juste affirmer que si les conditions ne sont pas remplies (formation continue avec au moins 1 jour par semaine qui y est dédié); les dev séniors peuvent être vite largués.

Sans compter que dans ce langage là avec les effets de mode, on change de lib tous les 6 mois... il est donc totalement impossible de passer 10 ans sur une lib pour en maitriser le fonctionnement.

Résultat : on passe son temps à être un 'débutant' et à peine on commence à saisir le fonctionnement de l'engin, il faut passer au suivant.

(c'est un peu pour ça que je suis en reconversion...)
16/05/2018, 10h55
onilink_

Tout dépend des technos utilisées j'ai envie de dire, et ce que l'on appelle un développeur accompli (qualité? rapidité? maintenabilité?)

Pour mon expérience, C++ est un langage long a maîtriser, malgré que l'on puisse gratter la surface très rapidement (et se penser bon, tant qu'on reste sur de petits projets on ne comprend pas forcement certaines difficultés).
Pour C++ je pense qu'il faut pratiquer au moins 3 ans (a raison de 35h par semaine minimum hein, pas juste en faire de temps en temps), et SURTOUT, entouré des bonnes personnes (des personnes calées niveau standard, qui vont t'expliquer ce qu'est une UB, comment ne pas en faire, a mieux utiliser la docu etc, c'est pas forcement évident tout seul au début) pour arriver a un bon niveau. Il ne faut pas oublier aussi que les standards évoluent, et qu'il faut donc régulièrement se mettre a jour. Il est inacceptable de ne pas faire du C++11 de nos jours si la toolchain est compatible par exemple (voir du c++14).

A première vue, Rust semble aussi être un langage long a maîtriser pleinement, a moins que ce soit surtout le début (j'aimerais des retours) étant donné que le langage semble bien conçu pour empêcher les devs de faire n'importe quoi avec (beaucoup de choses se font en "compile time").

A côté de ça, il y a des langages conçus pour être rapidement maîtrisés. Certains font ça correctement, d'autres non.
Je pense notamment a java qui veut faire croire que c'est un langage simple d'utilisation, mais qui en réalité ne l'est pas, a cause de beaucoup d'exception aux règles, de tricks chelous et de règles stupides.
On a aussi javascript et tout ses fameux corner cases bizarroïdes et éléments perturbateurs, au final le langage a l'air simple de loin mais ça devient vite un cauchemar dans un champ de mines.
Ou encore PHP avec sa bibliothèque standard foireuse (sans compter pas mal de problèmes dans le langage en lui même).

Au final je vois peu de langage assez bien pensés pour être rapidement maîtrisés, sans avoir a connaître une palanquée de corner cases et de pièges à éviter.
16/05/2018, 11h17
danielhagnoul
:salut:

Chimiste de formation et autodidacte en informatique, j'ai commencé avec un Apple II et le Basic, puis très vite, le langage Pascal. Au fur et à mesure des années et de l'évolution du matériel, j'ai pratiqué aussi un peu de C, de C++, et de C#.

Depuis plusieurs années, je me consacre au JavaScript, au HTML et au CSS.

Les seules choses dont je sois persuadé :
- le temps du "touche à tout" est révolu ;
- il faut se spécialiser dans un langage et dans un domaine ;
- il faut apprendre quelque chose de nouveau tous les jours ;
- le sujet évolue plus vite que je ne peux l'absorber.
Je constate souvent que les jeunes ont tendance à se satisfaire de ce qu'ils pensent maîtriser et à rester dans leur zone de confort. Quelques années plus tard, je pense à 5 ans, ils s'aperçoivent avec effroi qu'ils sont en train d'être largués et qu'il leur reste une montagne de choses à apprendre.

Mais vous me direz sans doute qu'à 68 ans je peux me reposer, qu'elle horreur, le repos c'est la mort. :mouarf:
16/05/2018, 11h25
Drowan

Citation:

échanger avec d’autres programmeurs et lire d'autres programmes

+1

Citation:

Envoyé par akd

on change de lib tous les 6 mois... il est donc totalement impossible de passer 10 ans sur une lib pour en maîtriser le fonctionnement.
Résultat : on passe son temps à être un 'débutant' et à peine on commence à saisir le fonctionnement de l'engin, il faut passer au suivant.

C'est justement là où l'expérience (plusieurs années) dans la programmation fait la différence. Tu as l'habitude de chercher à comprendre des mécanismes et tu en connais déjà un grand nombres. C'est donc bien plus facile de s'adapter. Alors que via des livres et apprentissage rapide, on pas eu le temp d'apprendre à s'adapter et à chercher.

Citation:

Envoyé par onilink_

A côté de ça, il y a des langages conçus pour être rapidement maîtrisés. Certains font ça correctement, d'autres non.
Je pense notamment a java qui veut faire croire que c'est un langage simple d'utilisation, mais qui en réalité ne l'est pas, a cause de beaucoup d'exception aux règles, de tricks chelous et de règles stupides

Je suis d'accord avec toi, il ne faut pas croire que Java est facile à apprendre ou maitriser. Je pense d'ailleurs pas qu'il y ai de langage vraiment facile à maitriser.
Je pense notamment que Java n'est pas un bon langage pour démarrer la programmation car il est basée sur un paradigme complexe qu'est l'orienté objet.
Pour moi, un débutant doit démarrer par du "simple" procédurale (base de la programmation) et si possible sans s'attacher à un langage particulier (vive le papier et le stylo). Quand il est à l'aise avec cela (et ça prend du temps) il peut commencer à l'appliquer dans un langage (par exemple C) mais tout en sachant qu'il y a plein de tricks qu'il ne connait pas par rapport à ce langage. Et quand enfin il est plutôt serein avec ça, il peut attaquer d'autres paradigmes (POO, fonctionelle, etc). Ben tout ça, ça prend du temps, beaucoup de temps

Citation:

Envoyé par onilink_

règles stupides

Je suis curieux de connaitre ces règles, tu dis ça de manières objective ou moyennement ?
Tu as des exemples ?
16/05/2018, 11h42
grunk
La maîtrise d'un langage est une chose qui peut prendre du temps , mais ce qui fait un bon développeur selon moi , ce n'est pas forcément sa maîtrise du langage (ça reste important) mais plutôt sa capacité à faire les bons choix technique, à anticiper la vie du code.
Et pour arriver à prendre les bonnes décisions au bon moment , ça demande de s'être trompé , d'avoir recommencé , encore et encore ... et inévitablement cela prend du temps.
Citation:
Envoyé par danielhagnoul

il faut se spécialiser dans un langage et dans un domaine ;
Je suis d'accord avec ça sauf qu'aujourd'hui le marché de l'emploi va à l'opposé.
Pour le web par exemple , il faudrait des dev frontend (html/css/js) , des dev backend (php/java/js/...) des dba (gestion base de données) et des admin système. Sauf que le seul mot qu'on les employeur à la bouche c'est "fullstack" , comprendre , qui sait tout faire. Et on va pas se mentir il est impossible d'être au top sur tous à la fois.
16/05/2018, 11h47
Anselme45

Citation:

Envoyé par danielhagnoul

.
Je constate souvent que les jeunes ont tendance à se satisfaire de ce qu'ils pensent maîtriser et à rester dans leur zone de confort. Quelques années plus tard, je pense à 5 ans, ils s'aperçoivent avec effroi qu'ils sont en train d'être largués et qu'il leur reste une montagne de choses à apprendre.

D'un point de vue théorique, c'est juste... Malheureusement, il y a bien longtemps que votre description ne correspond plus à la réalité du monde économique!

Les jeunes ne restent pas dans "leur zone de confort" (c'est un terme qui ne se voit plus en entreprise) et ne se satisfassent pas de leur connaissance, ils sont en permanence mis sous pression par leur hiérarchie qui ne leur laisse aucune possibilité de se former.

Dans le monde de l'informatique d'aujourd'hui, on ne planifie pas la formation du développeur (cela coûte trop cher): On se contente d'engager le spécialiste déjà formé pour ensuite le virer dès qu'il a fait son office.

Ce n'est pas pour rien que les SSII pullulent et que les mandats limités à 3-6 mois destinés aux "moutons à 5 pattes" sont beaucoup plus nombreux que les contrats en CDI :mrgreen:
16/05/2018, 12h03
sergio_is_back

Citation:

Envoyé par grunk

La maîtrise d'un langage est une chose qui peut prendre du temps , mais ce qui fait un bon développeur selon moi , ce n'est pas forcément sa maîtrise du langage (ça reste important) mais plutôt sa capacité à faire les bons choix technique, à anticiper la vie du code.
Et pour arriver à prendre les bonnes décisions au bon moment , ça demande de s'être trompé , d'avoir recommencé , encore et encore ... et inévitablement cela prend du temps.

Oui, beaucoup de langages ont évolués au cours du temps et en maitriser tous les aspects peu vite devenir chronophage... Malgré 20 le nez dans Delphi j'en découvre encore tous les jours... Et que dire de C++ quoi n'arrête pas d'évoluer ces dernières années... Pour Python, Java, Php et les autres, comme dit plus haut dans ce topic je n'ai fais "que gratter la surface" même si j'ai déjà mené des développements dans ces langages....

Il est très rare d'utiliser un langage à ses pleines possibilités, du fait que l'on est aussi limité par notre propre vision "de ce que l'on développe", les raccourcis que l'on choisit ne sont pas toujours les plus appropriés même si ils fonctionnent et très souvent d'autres possibilités du langage choisi pourraient être mieux exploités

Citation:

Envoyé par grunk

Je suis d'accord avec ça sauf qu'aujourd'hui le marché de l'emploi va à l'opposé.
Pour le web par exemple , il faudrait des dev frontend (html/css/js) , des dev backend (php/java/js/...) des dba (gestion base de données) et des admin système. Sauf que le seul mot qu'on les employeur à la bouche c'est "fullstack" , comprendre , qui sait tout faire. Et on va pas se mentir il est impossible d'être au top sur tous à la fois.

"fullstack" c'est encore un de ces termes qui veut tout et rien dire à la fois, ceux qui l'emploient à tour de bras n'ont souvent que très peu de culture technique et c'est plus souvent pour se faire mousser...

Tout maîtriser demande du temps, de l'expérience (toujours l'histoire de la théorie et de la pratique), il faut juste être curieux des choses, savoir sortir de sa zone de confort, être ouvert
Et avoir de bonnes bases

Les gens qui remplissent ces critères sont selon moi des "fullstack"

Et pas hésiter à parcourir les forums techniques comme developper.com, stackoverflow et d'autres, qui sont des mines d'infos et savoir additionner 1 et 1 pour faire 2 et pas s'arrêter à la première réponse
trouvée qui est peu être bonne mais rarement la seule...
16/05/2018, 12h16
onilink_

Citation:

Envoyé par Drowan

Je suis curieux de connaitre ces règles, tu dis ça de manières objective ou moyennement ?
Tu as des exemples ?

Un exemple qui touche pas mal de collègues qui bossent dans le domaine, c'est l'égalité, avec == qui compare par référence et equals qui compare par valeur qui peuvent poser pas mal de pièges assez vite:
https://stackoverflow.com/questions/...rting-to-integ
https://stackoverflow.com/questions/...trings-in-java

Y a pas mal de casses têtes aussi avec les primitives qui ne fonctionnent pas par référence.
J'ai pas mes collègues sous la main mais je me souviens qu'il y avait beaucoup de problèmes du genre.
Je posterais quand je les aurais si ça t’intéresse. Ce que j'en ai retenu, c'est que le langage n'est pas homogène au niveau des règles, et on tombe souvent dans des pièges absurdes (si ce n'est pas dans des limitations).
16/05/2018, 12h41
sergio_is_back
Citation:

Envoyé par onilink_

Un exemple qui touche pas mal de collègues qui bossent dans le domaine, c'est l'égalité, avec == qui compare par référence et equals qui compare par valeur qui peuvent poser pas mal de pièges assez vite:
https://stackoverflow.com/questions/...rting-to-integ
https://stackoverflow.com/questions/...trings-in-java

Y a pas mal de casses têtes aussi avec les primitives qui ne fonctionnent pas par référence.
J'ai pas mes collègues sous la main mais je me souviens qu'il y avait beaucoup de problèmes du genre.
Je posterais quand je les aurais si ça t’intéresse. Ce que j'en ai retenu, c'est que le langage n'est pas homogène au niveau des règles, et on tombe souvent dans des pièges absurdes (si ce n'est pas dans des limitations).

C'est pas débile : Integer est une classe en Java du coup dans l'exemple sur ton premier lien b2 et b3 sont des instances (des pointeurs)
donc l'instance b2 n'est pas "égale" à l'instance b3 (c'est deux instances différentes) même si elles sont initialisées avec le même contenu...

En java il ne faut confondre l'entier "natif" : int avec la classe "Integer"
C'est pas la même chose...

Par exemple :
Code:

1 2 3 4 5 6 7 8 class D { public static void main(String args[]) { Integer b2=128; Integer b3=128; System.out.println(b2==b3); } }
Renverra faux

Alors que
Code:

1 2 3 4 5 6 7 8 class D { public static void main(String args[]) { int b2=128; int b3=128; System.out.println(b2==b3); } }
Renverra vrai

Tu as mal lu, dans les deux cas il s'agit d'Integer:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class Hello
{
  public static void main(String[] args)
  {
    {
    Integer b2=127;
    Integer b3=127;
    System.out.println(b2==b3); // true
    }
    {
    Integer b2=128;
    Integer b3=128;
    System.out.println(b2==b3); // false
    }
  }
}

16/05/2018, 12h54
yildiz-online

Citation:

Envoyé par onilink_

Ce que j'en ai retenu, c'est que le langage n'est pas homogène au niveau des règles, et on tombe souvent dans des pièges absurdes (si ce n'est pas dans des limitations).

Si, et la règle est on ne peut plus simple: on ne compare JAMAIS des objets avec ==, rien d'autres à savoir.

Si tu veux creuser pourquoi certains objets passent avec == ce sont des optimisations de la JVM (pools), donc propre à l'environnement d’exécution et non au langage, il ne faut donc pas du tout en tenir compte.
16/05/2018, 13h09
sergio_is_back

Citation:

Envoyé par yildiz-online

Si, et la règle est on ne peut plus simple: on ne compare JAMAIS des objets avec ==, rien d'autres à savoir.

Si tu veux creuser pourquoi certains objets passent avec == ce sont des optimisations de la JVM (pools), donc propre à l'environnement d’exécution et non au langage, il ne faut donc pas du tout en tenir compte.

Exact : comme b2 possède la même valeur que b3 et qu'ils ne sont pas altérés après déclaration la JVM peut décider de faire pointer les deux instances sur le même "emplacement mémoire"... Mais c'est pas garanti
C'est comme ça que dans un cas "==" peut renvoyer vrai et faux dans l'autre... Mais y'a que les développeurs de la JVM qui pourraient l'expliquer, j'en suis pas un

En règle général pour des utilisations "standard" il vaut utiliser les types primitifs "int", "short", "byte", etc... que les classes "Integer", "Boolean", etc...
La programmation est facilitée (plus besoin de se poser la question pour == ou .equals) et la consommation mémoire bien moindre

Voir cet article (et les deux liens dans la première réponse) :

https://stackoverflow.com/questions/...nt-and-integer

Citation:

Envoyé par onilink_

Un exemple qui touche pas mal de collègues qui bossent dans le domaine, c'est l'égalité, avec == qui compare par référence et equals qui compare par valeur qui peuvent poser pas mal de pièges assez vite:

Maintenant pour tes collègues c'est peu être un problème de formation ou d'habitudes (ou de manque d'attention)
16/05/2018, 13h09
GordonFreeman

Clairement convaincu par ses propos

En ce qui me concerne, ça fait plus de 20 ans que je suis dans la technique et env 10 ans que j'ai décidé de me focaliser su le langage Java (après avoir fait du Pascal, PHP, javascript, C#)
Ma conclusion (pour le développement en général), plus j'en apprend, moins j'en sait...

La programmation est un monde complexe, ne serait-ce que connaitre un langage et son API prend un temps énorme. Mais c'est une infime partie de la connaissance requise pour être un bon développeur.
Ensuite viennent les concepts POO, APO, etc. le toolings, les bonnes pratiques, la conception, code maintenable, ensuite les framework et autres API, etc. etc etc.....

Et comme tous évolue très vite en matière de développement, dès qu'on maîtrise plus ou moins un outils/API/etc, ben on recommence.

C'est un monde excitant mais un peu fatiguant à la longue.
16/05/2018, 13h13
Drowan

Oula je voulais pas faire dériver le débat :oops:

J'étais juste curieux d'apprendre un truc, parce que je fais beaucoup de Java et ça m'intéressait si y'avait un truc chelou à savoir :mrgreen:
16/05/2018, 13h19
sergio_is_back

Citation:

Envoyé par Drowan

Oula je voulais pas faire dériver le débat :oops:

T'inquiète pas c'est fait pour dériver les débats... Et là on part sur du technique, c'est le coeur de developpez.com

Citation:

Envoyé par Drowan

J'étais juste curieux d'apprendre un truc, parce que je fais beaucoup de Java et ça m'intéressait si y'avait un truc chelou à savoir :mrgreen:

Ben... Justement, est-ce que les explications sont satisfaisantes ?
16/05/2018, 13h40
Drowan

Citation:

Envoyé par sergio_is_back

T'inquiète pas c'est fait pour dériver les débats... Et là on part sur du technique, c'est le coeur de developpez.com

Oui bien sûr mais là on est quand même loind du sujet en à peine 5 messages :mouarf:

Citation:

Envoyé par sergio_is_back

Ben... Justement, est-ce que les explications sont satisfaisantes ?

Le cas du == pour 128 dû à la JVM c'est effectivement intéréssant, donc là je suis satisfait d'avoir appris un truc ;).
Mais par contre comme dis par Yildiz, le règle est homogène : on compare les valeur avec .equals() et les référence avec ==.
Donc là je suis moyen satisfait de pas avoir d'exemple d'endroit où la règle est pas homogène, s'il y en a ; ou d'une documentation qui explique que toutes les règles de Java sont homogène.

Pour revenir au sujet, 10ans c'est bien on peut le compter sur les doigts :aie:
Plus sérieusement, qu'est-ce qu'on compte dans les années de programmation ? Parce qu'effectivement une année au lycée j'avais fait un peu de python, on avait dû faire un genre de programme qui trouve un nombre entre 1 et 100 par dichotomie.
Mais de souvenir on suivait un peu les consignes sans vraiment comprendre ce qu'on faisait. Je considère que mes années de programmation commencent à mes études sup (et encore en cycle prépa on en faisait pas beaucoup en temps). Donc perso je dirais que j'en suis plutôt à 5-6 ans de programmation #TeamDébutantVuL'article :mrgreen:
16/05/2018, 13h41
bilgetz
Citation:

Envoyé par sergio_is_back

Exact : comme b2 possède la même valeur que b3 et qu'ils ne sont pas altérés après déclaration la JVM peut décider de faire pointer les deux instances sur le même "emplacement mémoire"... Mais c'est pas garanti
C'est comme ça que dans un cas "==" peut renvoyer vrai et faux dans l'autre... Mais y'a que les développeurs de la JVM qui pourraient l'expliquer, j'en suis pas un

En règle général pour des utilisations "standard" il vaut utiliser les types primitifs "int", "short", "byte", etc... que les classes "Integer", "Boolean", etc...
La programmation est facilitée (plus besoin de se poser la question pour == ou .equals) et la consommation mémoire bien moindre

Voir cet article (et les deux liens dans la première réponse) :

https://stackoverflow.com/questions/...nt-and-integer

Maintenant pour tes collègues c'est peu être un problème de formation ou d'habitudes (ou de manque d'attention)

Si tu regarde bien la Class Integer, tu verra une classe static IntegerCache qui a en cache les integer de -128 a 127, et elle serve à l'auto-boxing (et au valueOf)
du coup quand tu fait :
Code:

1 2 3 Integer b2=127; Integer b3=127;
Grace a l'auto-boxing, tu aura la même référence, car elle sont en cache.

mais quand tu fait
Code:

1 2 3 Integer b2=128; Integer b3=128;
tu as toujours de l'auto-boxing, mais cela n'est pas en cache, du coup les 2 Integer seront créer.
16/05/2018, 13h46
yildiz-online

Citation:

Exact : comme b2 possède la même valeur que b3 et qu'ils ne sont pas altérés après déclaration la JVM peut décider de faire pointer les deux instances sur le même "emplacement mémoire"... Mais c'est pas garanti
C'est comme ça que dans un cas "==" peut renvoyer vrai et faux dans l'autre... Mais y'a que les développeurs de la JVM qui pourraient l'expliquer, j'en suis pas un

Les pools pour les wrapper objects (Integer, Boolean,...) contiennent une liste préinitialisée et limitée de valeurs, par exemple pour les Integer, ça ira de -128 à 127.
Pour utiliser des valeurs de ce pool, il faut passer par une initialisation litérale et pas par un new:

Integer.valueOf(10) == Integer.valueOf(10) mais new Integer(10) != new Integer(10) et Integer.valueOf(128) != Integer.valueOf(128)

Pour les String, un pool existe aussi, mais il est plus complexe(basé sur des index de sous chaine), aussi uniquement utilisable via literal "myString", et pas new String("myString").
Par contre on peut forcer une new String("myString") vers le pool en utilisant la methode intern().

Voir 40 message(s) de cette discussion en une page