Discussion :

[Neckara]

J'imagine qu'il fait référence à la bonne pratique de design composition over inheritance.

Je vois, cependant cela ne pose pas de problèmes avec l'héritage virtuel.

Après, d'après la page Wikipédia, il n'y a pas vraiment de problème d'utilisation abusive de l'héritage, tout du moins en Java.

A 2013 study of 93 open source Java programs (of varying size) found that:

While there is [no] huge opportunity to replace inheritance with composition (...), the opportunity is significant (median of 2% of uses [of inheritance] are only internal reuse, and a further 22% are only external or internal reuse). Our results suggest there is no need for concern regarding abuse of inheritance (at least in open-source Java software), but they do highlight the question regarding use of composition versus inheritance. If there are significant costs associated with using inheritance when composition could be used, then our results suggest there is some cause for concern.
— Tempero et al., "What programmers do with inheritance in Java"^[6]

https://en.wikipedia.org/wiki/Compos...er_inheritance

[_skip]

Pourquoi ?

Aurais-tu un exemple à nous proposer ?

Il a raison malheureusement. L'enseignement a tendance à survendre les bienfaits de l'héritage, lorsqu'il ne sanctionne pas carrément le fait de ne pas y avoir recours...
Je préfère 100 fois un peu de duplication de code et quelques interfaces entre les classes qu'un lien de parenté qui n'est là que pour économiser l'écriture de 2 ou 3 méthodes (en sachant qu'il existe d'autres façons de factoriser). La raison est simple, c'est souvent bien plus facile lorsqu'on travaille en équipe de comprendre rapidement un code lorsque ce dernier n'utilise pas d'héritage ou de polymorphisme et préserve une certaine horizontalité. Lorsqu'on lit le code écrit par quelqu'un d'autre, on apprécie d'avoir sous les yeux une unité de travail relativement homogène sans devoir se balader de haut en bas pour trier ce qui est emprunté ci et là.

L'autre souci mentionné, soit l'évolution, c'est ce qui arrive au cours du cycle de vie de maintenance d'un code, lorsque 2 classes enfant qui avaient beaucoup en commun commencent à diverger, et c'est pire quand elles divergent précisément sur ce qu'elles avaient en commun. Ca passe soit par l'introduction de classes intermédiaires, du pull-up, pull-down de méthodes existantes, soit par de l'override (pratique relativement dangereuse et dégueulasse qui rajoute des contraintes quant à l'évolution de la classe parent). Et oui, l'héritage c'est aussi une forme de couplage qui peut nuire.

Ne pas utiliser l'héritage? non ce serait dommage de se priver d'un outil, mais réfléchir à 10 fois à ce que ça peut entraîner, oui! Je vois beaucoup de cas où l'héritage est utilisé pour mettre en commun 3-4 champs et getters/setters, et ça vraiment je pense que c'est une erreur. Le meilleur code c'est celui qui se lit facilement, se comprend facilement et évolue facilement, et l'héritage peut vite faire perdre des points sur ces trois aspects.

[mermich]

Ben l'heritage est la soulution de couplage la plus forte, mais aussi la plus contraignate.

Je recommande de voir la presentation de sandi metz a ce sujet: https://www.sandimetz.com/blog/2016/...ng-abstraction

[EpiTouille]

Pour moi la plupart des problèmes que j'ai avec le JavaScript sont intrinsèques au langage : typage dynamique, opérations surprenantes, portée des variables, ... bref des choses qui ne pourront de toute façon pas être corrigé a moins de casser la compatibilité avec l'existant.

Pour ce qui est du typage dynamique, je dirais oui et non. Evidement, que c'est source de bug. Mais ça permet aussi une extreme souplesse (duck typing, fonction d'ordre supperieur etc.). Je dirais qu'une des forces du javascript, c'est son éco-système et son engouement. Ce qui a permis a des langages comme typescript (compilé derrière en javascript) de voir le jour (ou flow qui n'est pas un langage mais plus un système d'annotation de type pour javascript qui permet un typage statique). Ces langages là résolvent souvent les points que tu as cités. Les nouvelles normes javascript (> es6) ont résolu le problème de portée des variables avec les mot-clef let et const.
Après je suis d'accord que pour se faire une stack interessante en javascript et pouvoir s'amuser, il faut au moins:
- webpack + plugins
- babel + plugins
- Un framework d'UI comme react ou vue par exemple

