Tamadadoo a écrit :



@HarmattanBlow 13:50 Euh, et sinon ça va la hargne, serait pas temps d’arrêter le café ?



En effet, Chez JetBrains, ils savent bien faire les choses, j’ai d’ailleurs ma licence PhpStorm (webstorm +php)



Je n’ignore rien du tout, je ne partais simplement pas dans le développement d’un argumentaire car c’était pas mon propos.

Je

vous donne raison sur une chose, mon propos faisait lui-même la

démonstration d’une certaine suffisance en stigmatisant celle de mes

“adversaires” .  



Et non je ne suis pas conscient des problèmes

du typage dynamiques, j’ai appris à faire du vélo sans les roulettes,







Mais visiblement tu ne semble pas conscient des problèmes que cela pose aussi bien techniquement(les compilateurs ne savent pas bien optimiser ça) que d’un point de vue maintenabilité du code.





alors non j’ai pas trop de soucis. (ceci est une pique gratuite)

Je sais me servir convenablement

et sans abus du prototypage, et sans limite du pattern module,  je sais

avoir recours à un ensemble plutôt solide d’outils pas pourri du tout (mon

IDE, mocha, l’écosystème et la structure mise en avant par

nodejs et son packager npm, sails, ember, …)

Je ne pense pas qu’une bonne code convention va sans un

minimum de commentaires surtout en entrée de définitions

d’objets/modules/fonctions

 

Le fait est , c’est vrai, que JS est moins

facile d’accès qu’il ne semble de prime abord. Il vient comme une flopée de pelotes de laine dans une grande boite et c’est très vite facile de faire un gros spaghetti en croyant qu’on sait tricoter. A contrario d’autres langages plébiscités par les “typeurs” viennent plus souvent avec une norme et des conventions plus stricte, ne serait-ce que par les écosystèmes qui leur sont presque indissociables (.Net, J2SE/J2EE/Spring …  )

 Pour commencer à le maitriser soit on

s’enferme dans le confort de  librairies (Jquery) ou de framework

en vogue (angular, ember) soit on décide de comprendre les rouages (cf

le bouquin du mec qui a pondu jquery et dont la seconde édition

reviendra sur les les changements de ES6+) .





Malheureusement, on trouvera toujours plus de stagiaires qui font n’importe quoi que de bons programmeurs qui maîtrisent leur métier.



Un dérivé de la loi de murphy prédit que quand un langage permet de faire facilement n’importe quoi, c’est presque toujours ce qui arrivera.





Je dois l’avouer je préfère un langage en mouvement (ça bouillonne dans la galaxie nodejs et puis ES6+) qu’être sur des rails.





On appelle cela la mode.



L’inconvénient d’utiliser une technologie juste parce qu’il y a du buzz autour, c’est le risque de passer à côté des vraies questions essentielles.



Par exemple, de vous demander si le paradigme sur lequel repose nodejs ne serait pas une erreur fondamentale.



Un bon conseil de vieil informaticien : à votre place, je consulterais les discussions et débats de spécialistes en comprenant bien ce que chacun dit avant d’investir beaucoup de temps dans quelque chose.

gokudomatic a écrit :



Un vrai langage de programmation est horriblement compliqué à utiliser, très proche de la machine, qui n’offre aucune protection ni avertissement en cas d’erreur grave, et où il faut réinventer la pierre pour réinventer la roue. Le vrai langage de programmation n’est pas un outil pour faire des programmes, car le langage est déjà un but en soi (programmer pour programmer). Tout est fait pour qu’il soit inaccessible au commun des mortels.







Ou pas…

gokudomatic a écrit :



Quand on recommande l’assembleur comme vrai langage, c’est qu’on est un gros élitiste qui aime bien se compliquer la vie pour se vanter.







Toi, tu n’as pas compris. " />



Personne n’a jamais recommandé l’assembleur pour programmer tous les jours sauf cas particulier de certaines branches de l’embarqué.



