Discussion :

[bilgetz]

L’expérience de développeur, au delà de mieux maitriser un langage / librairie / framework , permet aussi de mieux comprendre et appréhender des concepts, de mieux cerner des patterns et leur défauts.
Tu as beau apprendre ce que tu veux dans des livres, tu ne verra que rarement les limites.

Je pense que tous le monde ici a déjà vue des architectures qui vont très bien sur des projet et qui se casse la gueule bien comme il faut sur d'autres.
Et ça, seul l’expérience peut le donner, qu'on l'ai vu en direct ou expliquer par des collègues.

[GordonFreeman]

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.

Hello, je ne comprend pas ta remarque : 'de pas avoir d'exemple d'endroit où la règle est pas homogène'.

Au final, la règle est toujours homogène. Ce qu'il faut retenir c'est le concept; en Java il n'y à pas de surcharge de l'opérateur '=='. Ce qui veut dire, comme dit plus haut que cet opérateur comparera toujours la référence des objets et non la valeur d'un objet (à la différence de C# par exemple : https://docs.microsoft.com/en-us/dot...able-operators).

De ce fait la comparaison de valeur se réalise tous le temps par la méthode .equals(..) en Java.
C'est également pour ça (et d'autres raison encore plus importantes!) que les méthodes .equals() et .hashcode() sont très importante en Java.

Mais c'est vrai, avec les optimisations de la JVM sur le valeurs jusqu'à 128 il serait possible de tester 2 valeurs avec ==. Mais ce n'est pas une raison pour le faire non plus

On dérive un peu du sujet oui, mais combien de développeur qui font du Java depuis plusieurs années ne maîtrisent pas ces concepts ?! J'en ai eu connus plusieurs, et ce genre de non maitrise du langage peut amener des problèmes très complexes à identifier...

Voili. Bonne journée.

[Drowan]

Hello, je ne comprend pas ta remarque : 'de pas avoir d'exemple d'endroit où la règle est pas homogène'.
Au final, la règle est toujours homogène

Ce que disait Onilink c'est "c'est que le langage n'est pas homogène au niveau des règles". Puis il a donné l’exemple du == en Java. Il s'avère que cette règle est homogène, donc c'est un mauvais exemple.

Je me demandais donc s'il y avait un exemple de règle non homogène en Java ? Ou s'il y a une règle (ou une certification, une documentation, un décret, un édit, un post-it) qui dit que les règles sont homogènes en Java ?

Par pas homogène j'entends très chelou, bizarre, ou avec exception : Par exemple si la règle "en Java on compare des types primitif avec ==" était "en Java on compare des types primitif avec == sauf les int parce qu'on trouvait ça rigolo de faire une exception pour ça"

[Pyramidev]

Étant donné que, en Java, la comparaison de valeurs des types primitifs se fait avec == alors que celles des objets se fait avec equals, on a bien une hétérogénéité, puisque ce n'est pas la même syntaxe dans les deux cas.

C++ a plein de règles complexes et bizarres mais, au moins, pour l'égalité, la syntaxe est vraiment homogène :
Comparaison de valeurs : variable1 == variable2.
Comparaison d'adresses : &variable1 == &variable2.

[bilgetz]

Un truc pas trop homogène en Java, c'est le passage de paramètres je pense (encore que y'a une logique).
Les type primitif se font par valeurs, les objets par référence.

mais bon, la on dérive grave du sujet de base ^^'.

[GordonFreeman]

Étant donné que, en Java, la comparaison de valeurs des types primitifs se fait avec == alors que celles des objets se fait avec equals, on a bien une hétérogénéité, puisque ce n'est pas la même syntaxe dans les deux cas.

C++ a plein de règles complexes et bizarres mais, au moins, pour l'égalité, la syntaxe est vraiment homogène :
Comparaison de valeurs : variable1 == variable2.
Comparaison d'adresses : &variable1 == &variable2.