Après, les outils mis en place, on aime faire du javascript

Ce sont des outils de bas niveau pas forcément facile à prendre en main au début. C'est pour ça qu'il existe des outils comme vue-cli ou create-react-app qui permette de démarrer avec un template de projet assez efficasse.

[popo]

Je veux dire, c'est un peu comme détester la POO et faire du Java, c'est quand même bien bien bien chelou

Comme on est venu à en parler lors d'une discussion entre collègues : ce n'est pas parce que tu fait du C# que tu sais faire de la POO.
Je pense que ça peut aussi s'appliquer à Java. Le mot de l'histoire est que faire la POO ce n'est pas uniquement créer des classes et beaucoup de développeurs oublient le plus important comme le S de SOLID ou à l'inverse créent des classes qui ne peuvent pas être réutilisées. Certes, toutes les classes ne sont pas faite pour être réutilisable mais des fois un peu de généricité ne fait pas de mal. J'ai vu pas mal de DAL maisons qui exposait une classe pour interfacer tel SGBD et une autre classe pour interfacer un autre SGBD, et qui étaient quasiment identiques.

Pardon, je m'éloigne un petit peu du sujet mais la phrase m'a bien fait rire.

[LapinGarou]

Si je pouvais voter je voterai Python:
- j'ai l'impression d'apprendre à programmer avec ce truc,
- + les "self" qu'il FAUT mettre et qui ne sont pas optionnels comme "this" en C#,
- sans compter que je le trouve bien plus chia... à débugger que du JavaScript par ex (pour ne parler que de langages de même niveau: script, faiblement typés).

Mais pas le choix quand il faut un script rapide à mettre en place avec ElasticSearch par ex.

Il n'y a pas à aimer ou pas un langage, il faut choisir celui qui convient pour un projet donné, point.
Même si on ne l'aime pas on est payé pour un résultat au final, pas pour ne faire que ce que l'on aime, on n'est pas encore au pays des bisounours.

Comment peut ne pas aimer le C# ?

[farid77]

delphi

[didier.cabale]

lanfage détester; delphi

vu l'argumentaire et le titre de la remarque, on ne risque pas de se laisser convaincre .. (ce qui est très positif pour les amateurs de ce formidable EDI qu'est Delphi)

[grunt2000]

Javascript
Je l'ai connu dès mes débuts. Avec ses premières incompatibilités Netscape, IE 5, puis Firefox...
Il fallait pour chaque navigateur écrire des ordres différents et avoir son petit livre des incompatibilités et changement de comportements connus, fonction par fonction, navigateur par navigateur. Ce que l'on faisait sur l'un gelait l'autre, et provoquait tout autre chose sur le suivant.
Depuis, on a fait du chemin. Et pour les navigateurs modernes (Chrome, Firefox et autres), ces listes sont maintenant accessibles sur Internet.

Un langage sans typage fort qui enthousiasme ceux qui écrivent les applications... et qui abat ceux qui les maintiennent.
Aujourd'hui, tout heureux les développeurs Angular qui nous mettent du js ou du ts partout... Comme c'est efficace et rapide, disent-ils !
Patience bonhomme, dans trois quatre ans, quand il va falloir maintenir ça, alors là on verra si c'était si bien que ça, à l'usage...
Et au pirate reconnaissant ! Des applications web avec du Javascript partout, c'est quand même le pied pour s'infiltrer !

Java
Ah ! Je l'apprécie. Malgré son problème avec les dates (il ne sait toujours pas les gérer simplement, il propose dix classes différentes pour ça toutes plus patraques les unes que les autres), et qu'il soit atteint du logger hell.
Vous ne connaissez pas le logger hell ?
C'est vous voulez utiliser le logger A ? Attention à bien désactiver le logger B dans la dépendance 1, les loggers B et C dans la dépendance 2, etc.

