Discussion :

[Chauve souris]

le langage assembleur en lui-même n'est pas prohibé ; dans Visual Studio en C/C++ je peux faire de l'assembleur inline grâce à asm{}
Ce qui est prohibé ce sont les interruptions avec l'instruction assembleur INT

OK, j'ai compris ! En tout cas, dans les langages de Visual Studio, je n'y ai jamais vu un macro assembleur comme au temps emmaissedossiens de Borland.

[popo]

Personnellement, le pire langage que j'ai pratiqué c'est le javascript. Encore un, je sais.
Pour les raisons, je crois que Sve@r en a fait un bon résumé.
Sinon, l'absence de typage fort est un frein considérable pour moi.
Si ce n'était que cela, rien n'empêche dans une variable de mettre une chaine dans une ligne et un entier dans l'autre, c'est perturbant.
Rien n'empêche des les d'additionner non plus.
Dans un tout autre registre, je préfère largement un code compilé plutôt qu'un code interprété.
Lorsque tu fait une erreur, tu ne le sais qu'au moment de l'exécution et encore il faut avoir un bon outil pour voir où est réellement l'erreur.
J'ai un gars au boulot qui adore le javascript. C'est super puissant et très simple selon lui.
Un jour, je lui ai lancé le défi de réaliser une tâche (routinière pour lui) sans toutes ses librairies.
Il m'a dit que ça lui prendrai seulement une petite demi-heure de plus.
Il a passé tout l'après-midi dessus et n'a pas réussi.
Bref tout ça pour dire que le javascript pur n'est pas aussi plaisant qu'on le croit.

Y'a juste Python, impossible à me faire à cette foutu syntaxe basée sur l'indentation. Je trouve ça illisible...

hotcryx a répondu à ça et je suis et je suis entièrement d'accord. L'indentation de python, c'est justement ce qui est appréciable.
Je ne l'ai pas mis dans les choix car bien qu'il ne soit pas typé et qu'il soit interprété, il est beaucoup plus complet que JS de manière native (sans tout plein de librairies).
On a pas la possibilité d'effectuer des opération contre nature comme additionner une chaine et un booléen.

Par contre j'ai mis Java.
Il est fortement typé et j'adore ça. Et il est compilé ce que j'apprécie également beaucoup.
Ce que je lui reproche, c'est ça complexité.
- Certes, c'est très documenté. Mais c'est le fouillis complet (c'était en 2006 et je l'ai fui comme la peste depuis, ça a peut-être changé depuis).
- Certes, il est cross-plateforme avec le même code (c'est ce qu'on m'a dit, je ne l'ai pas vérifié) mais la moindre opération basique avec d'autres langage prends un temps fou à coder.
OK, il existe de nombreuses librairies simplifiant les choses mais encore une fois, multiplier les librairies n'est pas une solution pour moi.
Eclipse est également complexe à maitriser.

Mon langage de prédilection serait le Delphi.
Outre la gestion des chaîne un peu bizarre, il est forment typé, permet de faire de la POO sans trop de difficultés et il est compilé.
Il n'est pas nécessaire de faire appel à des librairies pour réaliser en très peu de temps des opérations basique puisqu'il est assez complet.

Mon langage préféré serait le C#.
C'est le même gars qui a créée Delphi et C# et ça se ressent.
Il a d'ailleurs réglé tous les petit défauts que je trouvais à Delphi.

[Aizen64]

Alors si il y a un système de classe qui a été introduit dans la dernière version de la norme. Mais bon comme il faut gérer la compatibilité avec l'existant, ça reste une surcouche au système de prototype.


Alors le fait que la bibliothèque standard soit légère a aussi des avantages. Ça permet notamment de s'éviter un héritage trop lourd que l'on ne peut plus faire évoluer à cause de la compatibilité. Une maxime bien connue de la communauté Phyton est que la bibliothèque standard est là ou les modules vont mourir.