Heu, perso je vois pas en quoi c'est plus homogène ? Parce que tu utilise dans les 2 cas '==' ?
Je pense que la surcharge d'opérateur amène plus de risque d'amener de l’ambiguïté.
Perso, pour moi la surcharge d'opérateur c'est comme l'héritage multiple, c'est le mal. Surtout que c'est réalisable dans certains cas (pas tous les opérateurs sont sur-chargeable en C# p. ex) alors pour le reste on fait quoi ? On déclare une méthode .equals() ou isModulo ?

Question (pour ma culture générale):
Il se passe quoi en C++ si les variables 1 et 2 sont de type différents dans l'expression : &variable1 == &variable2 ?
En Java sa ne compile pas, en C++ aucune idée je ne maitrise pas ce langage..

Après, tous est question de point de vue et de perception

[GordonFreeman]

Un truc pas trop homogène en Java, c'est le passage de paramètres je pense (encore que y'a une logique).
Les type primitif se font par valeurs, les objets par référence.

mais bon, la on dérive grave du sujet de base ^^'.

un petit article sur le passage des paramètres : https://www.developpez.net/forums/d5...tre-reference/

Oui c'est vrai on dérive même pas mal

[Pyramidev]

Heu, perso je vois pas en quoi c'est plus homogène ? Parce que tu utilise dans les 2 cas '==' ?

C'est plus homogène parce que cela ne dépend pas du type.
Que variable1 et variable2 soient des int, des std::string ou autre chose, la comparaison des valeurs se fait avec la syntaxe variable1 == variable2. Et pour comparer l'identité, on compare les valeurs des adresses : &variable1 == &variable2.

Je pense que la surcharge d'opérateur amène plus de risque d'amener de l’ambiguïté.

Je maintiens régulièrement du mauvais code C++ et, en pratique, je n'ai pas encore constaté d'abus de surcharge des opérateurs.

Question (pour ma culture générale):
Il se passe quoi en C++ si les variables 1 et 2 sont de type différents dans l'expression : &variable1 == &variable2 ?
En Java sa ne compile pas, en C++ aucune idée je ne maitrise pas ce langage..

On a une erreur de compilation aussi.

EDIT 15h18 : paragraphe erroné supprimé.

[Drowan]

Étant donné que, en Java, la comparaison de valeurs des types primitifs se fait avec == alors que celles des objets se fait avec equals, on a bien une hétérogénéité, puisque ce n'est pas la même syntaxe dans les deux cas.

Vu comme ça effectivement on peut se dire que ça ne l'est pas...
Mais d'un autre coté en Java on considère que les types et les objets sont des entités complètement différentes, il est donc aussi logique que la règle ne soit pas la même.
Mais on peut aussi pousser et se dire "int et char c'est différent pourtant la règle est la même", et c'est vrai

Je pense donc que :

Après, tous est question de point de vue et de perception

Et surtout

Oui c'est vrai on dérive même pas mal

[yildiz-online]

Un truc pas trop homogène en Java, c'est le passage de paramètres je pense (encore que y'a une logique).
Les type primitif se font par valeurs, les objets par référence.

mais bon, la on dérive grave du sujet de base ^^'.