Cobol
Hein ? Mais tout le monde sait que ce n'est pas le Cobol, le problème.
Mais les développeurs Cobol, et la si grande assurance qu'ils ont d'eux-mêmes. De la certitude, teintée de condescendance parfois encore, qu'ils ont de détenir la vraie grande et seule informatique, et de ne jamais, jamais, mais alors jamais se remettre en question. Sur rien. C'est exceptionnel.

Assembleur
Mais il n'y a pas plus beau qu'un code assembleur 68000 ! Des années après, ça m'émeut encore, tellement il est bien fait.
Le 80x86, pardon mais il est laid.
Le 6502, j'en ai bouffé quand j'étais jeune, et je retiens qu'il est très difficile à manipuler.

C et C++
J'ai du respect pour ceux qui font encore du C et du C++.
Moi, je suis passé sur Java, mais je regrette l'époque où j'en faisais.
Un pointeur en void * qui se balade et qui fait tout planter parce qu'on sait pas ce qu'il est vraiment, ça fait plus professionnel qu'un Object qui provoque les mêmes problèmes.

C#
On m'a forcé à suivre une formation dessus. Je suis mort d'ennui alors.
Mais pourquoi, pourquoi, pourquoi avoir fait ça ?

XSLT
Est arrivé sur terre pour faire mériter aux gens leur paradis.
Pour punir ceux qui abusent d'XML. Et il les châtie bien.

Scala
Il faut l'apprendre. Ça fait plus dix ans qu'il existe, qu'il doit tout remplacer tellement il est meilleur que Java.
Dans les faits remplace rien du tout, et tout le monde reste sur Java.
Alors il faut l'apprendre, vous comprenez ?! C'est une injonction. Sinon, il ne remplacera jamais rien.

[keokaz]

Le javascript pur lorsqu'on début c'est indigeste , et en plus on met des proto cela n'attire pas, c'est moins facile.

Je me demande l'effet que ça donne en niveau compréhension , prise ne main?

-on a d'abord étudier javascript puis JAVA
ou l'inverse
- on étudie JAVA puis le javascript

être plus rigoureux si l'on a appris java en premier être moins ordonnée en apprenant javascript.
Les fonctions qu'on appelle qui ne sont par ordre chronologique ça perturbe et le call back.

Mais il est vrais que avec le Typescript ça arranges les choses, même si en coulisse c'est du javascript qui tourne....

[_skip]

Les fonctions qu'on appelle qui ne sont par ordre chronologique ça perturbe et le call back.

Comment ça pas par ordre chronologique?

[Madmac]

Pour ce qui est du typage dynamique, je dirais oui et non. Evidement, que c'est source de bug. Mais ça permet aussi une extreme souplesse (duck typing, fonction d'ordre supperieur etc.). Je dirais qu'une des forces du javascript, c'est son éco-système et son engouement. .

Je ne sais pas, si cela s'applique pour tout les langages dynamiques. Mais dans le cas de Ruby, il suffit d'attribuer une valeur à une variable pour qu'elle se comporte de la même façon qu'une variable déclaré. Si j'assigne la variable X avec 0, je ne peux pas lui passé autre chose qu'une valeur numérique réelle. Et si tu veux une approche en béton, tu peux également vérifier la classe de la valeur que tu passe en paramètre.

Mais je suis étonné que de la 'popularité' de JavaScript.

[thierryc]

Pour moi, en tant qu'auditeur qui ai examiné de nombreux projets, C++ et Java sont une catastrophe:
- estimer un projet au forfait y est impossible, en tout cas d'après les promoteurs desdits langages,
- le planning, les coûts et les délais sont les premières victimes, avant que le turn-over s'installe,
- de toutes manières, il n'y a pas de planning, ni de budget, ni de délais, vu qu'on applique une méthode "Agile" (LOL),
- la dette technique achève les projets, la vélocité s'effondre, la fiabilité aussi,
- un nouveau manager arrive, détruit les projets inaboutis, .... et recommence.

En tout cas, vu les choix des langages en 2017, mon avenir professionnel est assuré :-)

[grunt2000]

Et quels sont les langages qui s'y prêtent, alors ?

[thierryc]