L’assembleur, c’est juste un truc qu’il est utile d’apprendre pour mieux comprends les mécanismes d’un langage évolué. Et par ce moyen, d’améliorer sa compréhension du fonctionnement des langages, des outils de programmation et des machines…. pour au final mieux programmer.



Et c’est justement très utile pour appréhender ce débat sur les problèmes d’optimisation posés par certains langages.



Sinon, pour le côté élitiste, je trouve cela très surfait. L’assembleur est plus simple à comprendre que certains ne l’imaginent.



Et au passage, cela fait toujours partie du programme dans les bonnes écoles d’informatique.

saladiste a écrit :



Euh l’assembleur est le langage de programmation le plus facile qui existe.







Clairement.



Au pire, ça peut être fastidieux au quotidien ou si l’on veut faire des choses complexes. C’est pour cela qu’on a inventé les langages de haut niveau.



Mais l’assembleur, a la base ça n’est vraiment pas compliqué.

megabigbug a écrit :



Je me suis mal exprimé mais en disant “vrais langages de programmation” au pluriel je sous entendais qu’on va pouvoir programmer avec des langages compilés en webassembly. Pas qu’on allait programmer en webassembly directement ce qui serait pour le coup assez pénible.

Et par "vrais" langages je voulais bien sûr parler de langages qui ne sont pas transcompilés dans un langage pourri comme javascript où      


 0  ==  '' est égale à vrai.

C’est clair. Parce que compiler du C/C++ en javascript, la je crois qu’on touche le fond…

yellowiscool a écrit :



J’ai étudié l’histoire des langages de programmation, la compilation, leur fonctionnement interne. Merci de m’expliquer quelles sont les erreurs à ne pas commetre, et de me dire quel est le langage qui répond aux problèmes pour lesquels JavaScript est actuellement utilisé.







Pour résumer simplement, typage dynamique et langage orienté prototype, ce n’est pas compilable de manière efficiente.



Partant de la, et sachant que c’est aussi un inconvénient majeur en terme de maintenabilité, le reste est facile à déduire.





Sinon mon CPU coûte peut-être plus cher que le revenu annuel de beaucoup d’humains, mais c’est mon outil de travail, et ramené à mon niveau de vie et à mon coût horaire, il vaut mieux en avoir 25 (horizontal scaling, la loi de moore on s’en fout) au lieu que je perde mon temps à gérer manuellement des problèmes réglés depuis des dizaines d’années avec les langages à haut niveau.





Ce raisonnement n’est valable que pour les petit projets.



Dès qu’un projet devient important, le coût des serveurs économisé dépasse largement le salaire du programmeur.



Et même pour les petits projets, on commence à ne plus se moquer du temps de réponse à cause des critères SEO. Sur le marché, on voit de plus en plus de demandes pour des gens qui savent optimiser.



Le second problème, c’est que cette logique n’est pas applicable côté client. Tu ne va pas pouvoir afficher un bandeau sur ton site “pour surfer sur ce site, merci d’acheter un supercalculateur”. Et vu comment certains sites ont tendance à ramer…





Est-ce que ton débat, c’est bas-niveau vs haut-niveau ?





Non.



La programmation bas niveau et haut niveau ont leurs usages bien délimités.



Le débat, c’est d’utiliser des langages efficaces pour la programmation de haut niveau.

Tamadadoo a écrit :



+1000 , pas mieux

même si les ajouts de ES6 (notamment les “classes” … avec des guillemets car plutôt une pirouette syntaxique )

https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Classes

me laissent un peu dubitatif.

Enfin … la communauté a parlé …  “Tu l’as voulu tu l’a eu”



Pour revenir sur notre petit contentieux (vloz,sr17,harmatanblow, moi )

Somme toute c’est l’éternel débat de “chacun sa vérité”, en rapport à son contexte ou ses influences.

Ainsi chacun peut considérer que l’autre s’est fait brainwashé par l’un ou l’autre gourou, ou philosophie d’entreprise, ou paradigme tout puissant.  

On atteindra pas l’ultime vérité aujourd’hui. :-)







Pour ma part, j’ai tendance à penser que la vérité simple et unique n’existe pas. C’est précisément pour cette raison qu’il est intéressant d’échanger des points de vue.