Non les objets sont passés par copie de référence sinon leur réaffectation dans une fonction serait effective en dehors de la fonction, ce qui n'est pas le cas.
Le seul moyen d'outrepasser ça est d'utiliser un tableau, ou une classe englobante mais ça ne fait que déplacer le problème (si on réaffecte le tableau, ou le wrapper, c'est rebelotte).

[tanatiel]

Article intéressant.

J'ai 20 ans de carrière dont une large majorité en Java et ce que j'en retire c'est que j'apprends toujours (nouveaux frameworks, nouvelles manières de faire, évolutions du langage, etc...) et que j'apprends d'autant mieux quand je travaille en équipe en raison du partage d'expériences, des différents points de vue et j'en passe.

Chaque langage a ses bonnes pratiques et je pense que c'est là le plus important. Respecter les bonnes pratiques et le clean code, 2 choses qu'on peut apprendre en théorie mais dont on comprend l'intérêt par la pratique, surtout en maintenance applicative.

Je crois qu'il est important d'être passé par les différents types de développement: faire du build projet et faire la maintenance. Les contraintes ne sont pas les mêmes et cela apprend à se mettre à la place de l'autre et à comprendre son point de vue. Il est toujours facile de critiquer un code quand on ne l'a pas écrit mais dans quelles circonstances a-t'il été écrit?

Etre un développeur accompli demande une certaine pratique concrète pour être capable d'anticiper les écueils qui se présentent: changement de périmètre, spécifications bancales, cas innatendus, performances, sécurité...Le pire étant l'implicite, le non-dit, ce qui est tellement évident pour la MOA qu'elle ne l'exprime pas alors que la MOE n'en a pas conscience. Quand les gens me demande ce que je fais comme métier et que je réponds que je fais du développement informatique, en général il y a un silence. Alors j'explique que je suis un artisan qui fait du cousu main et qui, non seulement doit connaître son propre métier, mais également celui de son client.

Tout ça pour dire que rien ne remplace l'expérience concrète d'un ou plusieurs (c'est mieux!) projets. Combien en faut-il pour être "accompli", je ne saurai pas le dire mais avoir vécu un projet difficile aide à relativiser et permet de prendre du recul et revenir à la fois aux fondamentaux et à ne pas se faire de cheveux blancs inutilement.

[Invité]

Un truc pas trop homogène en Java, c'est le passage de paramètres je pense (encore que y'a une logique).
Les type primitif se font par valeurs, les objets par référence.

mais bon, la on dérive grave du sujet de base ^^'.

En java, les arguments sont toujours passés par valeur.

[cedric_g]

Pour ma part, j'utilise Visual Studio .Net depuis 2001 et s'il y a une chose qui a évolué dans ma manière d'aborder les projets, ce n'est pas tant l'efficacité intrinsèque de mes développements (en termes de performance par exemple), mais leur simplicité et leur structure qui a passablement évolué.

Pour faire une (énorme) simplification de mon raisonnement : mon code a probablement été divisé par 10 en 10 ans parce que :
- les frameworks ont évolué, et l'expérience permet d'en utiliser une part de plus ne plus large
- la réusabilité du code fait que l'on en tape de moins en moins
- l'utilisation de plus en plus forte de l'intégration objet fait que le code est de plus en plus lisible, maintenable et réutilisable

Ce n'est pas donc pas forcément la durée qui rend le code plus efficace. Mais une chose est sûre : il est plus qualitatif (à résultat égal).

[benjani13]

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.

C'est peut être par ce qu'un jeune sortant d'école en a un peu marre d'apprendre et veut pratiquer. Aussi en sortant d'école on pense avoir le bagage nécessaire à faire une longue carrière, puis on se rend compte en travaillant qu'on nous a pas appris grand chose. Je ne pense pas que ce soit beaucoup dit dans les études d'informatique que nous devons nous maintenir à niveau très régulièrement si on ne veut pas se retrouver vite dépassé. Et comme ça a été dit les entreprises ne joue pas le jeu de la formation tout en demandant tout le temps de nouvelles compétences.

[Matthieu76]

Je ne pense pas que ce soit beaucoup dit dans les études d'informatique que nous devons nous maintenir à niveau très régulièrement si on ne veut pas se retrouver vite dépassé.

Dans ma fac, il y a fallut attendre la 4^e année pour apprendre l'héritage et en gros on m'a dit: "Tu connais l'héritage, tu sais codé en C++."
Heureusement que je n'ai fait que ma 4^e et 5^e années à la fac mais pour ceux qui ont fait 5 années de fac...

99% de ce que j'ai appris en informatique vient de mes projets perso et sans eu je ne serais pas là où j'en suis actuellement. D'ailleurs même avec un bon boulot de développeur je continue mes projets perso, c'est important je pense.

[Matthieu Vergne]

Tout comme précisé dans un sujet tout récent, il s'agit d'avoir l'envie de s'améliorer et un bon coach. Le premier couvre le premier point :

• 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 ;

Le second couvre la plupart des autres. On y trouve notamment le coaching par les autres :

• é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) ;
• 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.