Et quels sont les langages qui s'y prêtent, alors ?

Démarrer un nouveau projet en Java ou en C++ est une faute professionnelle lourde pour un informaticien professionnel, sauf pour quelque besoin particulier (pilote système) ou pour tenter de maintenir un projet reçu un héritage ("legacy"), vu l'impact négatif de ces technologies de réalisation sur le projet et sur les femmes et les hommes (voir le sondage plus haut).

Pour un nouveau projet, la technologie de réalisation importe assez peu (sauf exceptions ci-dessus), le premier accent est à mettre sur la constitution d'une équipe aux talents variés (universitaires, ingénieures des grandes écoles, techniciens informaticiens), la formation des équipes, la mise en place d'un processus et d'une méthode solides, s'appuyant sur les choix technologiques. Si l'équipe se sont formée et soudée, rien ne lui est impossible. Et l'argent investi dans ces moyens initiaux est d'un excellent retour sur investissement.

Ensuite la technologie de réalisation vient en deuxième. Certaines parties (GUI) peuvent être réalisées en Javascript, en VB, VBA (!), en HTML5 ou toute autre technologie du même type. Le cœur métier peut être réalisé en python, delphi, pascal orienté composant, eiffel ou Ada si l'on a besoin d'un très haut niveau de qualité. La persistance peut être assurée par l'une des nombreuses bases libres comme PostGreSQL, MySQL, Firebird (surtout pas Oracle). Le moteur de règles peut éventuellement être réalisé dans un langage exotique comme lisp, smalltalk ou prolog. Éventuellement, un DSL ou deux peuvent être réalisés en fonction des besoins clients pour traiter la variabilité apparente des exigences. Les bibliothèques de composants disponibles et adaptés aux projet doivent être sélectionnés le plus souvent possible : la meilleure ligne de source est la ligne que l'on n'écrit pas. Le choix est donc une combinaison des choix. S'il s'agit de temps réel critique (avec certification), les choix se restreignent.

Bien cordialement,
Thierry

[Benbout]