Point par point :
- oui, créer des classes est possible en 2017, cela étant, ce n'est pas tout à fait réalisable du fait que tous les navigateurs ne le prennent pas tous en charge et que tous les utilisateurs ne gardent pas à jour leur navigateur.

- effectivement, avoir une blibliothèque standard légère pour un navigateur porte son sens. Difficile de demander à des utilisateurs de télécharger 300 Mo pour un navigateur pour qu'il contienne une bibliothèque standard.

Ce qui ne m'inspire pas confiance avec JS au delà du langage, vient du fait que je ne saisis pas trop quelle est la structure de l'objet que je manipule et donc ses propriétés/méthodes, ses frameworks qui poussent comme des champignons, des outils comme Webpack qui sont très utiles mais qui consomme beaucoup de CPU pour compiler du JS/CSS à la volée avec son nombre incalculable de dépendances.

Autre exemple, Angular, quel est le rythme des MAJ majeures ? 6 mois ? En matière de pérennité c'est discutable non ?

[Sve@r]

Résumé intéressant, en plus des problèmes pour savoir sur quel élément on travaille. Je te le pique !

[EpiTouille]

Alors pour le javascript, il faudrait nuancer. Parce que maintenant, quand on dit "javascript", on parle souvent d'es6 voir es7, et plus de d'es5.

Ce qui ne m'inspire pas confiance avec JS au delà du langage, vient du fait que je ne saisis pas trop quelle est la structure de l'objet que je manipule et donc ses propriétés/méthodes, ses frameworks qui poussent comme des champignons, des outils comme Webpack qui sont très utiles mais qui consomme beaucoup de CPU pour compiler du JS/CSS à la volée avec son nombre incalculable de dépendances.

Webpack ne compile pas à la volée, et n'inclue pas de dépendances. Il "bundle" ton code javascript. C'est le développeur qui inclue des dépendances, et forcément webpack les inclues pour que ça puisse fonctionner. Pareil, webpack ne compile pas du CSS. Par contre, il a un système de plugin très complet qui permet d'étendre les fonctionnalitées (genre transpiler du scss vers du css, transpiler du ES6 vers ES5 etc...). Chaque developpeur choisit ce qu'il veut faire ou pas, mais c'est surement pas de la faute de webpack quand les gens ont des output à 20Mo.

[Uther]

Alors pour le javascript, il faudrait nuancer. Parce que maintenant, quand on dit "javascript", on parle souvent d'es6 voir es7, et plus de d'es5.

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.

[Aizen64]

@Uther oui, le côté ultra dynaique de JS est pour moi un problème.
Le nombre de fois où je me pose des questions sur les méthodes d'un objet que l'utilise, s'il est instancié ou non, s'il est accessible dans la portée actuelle.

Y a t-il vraiment des gens qui apprécient vraiment le langage ? JS c'est une malédiction plutôt, un langage dont tout le monde est d'accord pour dire qu'il n'a pas été très bien conçu mais dont personne ne peut se passer pour du web. Personne, il est donc, malgré ses défauts, incontournable.

J'irai même dire que je préfère utiliser PHP, avec un framework et des espaces de noms/autoload/PHPDoc pour de l'autocomplétition. J'admet choisir la facilité et ne pas hésiter à utiliser des points d'arrêts.

[melka one]

@Uther oui, le côté ultra dynaique de JS est pour moi un problème.
Le nombre de fois où je me pose des questions sur les méthodes d'un objet que l'utilise, s'il est instancié ou non, s'il est accessible dans la portée actuelle.

sa resemble plus a un probleme de compréhention du garbage collector

[foetus]

sa resemble plus a un probleme de compréhention du garbage collector

Non, il a raison .

Même la notion de "this" est dynamique : c'est soit l'objet courant soit le gros objet global (window pour les navigateurs)
Et en plus, lorsque tu fais une référence de méthode, JS se troue totalement sur le "this" et le dév. peut corriger l'erreur en utilisant les méthodes "call"/ "apply"/ "bind".