et le self-coaching :

• apprendre la programmation par la pratique ;
• 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 ;

Pour ce qui reste, c'est par contre discutable :

• 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) ;

Apprendre une demi-douzaine de langage est arbitraire. Si on souhaite devenir un expert dans un langage, nul besoin de perdre son temps à travailler d'autres langages. C'est un plus, mais apprendre par exemple les channels en Go quand on préfère faire du Java, ça n'apporte pas grand chose. Si on souhaite être capable de faire plusieurs langages, alors il faut que la pratique suive, et donc multiplier les langages. C'est une question d'objectifs.

• 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 ;

Là, par contre, c'est vraiment spécifique. On est dans le bas niveau, et on peut devenir bon programmeur sans ça. Si on fait du HTML/CSS/JS/..., ce genre de considération me semble franchement être de l'ordre du futile.

N'oublions pas qu'un bon programmeur n'est pas forcément un full stack. On peut être très spécialisé dans quelques langages qui marchent bien ensemble (e.g. technos Web), ou souhaiter mettre les mains dans des domaines différents. L'important étant de savoir ce qu'on veut et d'adapter son expérience en conséquence.

[yildiz-online]

Apprendre une demi-douzaine de langage est arbitraire. Si on souhaite devenir un expert dans un langage,

On attend pas d'un dev qu'il soit spécialiste dans un langage, on attend qu'il solutionne des problèmes.
Si certains langages avec des paradigmes plus pertinent pour résoudre une problématique donnée sont en phase avec le besoin, ce serait dommage de devoir se cantonner à son langage de prédilection sous prétexte qu'on en est expert.

La capacité d'adaptation et la visions plus large qu'offre un panel de paradigmes plutôt qu'un seul est sans aucun doute un avantage.

[Drowan]

Là, par contre, c'est vraiment spécifique. On est dans le bas niveau, et on peut devenir bon programmeur sans ça. Si on fait du HTML/CSS/JS/..., ce genre de considération me semble franchement être de l'ordre du futile.

Plus ou moins, c'est quand même la base de la programmation.

Et je pense que c'est utile pour comprendre des notions de base.
Comme le fait que des variables puissent être passées par référence ou par valeur, ou ce qu'est une stackOverflow, etc

Par contre je suis d'accord, connaitre le temps que ça prends d'aller lire une instruction je suis pas sûr que ça serve en haut niveau...

[Pyramidev]

Apprendre une demi-douzaine de langage est arbitraire. Si on souhaite devenir un expert dans un langage, nul besoin de perdre son temps à travailler d'autres langages. C'est un plus, mais apprendre par exemple les channels en Go quand on préfère faire du Java, ça n'apporte pas grand chose. Si on souhaite être capable de faire plusieurs langages, alors il faut que la pratique suive, et donc multiplier les langages. C'est une question d'objectifs.

Mouais, enfin, d'un autre côté, ce serait dommage de gâcher son intelligence en se restreignant à de la programmation orientée objet en Java alors que d'autres paradigmes permettent de pousser plus loin le niveau d'abstraction et parfois aussi les contrôles à la compilation.
(Certes, Java gratte aussi la surface de la programmation générique, mais il est avant tout orienté objet.)