Difficile d'exprimer un avis dénué de partialité quand il s'agit de répondre à un sondage de la sorte. J'ai voté pour javascript. Je n'aime pas javascript pour une raison particulière, son intégration avec le css et le html dans le développement web. Je trouve que cette "triade infernale" (reprenant l'expression d'un développeur dont j'apprécie les articles, olivier dahan) est la source d'une grande diversité de problèmes rencontrés lors du développement et du maintient d'une application web. Je ne développerais pas mon avis dans un argumentaire, ce n'est pas l'endroit et ce serait bien trop long pour y exposer des cas pratiques. J'ai aussi du mal à me résoudre à l'utilisation de sur-langages pour utiliser JS en typage fort et statique (tout comme python avec son projet mypy), mais leur succès n'est pas anodin. Obligés de travailler sur du js, les professionnels sont amenés à trouver des solutions étonnantes pour s'en accommoder.

Autre langage que je déteste, le LUA. En théorie, il a de quoi intéresser (lire ses spécificités), d'ailleurs je l'ai utilisé plusieurs fois comme langage de script pour des programmes c++ embarqués. Malheureusement, la lisibilité de sa syntaxe est si mauvaise (je ne parle même pas de la poo en lua, c'est horriblement lourd) que ce langage devient un véritable probleme dans des projets de grande taille. (pour lire un fichier avec une dizaine de fonctions, c'est facile, mais un projet avec 1000 fiches lua, il faut s'accrocher).

Il a raison malheureusement. L'enseignement a tendance à survendre les bienfaits de l'héritage, lorsqu'il ne sanctionne pas carrément le fait de ne pas y avoir recours...
Je préfère 100 fois un peu de duplication de code et quelques interfaces entre les classes qu'un lien de parenté qui n'est là que pour économiser l'écriture de 2 ou 3 méthodes (en sachant qu'il existe d'autres façons de factoriser). La raison est simple, c'est souvent bien plus facile lorsqu'on travaille en équipe de comprendre rapidement un code lorsque ce dernier n'utilise pas d'héritage ou de polymorphisme et préserve une certaine horizontalité. Lorsqu'on lit le code écrit par quelqu'un d'autre, on apprécie d'avoir sous les yeux une unité de travail relativement homogène sans devoir se balader de haut en bas pour trier ce qui est emprunté ci et là.

Au dela de la readabilité, c'est aussi et surtout une question de testabilité et de couverture optimale du code. L'héritage complexifie ce processus.
D'accord avec vous concernant l'enseignement!

Le C/C++ c'est délicieusement pédagogique mais dans la vraie vie et les applis principalement de gestion c'est s'embêter inutilement. Pour ces applis j'étais passé au Visual Basic à cette époque (le 4). Je crois qu'on garde C, principalement pour des applis bas niveau système et réseau. Je ne sais pas avec quoi on programme les jeux actuellement. Java, faut aimer, mais, en gros c'est similaire à C# qui est mon préféré.

Salut chauve souris. Pour répondre à ta question niveau jeu vidéo: les grosses boites sont toujours majoritairement des boites à C++. La raison en est simple, les écoles forment avant tout en C++, qui restent à tord ou à raison le langage de référence en terme de high performance programming. Mais on commence à apprendre le c# et le java aussi dans ces écoles, ca évolue. De plus, les grosses boites sont habitués à utiliser une palette d'outils exclusivement concus pour le développement de jeu vidéo, et ces outils sont très souvent lié à un développement de projet C++. Les indépendants eux sont plus dans des langages liés étroitement au moteur de jeu qu'ils ont téléchargés/achetés (java / c# avec unity par exemple, je ne dis pas javascript car unity a abandonné js, ce qui me semble raisonnable) .

[domi65]

Malgré les pouces en bas sur cette réponse, je suis d'accord. La preuve: le plus haï est javascript, qui est aussi celui que tout le monde utilise en programmation web... S'il était vraiment détesté, il ne serait plus là et remplacé par autre chose, ce ne sont pas les solutions plus jolies qui manquent !

Par quel langage de script tu peux remplacer JS dans une page web ?
Quant à JS, il est détesté pour trois raisons :
- il est mal (voire très mal) compris
- On confond JS et interface DOM
- La mauvaise prise en charge des navigateurs du couple JS-DOM complique son l'utilisation pour le web.

Perso, la seule chose que j'aurais à reprocher à JS, c'est son typage.

[domi65]

grossièrement tu c'est pas programmer donc tu trouve des excuse

Je connais le langage que tu détestes le plus : le français.

[grunt2000]

Le langage que je déteste ? N'importe lequel, avec Checkstyle :
vous avez mis static public ?! Mettez public static !
vous avez pas mis this. ? Mettez this !
l'accolade d'ouverture de fonction est passée à la ligne du dessous ? Mettez-là à côté de la parenthèse de déclaration de fonction !
(==> Développeurs C++, faites le contraire : votre checkstyle à vous va râler dans l'autre sens <==)
...
Des centaines d'heures de perdues sur des détails, parfois...
...
Ce n'est pas que je sois contre les programmes d'analyse du code,
mais seulement quand ils se limitent à la détection de problèmes réels : = au lieu de == dans un if, ou autres incidents aux effets concrets.

[Neckara]

Par quel langage de script tu peux remplacer JS dans une page web ?

Tu peux en théorie utiliser n'importe quel langage de scripts, tant qu'il est supporté par le navigateur.
De plus, il est aussi possible de "transcompiller" du code vers du JavaScript avec emscripten/asm.js.

Par exemple si le python était nativement supporté par les navigateurs, cela pourrait être plutôt intéressant.

Quant à JS, il est détesté pour trois raisons :
- il est mal (voire très mal) compris

Je pense surtout que ce sont les créateurs qui ont mal (voire très mal) compris.

Désolé, mais utiliser des nombres sur 64 bits, mais faire des opérations de décalage de bits sur 32 bits, c'est n'importe nawak. De même que de tuer l'aspect "commutatif" de certains opérateurs/conversions.
Je ne parle même pas des "classes" JavaScripts introduites avec ES6, qui ne supportent même pas l'appel d'une méthode (non-statique) de la classe mère ! Cela devait être trop compliqué à implémenter..