@sr17 : Et le paradigme et les galaxies interminables de sous-projet de java ? à comparer avec l’effort nodejs ?





Bien que Java ait quelques qualités qui manquent à Javascript, ce langage et son framework possèdent de nombreuses tares. Et bien souvent, on constate que cela donne des projets bordéliques.



Même s’il faut reconnaître que c’est un langage plus efficient que Javascript, je pense qu’il ne faudrait pas reprendre ce modèle tel quel.





En matière d’IT, nier que cette vérité est toujours fonction d’évolutions et d’expérimentation, c’est un peu nier le vent. Dans ces évolutions/expérimentations, il y aura des buzz , bons et moins bons.

ça devrait étonner qui que les technologies du web, et des apps mobiles, se cherchent encore ?

Et puis c’est la dynamique du marché que de vouloir être de ceux qui apportent les bonnes réponses.





Peut être justement qu’elles se chercheraient beaucoup moins si on acceptait de jeter à la poubelle les pis-aller fabriqués sur un coin de table a une époque pour servir des buts modestes afin de reconcevoir en partant de zéro des choses efficientes avec ce que l’expérience de la science informatique peut imaginer de de mieux.



Mais aujourd’hui, il y a cette espèce de logique commerciale omniprésente qui tends à prolonger la vie de tout ce qui est médiocre. Le raisonnement commercial est simple et se base sur le nombre d’utilisateur.



Quelque chose qui est merdique mais qui est utilisé tends à devenir encore plus merdique et encore plus utilisé. C’est un peu comme l’entropie de l’univers.

Ce qui me fait bien marrer dans la période actuelle, c’est cette prolifération des langages. Tout le monde veut faire le sien. Ca grouille de partout comme des champignons.



Et si encore c’était pour faire de bonnes choses. Malheureusement, tous ces langages sont aussi imparfaits, peu performants et mal fichus.



Quand je vois un site web moderne, je suis plié de rire. Des kilos de CSS, de montagnes de frameworks empilés… juste pour quelques images et bouts de texte. Parfois des animations minables.



Et c’est tellement lourd qu’il faut une puissance CPU démente juste pour afficher une simple page de texte.



Avec une machine dotée d’un petit CPU et de faibles ressources en RAM, il est impossible de surfer convenablement sur cet “internet pour les riches”…



Je prévoit d’avance que quelques uns vont se marrer en lisant mon post en pensant que je suis un vieux con.



Mais je prédit que vous rigolerez moins dans quelques années quand vous devrez apprendre votre 256ième langage de script bidon qui-viens-de-sortir juste pour faire des trucs minables et coller à la mode du moment.



Vous comprendrez alors l’intérêt d’un langage performant, unifié, bien pensé dès le départ et qui ne change pas toutes les 3 semaines.

CryoGen a écrit :



Tu n’as pas tout à fait tort. Celà dit, pour vivre moi même au Mali, le principal problème n’est absolument pas la puissance mais le débit, puis la mémoire.

Je ne veux pas faire de généralité mais voilà pour mon expérience :)







Le problème du débit et de la mémoire sont aussi et directement lié a la façon dont les pages web sont conçues.