Il n'y a même pas un an, j'étais satisfait du C++ et je préférais l'approfondir que d'explorer d'autres langages. C++ est statiquement typé, supporte à la fois le haut niveau et le bas niveau et permet de programmer en procédural, en objet et en générique. En programmant, j'étais content de réfléchir en C++, parce que je pensais avoir une large boîte à outils. Je ne voulais pas revenir au Java, que je considérais (et considère encore) comme moins enrichissant. Je n'étais pas motivé non plus par l'approfondissement d'un langage dynamiquement typé, car je pensais ne plus pouvoir y utiliser les astuces qui permettaient de repérer des erreurs directement à la compilation.

Ensuite, il y a quelques mois, j'ai commencé à apprendre le Haskell et je me suis pris une claque : comment ai-je pu manquer le paradigme fonctionnel alors qu'il facilite autant les abstractions ? Plus récemment, j'ai commencé à apprendre le D et je me suis pris une claque plus petite : D supporte mieux la programmation générique que le C++. Je savais déjà que la programmation générique permettait, sans perdre en abstraction, de pousser plus loin les contrôles à la compilation que la programmation orientée objet, mais c'était dans des proportions plus grandes que celles que je connaissais. D'ailleurs, en métaprogrammation aussi, D va beaucoup plus loin que le C++.

Et maintenant, je veux devenir expert en programmation générique, en programmation fonctionnelle et en métaprogrammation. Je veux approfondir Haskell et D et apprendre Rust et Common Lisp. J'apprendrai probablement aussi d'autres langages plus tard. J'ai de quoi m'occuper pendant longtemps.

[Matthieu Vergne]

On attend pas d'un dev qu'il soit spécialiste dans un langage, on attend qu'il solutionne des problèmes.

Tu confonds avec ingénieur. En l'occurrence, être spécialiste n'empêche pas de trouver des solutions. Il y a des gens hyper experts dans leurs technos qui font le boulot très bien. Il ne faut pas les considérer comme de l'histoire ancienne sous prétexte qu'il est devenu plus facile de programmer, et donc de se former à plusieurs langages. Maîtriser une techno n'a rien de trivial, ça prend énormément de temps et il faut en suivre les évolutions. Il s'agit de faire un choix entre généraliste et spécialiste, avec tout le continuum qu'il y a entre les deux. Il n'y a pas un côté mieux que l'autre.

Si certains langages avec des paradigmes plus pertinent pour résoudre une problématique donnée sont en phase avec le besoin, ce serait dommage de devoir se cantonner à son langage de prédilection sous prétexte qu'on en est expert.

Je fais la distinction entre ingénieur et technicien : on attend d'un ingénieur qu'il ait une boîte à outils bien fournie, on attend par contre d'un technicien qu'il maîtrise ses quelques outils sur le bout des doigts. Si le premier peut régler un problème en utilisant un autre outil, le second peut le faire en utilisant son outil de prédilection de manière adaptée. Le problème du premier est que cela introduit de la complexité de par l'hétérogénéité de la solution. Le soucis du second est la complexité introduite par les subtilités d'usage. Il n'existe pas qu'une seule façon de résoudre des problèmes.

Non, je n'ai pas dit que connaître plusieurs langages ne servait à rien. Ce que je dis est que ce n'est pas nécessaire pour être un bon développeur.

Plus ou moins, c'est quand même la base de la programmation.

Les origines si tu veux, mais je n'appellerai pas cela la base. L'algorithmie fait partie de la base, ça d'accord. Tu ne peux pas programmer sans faire de l'algorithmie. Mais tu peux programmer sans savoir ce qu'est un registre ni connaître la différence entre un envoi par valeur ou par référence (e.g. HTML, XML, CSS, Java). Avec les langages de haut niveau d'aujourd'hui, les concepts bas niveau n'ont pas grande utilité d'un point de vue général. Tout le monde les étudie parce que ça fait partie de l'histoire, mais honnêtement, ça sert à combien de personnes sur toute la population de dévs ?

Encore une fois, je ne dis pas que c'est inutile, mais ce n'est pas nécessaire pour devenir un bon dév.