Mais bon les experts JavaScript n'arrêtent pas de me dire "il faut connaitre un langage pour l'utiliser et tout cela c'est normal".
Pas si normal que cela parce que JavaScript est quand même le seul langage avec ces spécificités (on peut rajouter la notion de portée fonction, la notion de chaîne de prototypes et que c'est au dév. de devoir la parcourir pour savoir si c'est la classe mère si c'est la classe fille. Même isPrototypeOf et/ ou instanceof se troue sur certains cas)
Et ce n'est pas normal non plus que la nouvelle version du langage ES6-ES7 et ces implémentations (typescript par exemple) cachent toutes les "spécificités de JavaScript " sous une couche langage qu'on retrouve dans les autres langages (notion de classe, notion de bloc) voire même encourage l'abandon de certaines "spécificités" (par exemple le mot clef var au profit de let et __proto__)

[Madmac]

En premier Java. Je crois que les inventeurs de ce langage prenaient des paries pour savoir savoir qui inventerait la méthode et la classe avec le le plus de caractères. Un langage idéal pour les tendinites.

PHP, le langage plus inconstant qu'il existe. Ils essaient de corriger le coup en copiant les classes de Ruby en PHP. Malheureusement en programmation-objet, le gain de vitesse qui attiraient les gens disparaît.

[foetus]

Moi, c'est le C++ moderne (C+11, C+14, C+17, C++19, ...)

Pour l'instant je n'y arrive pas à m'y mettre

C'est vrai que le C++03 était relativement simple à apprendre, mais dangereux (mais c'est sa force et l'héritage du C), difficile à coder correctement et qu'on avait tendance à se concentrer sur le comment faire au lieu du "ce qu'il faut faire.

Mais le C++ moderne a désambiguifié tout cela et à tout surcharger : on passe du big 3 au big 5, on a maintenant 4 ou 5 pointeurs intelligents, ....
J'ai l'impression que maintenant on se prend la tête sur la possession/ l'appartenance et si on fait une copie profonde ou pas.

Et en plus, on a pléthore d'outils mais il faut savoir les utiliser . Par exemple, les pointeurs intelligents partagés restent quand même des pointeurs avec un compteur (et donc on retombe sur toutes les critiques qui ont commencé avec les objets COM en 1996-1997).

L'autre truc, ce sont les templates. Depuis Boost (2005, il me semble) je n'arrive pas à programmer avec les techniques de calcul/ d'optimisation lors de la compilation (traits, templates partielles, ...). Les grands gourous C++ raffolent de cela et le C++ moderne ce n'est que cela.
Le peu de j'ai essayé d'en coder, j'ai une impression d'une double conception : une première fois pour faire du code spécifique et une deuxième fois avec une généralisation et des templates

Et enfin, il y a les promesses non tenues : un remplaçant aux macros, un remplaçant au include, le fameux export des templates que personne ne veut. Certains trucs vont arriver en 2022.

Et pour finir, il y a un éloignement avec le C : programmation défensive avec les exceptions/ RAII, programmation service (on utilise des objets dont la seule chose qu'on sait c'est ce qu'ils font. R.A.F. du comment), les trucs modernes (fermetures/ closures, fonctions anonymes/ lambdas, ...), et j'ai vu passer la programmation par contrat.


Et pour troller , pourquoi faire 5 - 6 versions, c'était trop compliqué d'en faire 2 versions complètes (le C++11 est déjà obsolète)

[LSMetag]

Moi, c'est le C++ moderne (C+11, C+14, C+17, C++19, ...)

Pour l'instant je n'y arrive pas à m'y mettre

C'est vrai que le C++03 était relativement simple à apprendre, mais dangereux (mais c'est sa force et l'héritage du C), difficile à coder correctement et qu'on avait tendance à se concentrer sur le comment faire au lieu du "ce qu'il faut faire.

Mais le C++ moderne a désambiguifié tout cela et à tout surcharger : on passe du big 3 au big 5, on a maintenant 4 ou 5 pointeurs intelligents, ....
J'ai l'impression que maintenant on se prend la tête sur la possession/ l'appartenance et si on fait une copie profonde ou pas.

Et en plus, on a pléthore d'outils mais il faut savoir les utiliser . Par exemple, les pointeurs intelligents partagés restent quand même des pointeurs avec un compteur (et donc on retombe sur toutes les critiques qui ont commencé avec les objets COM en 1996-1997).

L'autre truc, ce sont les templates. Depuis Boost (2005, il me semble) je n'arrive pas à programmer avec les techniques de calcul/ d'optimisation lors de la compilation (traits, templates partielles, ...). Les grands gourous C++ raffolent de cela et le C++ moderne ce n'est que cela.
Le peu de j'ai essayé d'en coder, j'ai une impression d'une double conception : une première fois pour faire du code spécifique et une deuxième fois avec une généralisation et des templates

Et enfin, il y a les promesses non tenues : un remplaçant aux macros, un remplaçant au include, le fameux export des templates que personne ne veut. Certains trucs vont arriver en 2022.

Et pour finir, il y a un éloignement avec le C : programmation défensive avec les exceptions/ RAII, programmation service (on utilise des objets dont la seule chose qu'on sait c'est ce qu'ils font. R.A.F. du comment), les trucs modernes (fermetures/ closures, fonctions anonymes/ lambdas, ...), et j'ai vu passer la programmation par contrat.


Et pour troller , pourquoi faire 5 - 6 versions, c'était trop compliqué d'en faire 2 versions complètes (le C++11 est déjà obsolète)

En gros ton problème est plus un problème de migration vers quelque chose qui s'éloigne du C, que de désaffection/désaveux du langage proprement dit.

[gerard093]

Tout sondage induit un biais de sélection.

Ce biais existe parce que les sondés ne répondent pas à un sondage de façon aléatoire, mais en fonction de leur motivation et de la façon dont ils ont été contactés.

Bref, les populations sondées par un sondage 'positif' ne sont pas le mêmes que celles sondées par un sondage négatif.

Par ailleurs, dans l'expression des réponses, il faut tenir compte des taux de pénétration (ou d'utilisation) de chaque langage, puisqu'un langage plus utilisé engendre plus de réponses.

Il faut donc 'redresser' les résultats de sondage pour pouvoir les interpréter. C'est une opération complexe.

Les résultats de sondage bruts sont généralement faux, les résultats corrigés discutables. Certains disent qu'on fait dire au sondage ce qu'on veut ce qui n'est pas faux. En fait, tout langage a son utilité à condition d'être utilisé dans l'esprit dans lequel il a été créé. Et tout sondage est élaboré pour devenir instrument d'influence...

Et l'aversion pour un langage est l'aversion contre l'architecte qui s'est planté sur le choix du langage dès la naissance du projet. L'aversion est d'autant plus grande que l'architecte est plus obstiné, imbus de sa supériorité, et très con. Pensez aux méthodes Agiles ... et soyez plus souple en terme de standard ... à réfléchir ...

[Uther]

Tout sondage induit un biais de sélection.

Oui, faire un sondage en mettant tout les langages au même niveau n'a clairement pas de sens. Une façon bien meilleure (quoique pas parfaite non plus) de sonder sur le sujet aurait été de faire un sondage individuel par langage pour connaitre son niveau d’appréciation. C'est ce que fait Stackoverflow dans son enquête annuelle :
https://insights.stackoverflow.com/s...nted-languages

Et l'aversion pour un langage est l'aversion contre l'architecte qui s'est planté sur le choix du langage dès la naissance du projet.

Ça peut être le cas mais j'ai rarement eu à faire à ce cas. La plupart des architectes savent ce qu'ils font. Le plus souvent, quand on se retrouve à utiliser un langage non souhaité, c'est à cause de l’environnement ciblé qui ne laisse pas le choix.

Personnellement mes deux votes : JavaScript et VBA sont deux langages que j'ai du utiliser par obligation parce qu'il n'y a pas d'alternative simple. Et si j'avais dû développer sur iOS, j'aurais probablement rajouté Objective-C car c'est un langage qui, du peu que j'en ai vu, ne me plait pas vraiment, mais que je n'ai pas eu à subir assez pour le détester.

[Watilin]

Coucou,

j’ai pas lu tout le fil et c’est certain que j’ai raté des trucs, mais j’aimerais réagir sur deux-trois trucs qui ont été dits à propos de JavaScript.

Pour commencer, j’aime JavaScript et je ne le cache pas. Et la raison pour laquelle j’aime ce langage, c’est parce que je le connais bien. Je connais ses pièges, je sais comment les éviter et, grâce à cette expérience, j’ai accès à l’essence du langage, à ce qu’on peut faire de plus beau avec. Bien sûr ce n’est pas objectif. Mais c’est là où je veux en venir : je pense que quand on connaît un minimum un langage, on l’apprécie forcément.

Tous les langages ont des défauts. Mais tous les langages évoluent, et voient petit à petit leurs défauts corrigés avec les nouvelles versions. Parfois de nouveaux défauts apparaissent, c’est comme ça, mais globalement, un langage correctement maintenu est en accord avec les tendances du moment.
Les langages du Web (JS et PHP ont été beaucoup cités) ne bénéficient pas de cet avantage, à cause de la nécessité de rétro-compatibilité imposée par le Web. JS est le plus touché car il est côté client, et on n’a aucun contrôle sur la plateforme cliente. Du coup, il se traîne des défauts qui datent de l’époque de sa conception, et qui ne peuvent pas être corrigés parce que des sites reposent dessus aujourd’hui encore. Ajoutez à cet argument l’abondance de docs obsolètes et parfois simplement fausses qui rendent l’apprentissage du langage difficile, et vous avez, à mon avis, la principale raison pour laquelle ce langage est tant detesté.

Pour rejoindre mon argument précédent, je pense aussi que les gens qui n’aiment JS ne le connaissent pas suffisamment, par exemple ne sont pas au courant de la rapide évolution qu’a connu le langage ces dernières années, ainsi que l’admirable effort d’adaptation des navigateurs. La dure concurrence entre Mozilla et Google pour optimiser leurs moteurs (resp. Spidermonkey et V8) y est pour quelque chose ; l’essor du JS côté serveur également. Mais pour savoir ça, il faut se tenir au courant, et on n’a pas envie de se tenir au courant sur un langage qu’on n’aime pas, c’est compréhensible.

[Invité]

Pour rejoindre mon argument précédent, je pense aussi que les gens qui n’aiment JS ne le connaissent pas suffisamment, par exemple ne sont pas au courant de la rapide évolution qu’a connu le langage ces dernières années, ainsi que l’admirable effort d’adaptation des navigateurs. La dure concurrence entre Mozilla et Google pour optimiser leurs moteurs (resp. Spidermonkey et V8) y est pour quelque chose ; l’essor du JS côté serveur également. Mais pour savoir ça, il faut se tenir au courant, et on n’a pas envie de se tenir au courant sur un langage qu’on n’aime pas, c’est compréhensible.

Je travaille avec Javascript depuis pas mal de temps, et, pour le boulot, NodeJS, et je liste donc toutes les raisons pour lesquelles je déteste, je méprise profondément ce langage:

- Syntaxe inconsistente
- Système de typage rempli de conneries incohérentes
- Callback/Promise/Async hell
- Pas d'outils stables/matures
- Pas de cohérence dans l'arrivée des standards
- Aucune cohérence dans la gestion de scope
- Enfin, qui se sépare du langage mais, pour un langage aussi faible, qui a son importance: une communauté très immature et fermée, des projets sans pérennité

Ce langage a ses intérets, ses qualités mais est encore beaucoup trop jeune, limité et mal pensé pour être un outil de travail sérieux et pérenne.
Et quand à la rétro-compatibilité, que ce soit côté client ne change rien. Si quelque chose est obsolète par question de sécurité ou maintenance, il doit arrêter d'être utilisé, pour des raisons évidentes précises à chaque situation, qui justifient déjà la dépréciation dudit outil.

[Madmac]

Moi, c'est le C++ moderne (C+11, C+14, C+17, C++19, ...)

Pour l'instant je n'y arrive pas à m'y mettre

C'est vrai que le C++03 était relativement simple à apprendre, mais dangereux (mais c'est sa force et l'héritage du C), difficile à coder correctement et qu'on avait tendance à se concentrer sur le comment faire au lieu du "ce qu'il faut faire.

Mais le C++ moderne a désambiguifié tout cela et à tout surcharger : on passe du big 3 au big 5, on a maintenant 4 ou 5 pointeurs intelligents, ....
J'ai l'impression que maintenant on se prend la tête sur la possession/ l'appartenance et si on fait une copie profonde ou pas.

Et en plus, on a pléthore d'outils mais il faut savoir les utiliser . Par exemple, les pointeurs intelligents partagés restent quand même des pointeurs avec un compteur (et donc on retombe sur toutes les critiques qui ont commencé avec les objets COM en 1996-1997).

L'autre truc, ce sont les templates. Depuis Boost (2005, il me semble) je n'arrive pas à programmer avec les techniques de calcul/ d'optimisation lors de la compilation (traits, templates partielles, ...). Les grands gourous C++ raffolent de cela et le C++ moderne ce n'est que cela.
Le peu de j'ai essayé d'en coder, j'ai une impression d'une double conception : une première fois pour faire du code spécifique et une deuxième fois avec une généralisation et des templates

Et enfin, il y a les promesses non tenues : un remplaçant aux macros, un remplaçant au include, le fameux export des templates que personne ne veut. Certains trucs vont arriver en 2022.

Et pour finir, il y a un éloignement avec le C : programmation défensive avec les exceptions/ RAII, programmation service (on utilise des objets dont la seule chose qu'on sait c'est ce qu'ils font. R.A.F. du comment), les trucs modernes (fermetures/ closures, fonctions anonymes/ lambdas, ...), et j'ai vu passer la programmation par contrat.


Et pour troller , pourquoi faire 5 - 6 versions, c'était trop compliqué d'en faire 2 versions complètes (le C++11 est déjà obsolète)

J'ai le même vertige. Mais en plus, j'ai appris que le C++ m'a donné de mauvaises habitudes.

https://fr.wikipedia.org/wiki/SOLID_(informatique)

L'héritage est une pratique à réduire au maximum, car il produit du code difficile à maintenir ou à modifier.

[Neckara]

L'héritage est une pratique à réduire au maximum, car il produit du code difficile à maintenir ou à modifier.

Pourquoi ?

Aurais-tu un exemple à nous proposer ?

[Marco46]

Je travaille avec Javascript depuis pas mal de temps, et, pour le boulot, NodeJS, [...] je méprise profondément ce langage:

[...]

Ce langage a ses intérets, ses qualités mais est encore beaucoup trop jeune, limité et mal pensé pour être un outil de travail sérieux et pérenne.

Bizarre quand même. Tu travailles avec un outil que tu ne trouves pas sérieux ni pérenne ? Tu serais pas un peu maso ?

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

Après je pense que tes arguments ne valent rien s'ils ne sont pas développés. Ya certains trucs vraiment hallucinants, comme qualifier la communauté JavaScript de fermée alors que c'est le langage le plus actif sur github et de très loin, j'ai envie de te donner l'adresse d'un bon neurologue.

[Marco46]

Aurais-tu un exemple à nous proposer ?

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