Concernant les machines, si je me base sur les données de cette page, je conclu que le salaire mensuel au mali serait à peu près de l’ordre de 55\(.



Même si mon raisonnement est peut être naïf (je ne demande qu'a apprendre), je pense qu'il est plus facile d'informatiser ces pays en utilisant cela :https://www.adafruit.com/products/2885 qu'un mac book pro à 2000\)….





C’est vrai que les framework js deviennent “gros” mais les images design/contenu et surtout les pubs sont bien plus néfastes que l’exécution du JS en réalité. D’autant plus vrai à l’époque du Flash.





Justement, le problème c’est qu’a cause du manque d’optimisation de l’ensemble navigateur-langage, il faut beaucoup de puissance pour des effets relativement minables. Et HTML 5 n’est pas plus rapide que Flash, c’est même plutôt le contraire.

goldbergg a écrit :



L’inférence de type (qui dans bien des cas améliore grandement la lisibilité) ne permet pas non plus de connaitre le type d’une variable déclaré et pourtant on est dans le cas de typage fort.







L’inférence de type a effectivement des limites.





Et rien n’empêche de  mètre un commentaire sur le type a chaque déclaration:

 var maChaine;//String 

 var maDate;//Date





Certes, mais qui le fera ?



Et quitte à donner des types, autant que cela puisse aider aussi le compilateur à optimiser et repérer les erreurs.

 



voir a appliquer une valeur par défaut des la déclaration:

var maChaine =“”; (maChaine est de type String)

var maFunc =new LaFunc(); (maFunc est de type LaFunc)

(mais bon se cas là peut être problématique)



Et pour les function : function Addition(a/number/, b /number/){}

 

Bref, vue que dans les bonne pratique, “une varriable == un usage == un type”, en appliquant certain convention on peut facilement avoir une code lisible et maintenable et surtout sans avoir a passé par une surcouche comme TS.





Sauf que c’est beaucoup moins lisible que dans un langage fortement typé.



Et comme dit plus haut, le problème, c’est que ces indications n’aident pas le compilateur.



Et quand bien même tu décidera toi de coder ainsi, le problème de la documentation d’un code se pose surtout quand on reprends le code des autres.

saladiste a écrit :



Pas seulement, quand je reprends un code vieux de plus de 6 mois, j’avoue avoir un peu de mal, si en plus j’oublie de le documenter, autant le réécrire…







C’est très vrai…. et plus on avance en age, plus on oublie vite.



Mais le problème dépends aussi du langage. Par exemple, en C/C++, même avec du code qui n’est pas spécialement documenté, on arrive à comprendre sans trop d’effort ce qu’on avait écrit plusieurs années auparavant.







goldbergg a écrit :



Bin, pour qui code tous seul dans son coin pour sa pomme, certe il fera bien se qu’il veut, mais dans une entreprise il y a (normalement) des convention, convention qui peuvent être d’utiliser la JSDocpar exemple.



 Et je parle d’entreprise, mais tous bon dev devrais faire attention a sa façon de coder si il veut produire un code de qualité et je trouve sa moyen d’accuser le langage quand c’est le dev qui code comme un porc…







En général, les problème arrivent surtout quand on doit reprendre le code d’une autre entreprise.



Dans la pratique beaucoup d’entreprises ne veulent pas qu’un concurrent puisse reprendre facilement leur code. Elles feront tout pour qu’il soit le moins lisible et le moins documenté possible. Inutile de dire qu’un langage comme Javascript leur facilite énormément la tâche.





Aprés je vois pas pourquoi tu parle du compilo, que les variable sois typé dynamiquement n’empêche pas qu’elle sois belle et bien typé des qu’une valeur leurs est attribué.





Oui, bien sûr qu’elles sont typées a partir du moment ou on les utilise. Mais le typage dynamique est géré à l’exécution(et non à la compilation), ce qui est très lourd. C’est une question de traitement interne.



Par exemple, voila comme un langage à typage dynamique(PHP) stocke ses variables :



http://blog.ircmaxell.com/2012/03/phps-source-code-for-php-developers_21.html



Non seulement cela prends beaucoup de place en mémoire, c’est lourd à gérer, mais en plus, à chaque utilisation de la variable, le langage doit effectuer des tests pour savoir comment il devra traiter cette variable (en fonction de son type réel).



Les petits malins répondront qu’un excellent compilateur (comme le sont les dernières machines d’exécution Javascript) serait en mesure d’optimiser cela en déduisant le type à la compilation pour le transformer en typage statique.



Hélas, dans la pratique, hormis les cas simple (exemple : variable assignée localement par une constante), il extrêmement difficile d’être certain à 100% du type d’une variable au stade de la compilation. C’est ce genre de détail qui rends l’optimisation d’un langage tel que Javascript particulièrement difficile.



Et si encore c’était la seule difficulté, mais il y a bien d’autres difficultés comme par exemple l’orientation prototype du modèle objet.