Affichage des résultats du sondage: Quels sont les langages de programmation que vous détestez le plus en 2017 ? Pourquoi ?

Votants
241. Vous ne pouvez pas participer à ce sondage.
  • JavaScript

    106 43,98%
  • Java

    61 25,31%
  • PHP

    53 21,99%
  • Kotlin

    3 1,24%
  • VBA

    62 25,73%
  • Perl

    16 6,64%
  • Delphi

    9 3,73%
  • Cobol

    33 13,69%
  • Assembleur

    17 7,05%
  • C#

    8 3,32%
  • Python

    14 5,81%
  • C

    13 5,39%
  • Haskell

    4 1,66%
  • Pascal

    7 2,90%
  • R

    7 2,90%
  • MATLAB

    13 5,39%
  • Scala

    3 1,24%
  • Rust

    1 0,41%
  • TypeScript

    5 2,07%
  • Go

    8 3,32%
  • Swift

    6 2,49%
  • Fortran

    13 5,39%
  • Objective-c

    20 8,30%
  • Ruby

    11 4,56%
  • C++

    24 9,96%
  • Lisp

    16 6,64%
  • Autres, merci de les préciser

    10 4,15%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
Page 6 sur 6 PremièrePremière ... 23456
  1. #101
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2011
    Messages
    6 352
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 6 352
    Points : 16 393
    Points
    16 393

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    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
    On dit "chiffrer" pas "crypter" !

    On dit "bibliothèque" pas "librairie" !

    Ma page DVP : http://neckara.developpez.com/

  2. #102
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 889
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 889
    Points : 7 343
    Points
    7 343

    Par défaut

    Citation Envoyé par Neckara Voir le message
    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.

  3. #103
    Membre expérimenté
    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2007
    Messages
    763
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : février 2007
    Messages : 763
    Points : 1 342
    Points
    1 342

    Par défaut

    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

  4. #104
    Membre éprouvé
    Avatar de EpiTouille
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2009
    Messages
    371
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mai 2009
    Messages : 371
    Points : 911
    Points
    911

    Par défaut

    Citation Envoyé par Uther Voir le message
    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.

  5. #105
    Membre expérimenté
    Avatar de popo
    Homme Profil pro
    Analyste programmeur Delphi / C#
    Inscrit en
    mars 2005
    Messages
    1 027
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Analyste programmeur Delphi / C#
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2005
    Messages : 1 027
    Points : 1 599
    Points
    1 599

    Par défaut

    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.

  6. #106
    Membre averti Avatar de LapinGarou
    Homme Profil pro
    Developer R&D
    Inscrit en
    octobre 2005
    Messages
    327
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Developer R&D
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : octobre 2005
    Messages : 327
    Points : 423
    Points
    423

    Par défaut

    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# ?

Discussions similaires

  1. Quels sont les langages de programmation que vous détestez le plus, et pourquoi ?
    Par Siguillaume dans le forum Langages de programmation
    Réponses: 214
    Dernier message: 31/08/2017, 11h38
  2. Sondage : quels sont les langages de programmation que vous maîtrisez ?
    Par Michael Guilloux dans le forum Débats sur le développement - Le Best Of
    Réponses: 81
    Dernier message: 27/03/2017, 10h33
  3. Réponses: 1
    Dernier message: 10/12/2015, 13h48
  4. Les langages de programmation que vous détestez
    Par Neuromancien2 dans le forum Débats sur le développement - Le Best Of
    Réponses: 385
    Dernier message: 13/05/2011, 09h46

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo