TypeScript 1.8 permet la compilation mixte avec le JavaScript

TypeScript 1.8 permet la compilation mixte avec le JavaScript

Plus besoin de convertir

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

23/02/2016 3 minutes
61

TypeScript 1.8 permet la compilation mixte avec le JavaScript

Microsoft a annoncé hier soir la version 1.8 du langage TypeScript. Les développeurs pourront notamment mixer le code avec du JavaScript, évitant la conversion de tous les fichiers.

La version 1.8 de TypeScript est disponible depuis hier soir. Lancé en octobre 2012 par Microsoft, ce langage de script se veut un superset de JavaScript, dont il reprend une partie de la syntaxe, mais en lui donnant une orientation bien spécifique : la création de gros projets.

Le langage est typé et permet de réduire fortement le nombre de lignes de code nécessaire. Anders Hejlsberg, père du C#, en est l’un de ses créateurs. Le langage est devenu assez populaire, la version 2.0 d’AngularJS (un projet de Google) étant par exemple basée sur TypeScript.

Compilation mixte TypeScript/JavaScript

Depuis sa version 1.0, le langage a bien entendu beaucoup évolué. La mouture 1.8 sortie hier apporte encore un certain nombre d’améliorations, à commencer par la prise en charge du code JavaScript dans la compilation. Pour la première fois, un développeur peut inclure un tel code dans son projet TypeScript. La raison importe peu, l’essentiel étant de pouvoir le faire, au moyen de l’argument « --allowJS » en ligne de commande.

L’idée derrière cette capacité est de permettre à un développeur de recycler par exemple ses fichiers JavaScript en cas de passage à TypeScript pour un projet plus important. Cette compilation « mixte » évite notamment la conversion d’un trop grand nombre de fichiers de JavaScript vers TypeScript, avec les erreurs que cela peut supposer. En outre, une telle compilation signifie que le développeur peut utiliser virtuellement n’importe quelle bibliothèque tierce.

Attention aux cassures dans la compatibilité

Parmi les autres nouveautés, on signalera en particulier l’amélioration de l’inférence de type pour les unions et intersections, la gestion simplifiée des types props dans React, l’ajout des string literal types pour éviter certaines erreurs lors de l’écriture de paramètres de configuration, une analyse plus « intelligente » du contrôle de flux lors de la compilation (code injoignable, retours implicites…) ou encore l’augmentation des modules.

Attention, il existe quelques changements dans cette mouture qui peuvent rompre la compatibilité, notamment dans les API du DOM et dans le parsing strict de tous les modèles, y compris quand les cibles ne sont pas de type ECMAScript 6 (ES6).

Le téléchargement de TypeScript 1.8 peut se faire de plusieurs manières différentes, mais toutes sont disponibles depuis le dépôt GitHub de Microsoft. Les développeurs pourront par exemple récupérer une version compatible avec Visual Studio 2015, sous forme de paquet NuGet ou npm.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Compilation mixte TypeScript/JavaScript

Attention aux cassures dans la compatibilité

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (61)




Le langage est devenu assez populaire, la version 2.0 d’AngularJS étant par exemple basée sur TypeScript.



J’aurai tendance à dire que c’est exclusivement grâce ça… Typescript personne ne l’utilisait il y a encore quelques mois, et depuis l’annonce du passage atScript->Typescript d’Angular t’as plein de talks qui pop de partout avec des mecs en mode “Nan mais en fait TS c’est pas mal m’voyez”… :/

 

Pour l’utiliser au quotidien faut quand meme avouer que c’est beaucoup moins avancé que dart, qu’on retrouve pas mal des probleme majeur du js, et que Microsoft investi pas beaucoup dessus: le projet a l’air vachement community-driven, le nombre tsd est à la ramasse par rapport au nombre de library traduites en Dart (ce qui est quand meme une honte quand on voit le différence de trend), et ils ont pris du retard sur babeljs concernant le support  d’es6/es7…



Bref, ça reste une bonne chose pour le petit monde du “anything-but-js”, mais je reste quand même pas mal sur ma faim… :/


J’ai du mal à comprendre,

On m’avait vendu le typescript comme un superset de js 

on m’avait expliqué que le javascript était du typescript 



Si tel était le cas, pourquoi avoir besoin du –allowJS ? 

 








vloz a écrit :



… le petit monde du “anything-but-js”, …



Parfaite petite formule,

ce qui me pèse de la part de ce petit monde ,  c’est cette arrogance du “stricly typed sinon rien” ou du “sérieux mais comment tu fais avec un langage non typé” …. gna gna gna c’est tellement mieux … blablablah .



Lisez d’abord Douglas Crockford et surtout John Resig (Secrets of the JS ninja) pour comprendre d’abord de quoi il en retourne avant de frapper JS du sceau de l’infamie, simplement parce que vous venez d’un autre scope.



Question à un utilisateur:

 e vois que le langage est compilé.

Mais en quoi ?








Tamadadoo a écrit :



… simplement parce que vous venez d’un autre scope.







<img data-src=" />



En JS :)








vloz a écrit :



J’aurai tendance à dire que c’est exclusivement grâce ça… Typescript personne ne l’utilisait il y a encore quelques mois, et depuis l’annonce du passage atScript-&gt;Typescript d’Angular t’as plein de talks qui pop de partout avec des mecs en mode “Nan mais en fait TS c’est pas mal m’voyez”… :/

 

Pour l’utiliser au quotidien faut quand meme avouer que c’est beaucoup moins avancé que dart, qu’on retrouve pas mal des probleme majeur du js, et que Microsoft investi pas beaucoup dessus: le projet a l’air vachement community-driven, le nombre tsd est à la ramasse par rapport au nombre de library traduites en Dart (ce qui est quand meme une honte quand on voit le différence de trend), et ils ont pris du retard sur babeljs concernant le support  d’es6/es7…



Bref, ça reste une bonne chose pour le petit monde du “anything-but-js”, mais je reste quand même pas mal sur ma faim… :/







Tiens moi j’avais lu (vite fait) que Angular 2 avait switcher car la communauté ne voulait pas de atScript et préférait Typescript.

Est-ce qu’on sait alors pourquoi le Dart n’a pas été choisi ?



C’est simple personne n’aime Dart comme atScript.


Oui mais atScript est abandonné donc, faut-il encore en parler ?



L’avantage de ts, c’est qu’il est plus aisé de coder des structures comme les langages c#, Java, ect…

Ca offre donc à des dev qui n’ont jamais fait bcp de js, de faire du code plus vite que d’apprendre js.



La question à se poser, c’est pourquoi Google à choisi Typescript pour angularjs 2 plutôt que son langage dart.

&nbsp;


Pour l’utiliser tous les jours c’est quand même sacrément confort par rapport à du js.



Le code compilé est plus facilement lisible que du babel, l’intégration avec VS Code / VS Studio ou SublimeText est ok et le typage est appréciable, surtout lorsque que l’on est nombreux à travailler sur un projet.&nbsp; Dans l’ensemble j’ai l’impression de gagner du temps. Utilisé avec plusieurs librairies je n’ai eu aucun problème à convertir une SPA de javacript en typescript.



Ceci dit j’aimerais bien connaitre les raisons qui ont fait qu’Angular ait switché sur TS.


il semble en effet que c’était le résultat du sondage qu’ils avaient réalisé



http://news.softpedia.com/news/angular-2-survey-shows-typescript-s-popularity-am…



&nbsp;








vloz a écrit :



‘on retrouve pas mal des probleme majeur du js





Je plussoie malheureusement.



C’est un mix entre C# et JS, avec les défauts de C# et les défauts de JS, sans tous les avantages de C# ni tous les avantages de JS.



Entre ça et JS je préfère quand même typescript pour un projet moyen-gros. Mais c’est vraiment un pis aller…







Tamadadoo a écrit :



Lisez d’abord Douglas Crockford et surtout John Resig (Secrets of the JS ninja)





On s’en fout. Tu veux convaincre les gens d’adopter le JS ? Voilà ce qu’il faut faire :



* Recommander un bon IDE (indice : webstorm).



* Montrer que tu es conscient des problèmes liés au typage dynamique et à l’interprétation en général, et à JS en particulier. Ne pas les nier ni les sous-estimer. Maintenance fragile et coûteuse, besoin de davantage de tests, de davantage de commentaires, outillage pourri, découvrabilité difficile des bibliothèques, faible modularité, processus de build fragile et alambiqué (inclusions de fichiers == fuck), tests lents, etc.



* Leur montrer les problèmes liés au typage statique (ou du moins ceux liés à de mauvais systèmes de types - comme ceux présents dans tous les langages). Verbosité, factorisabilité réduite (redondance du code), testabilité difficile (besoin d’interfaces == fuck).





A la place qu’as-tu fait ? Tu as émis une opinion, tu n’as pas fourni d’argument, tu as ignoré ceux de tes adversaires, puis tu es les as renvoyés vers un bouquin à 50$. Tout ça donne le sentiment que tu ne connais pas le problème.









CryoGen a écrit :



Tiens moi j’avais lu (vite fait) que Angular 2 avait switcher car la communauté ne voulait pas de atScript et préférait Typescript.

Est-ce qu’on sait alors pourquoi le Dart n’a pas été choisi ?





En fait si la team angular avait choisi Dart ils auraient du drop le comptabilité js parce que le code que sort Dart est inexploitable en tant que tel (on peut facilement appelé du js depuis Dart mais l’inverse c’est vraiment chaud) et ça aurait été du suicide d’abandonner JS (voir le commentaire de Tamdadoo).

&nbsp;

Ils voulaient pas non plus que ce soit dev en js pure parce qu’ils perdaient tous les avantages du typage… (et ils s’en servent &nbsp;pas mal dans angulars 2 pour raccourcir le code, parfois en faisant de la merde.)



Du coup ils ont commencés à bosser sur atScript pour pouvoir générer la bibliothèque à la fois en Dart et JS sans perdre le typage en cours de route…

Apres ils se sont rendu compte que TS faisait la meme chose mais sans les décorateurs donc ils ont dis:

“Eh! Ca serait cool d’utiliser une techno MS plutot que de créer un enieme language et puis en fait on s’est rendu compte que c’est casse couille de maintenir atScript”



Donc du coup les gens ont commencé à brailler que Google abandonnait Dart (alors que y’a toujours autant d’ingé de chez google qui bossent dessus 1an apres), surtout que le meme mois la team chrome annonçait de maniere seche qu’elle allait pas supporter la DartVM (alors qu’ils teasaient son support depuis 4 ans, et que c’etait tout proche!).



Et pour l’histoire il aura fallut attendre la sortie de la beta en decembre pour avoir TS de repertorié sur le site d’angular 2 (qui ne présentait jusqu’alors que JS et Dart)…

&nbsp;



MoonRa a écrit :



C’est simple personne n’aime Dart comme atScript.



mdr t kon



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.


Quel est ton langage performant, unifié, bien pensé dès le départ ? Ça serait bien aussi qu’il soit sécurisé, facile à déployer, facile à apprendre et à maintenir, ou tout simplement parfait ?








sr17 a écrit :



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





En ce qui me concerne tu as tout à fait raison : ces technos sont souvent bancales.



Malheureusement elles foisonnent pour répondre à des besoins bien réels et ne pas les utiliser est encore pire.









HarmattanBlow a écrit :



En ce qui me concerne tu as tout à fait raison : ces technos sont souvent bancales.



Malheureusement elles foisonnent pour répondre à des besoins bien réels et ne pas les utiliser est encore pire.







Tout à fait.



Mais on ne peut que déplorer que ce foisonnement ne soit finalement une énorme division des efforts qui n’aboutit qu’a une myriade de concepts médiocres pondus sur un coin de table plutôt qu’a quelques idées un peu travaillées.



Mais comme tu le souligne, il n’est malheureusement pas possible pour l’instant de se passer de ces technologie parce qu’elles sont imposées (browser = pas le choix du langage). La difficulté, c’est d’expliquer aux jeunes qu’il faut les utiliser de manière propre, raisonnée et à bon escient.







yellowiscool a écrit :



Quel est ton langage performant, unifié, bien pensé dès le départ ? Ça serait bien aussi qu’il soit sécurisé, facile à déployer, facile à apprendre et à maintenir, ou tout simplement parfait ?







Penses tu sincèrement qu’il soit très difficile de trouver mieux que Javascript (et ses dérivés…) ?



&nbsp;Bin y en a un sa s’appelle le JavaScript, sa fait des années que je l’utilise et il a toujours répondu a tous mes besoin, même les plus complexe ;)

Le truc c’est que pour bien l’utiliser il faut directement le considérer comme un Language Objet orienté Prototype et ne pas chercher a le rendre orienté Class…



De nos jours tous le monde veux faire du JS pour suivre la mode, mais personne ne veux se faire chier a l’apprendre vue que trop différent de la POO classique par Class, donc surcouche dégeux qui nous génère on sait pas trop quoi…&nbsp;



Si il y a un gros problème dans le monde JS de nos jours, c’est bien la mauvaise volonté de la majorité des dev qui au final ne veullent pas faire du JS!



Un gros +1 à&nbsp;sr17&nbsp;

PS: vive le Vanilla o/


Vivement que&nbsp;Webassembly&nbsp;soit finalisé et intégré aux navigateurs qu’on puisse afin programmer avec de vrais langages de programmation.


@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” . &nbsp;



Et non je ne suis pas conscient des problèmes

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

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,&nbsp; 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

&nbsp;

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 …&nbsp; )

&nbsp;Pour commencer à le maitriser soit on

s’enferme dans le confort de&nbsp; 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+) .



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.


L’ennui dans ton discours c’est que tout porte à croire que t’essaye de protéger ton patrimoine de compétences..

&nbsp;Comme les dev PHP qui te balancent “Nan mais le php c’est pas un langage bancale, c’est juste que les bon devs php sont rares” (&lt;= donc le langage est bancale, cqfd.)

Ca m’étonne que tu nous ai pas encore sorti la rhétorique du marteau et du clou (je l’aime bien celle la).

&nbsp;








sr17 a écrit :



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



Ah, c’est pas le cas? <img data-src=" />









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.









Patch a écrit :



Ah, c’est pas le cas? <img data-src=" />







Bien sûr que si <img data-src=" />









sr17 a écrit :



Penses tu sincèrement qu’il soit très difficile de trouver mieux que Javascript (et ses dérivés…) ?





Tout dépend du problème. Mais JavaScript a du succès pour de nombreuses

raisons, et plus uniquement parce que c’était le seul langage supporté

cotés navigateur web à une époque.



&nbsp;





megabigbug a écrit :



Vivement que&nbsp;Webassembly&nbsp;soit finalisé et intégré aux navigateurs qu’on puisse afin programmer avec de vrais langages de programmation.





&nbsp; C’est quoi un vrai langage de programmation? Qu’est-ce qui distingue un vrai

langage de programmation d’un faux langage de programmation ?



&nbsp;





sr17 a écrit :



les compilateurs ne savent pas bien optimiser ça





Les VMs JavaScript (V8, SpiderMonkey, Chakra) savent très bien travailler avec ça, et sont plutôt performantes. Ça consomme plus de CPU et plus de RAM qu’un algo en C, C++, Ada, Go…, mais on s’en fout complètement, dans le pire des cas “l’auto-scaling” du Cloud prestataire va couter moins cher qu’un bon développeur.



&nbsp;





sr17 a écrit :



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



&nbsp;

En attendant avec NodeJS je fais des services qui travaillent&nbsp; sur des flux, le tout&nbsp; en 100 lignes, et ça scale horizontalement par défaut. C’est peut-être une erreur, mais je crois qu’on est nombreux à la faire.









yellowiscool a écrit :



C’est quoi un vrai langage de programmation? Qu’est-ce qui distingue un vrai

langage de programmation d’un faux langage de programmation ?





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.









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…




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.








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.






 ... et/ou un troll qui balance ça sauce à chaque post qui a trait de près  ou de loin au dév, et dans lequel tout le monde décide de tomber  allègrement en balançant ses certitudes et sa petite science pour se  sentir au dessus de la mélée.      





Et au final, on aura quoi ? un énième vieux non-débat fan/hate/boys qui ne servira strictement à rien. Le simple fait de participer à ça relève de l’attitude d’un gamin de 5 ans et de sa vision caricaturale des choses, dans laquelle le monde est divisé entre les “bons” et les “méchants”, sans la moindre pondération possible.



A mon tour de faire le vieux con: il fut un temps où sur PCI, on avait des discussions de qualité.









yellowiscool a écrit :



Tout dépend du problème. Mais JavaScript a du succès pour de nombreuses

raisons, et plus uniquement parce que c’était le seul langage supporté

cotés navigateur web à une époque.







La vérité, c’est que Javascript est un petit langage de script qui a été écrit sur un coin de table. La seule raison pour laquelle il est utilisé, c’est parce qu’il s’est retrouvé intégré aux navigateurs.



Et la seule raison pour laquelle des programmeurs ont été formés à ce langage, c’est parce qu’il n’y avait pas le choix, les navigateurs imposant de fait ce langage.





C’est quoi un vrai langage de programmation? Qu’est-ce qui distingue un vrai

langage de programmation d’un faux langage de programmation ?





Je t’engage à étudier l’histoire des langages ainsi que leur fonctionnement interne pour comprendre qu’il y a des erreurs à ne pas commettre.



Ceux qui veulent réinventer la roue sans tenir compte de l’état de l’art d’un domaine sont juste condamnés à répéter les erreurs…





Les VMs JavaScript (V8, SpiderMonkey, Chakra) savent très bien travailler avec ça, et sont plutôt performantes.





Non



Il faut cesser de croire au mythe du compilateur magique.



La vérité, c’est qu’il y a énormément de choses que même le meilleur compilateur du monde ne sait pas détecter et optimiser correctement si le programmeur ne l’y aide pas.



Étudiez la compilation des langages et vous le comprendrez…





Ça consomme plus de CPU et plus de RAM qu’un algo en C, C++, Ada, Go…, mais on s’en fout complètement, dans le pire des cas “l’auto-scaling” du Cloud prestataire va couter moins cher qu’un bon développeur.





Et on voit le résultat d’années d’empilement de couches écrites par des programmeurs qui se moquent de la notion de performances. Parce que c’est malheureusement cumulatif…



Peut être ne réalisez vous pas que la moitié de l’humanité n’a pas les moyens de se payer les terminaux qu’il faudrait pour surfer sur ces pages web ultra lourdes, sans compter les serveurs pour leur propres services.



Parce que le CPU que vous avez dans votre ordinateur coûte plus cher que le salaire annuel de beaucoup d’humains.



Mais c’est votre droit d’aller dans le mur et on vous souhaite bonne chance avec la fin de la loi de moore…





En attendant avec NodeJS je fais des services qui travaillent  sur des flux, le tout  en 100 lignes, et ça scale horizontalement par défaut. C’est peut-être une erreur, mais je crois qu’on est nombreux à la faire.





Etre nombreux à avoir tort ne donne pas pour autant raison.



La facilité pratique peut être le sucre qui cache l’amertume d’une erreur conceptuelle fondamentale.



Chaque époque a vu sa mode dans laquelle se sont rués les jeunes programmeurs d’une génération.



Mais à long terme, les erreurs d’une mode éphémère ne perdurent jamais.



Chaque génération de programmeur finit par en payer le prix…









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. <img data-src=" />



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.









brazomyna a écrit :



A mon tour de faire le vieux con: il fut un temps où sur PCI, on avait des discussions de qualité.





Tu parles de l’époque du panda roux <img data-src=" /> ?









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é.



&nbsp;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ù      

&nbsp;0 &nbsp;== &nbsp;'' est égale à vrai.

&nbsp;

&nbsp;







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…









vloz a écrit :



Comme les dev PHP qui te balancent “Nan mais le php c’est pas un langage bancale, c’est juste que les bon devs php sont rares” (&lt;= donc le langage est bancale, cqfd.)







Un peu rapide comme conclusion. Sans nier les problèmes du php, il y a infiniment plus de gus qui s’improvisent dev en PHP qu’ailleurs… ce qui entraine tout un tas de conséquences menant à la “rareté” du bon dev php (le dev est élitiste…). Mais le pire tas de merde que j’ai vu ça reste du java…



Comme quoi, à faire ou non de la merde, on est certes aidé par les caractéristiques du langage, mais ça reste l’humain assit sur son trône qui décide.



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é.



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.



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








megabigbug a écrit :



&nbsp;0 &nbsp;== &nbsp;” est égale à vrai.





En même temps pour qui à un minimum cherché a comprendre le JS se résultat est tout a fait cohérent, si on veut faire un test sur le type (car oui les variable sont bien typées) avant de tester la valeur, il faut utiliser le “===”.



C’est pas le langage qui est pourri, mais les devs qui ne veulent pas se cassé le cul a apprendre a l’utiliser…

(je précise au cas où que mon langage favori est le C# et non le JS, je ne cherche donc pas particulièrement à le&nbsp;défendre)

&nbsp;









sr17 a écrit :



Peut être ne réalisez vous pas que la moitié de l’humanité n’a pas les moyens de se payer les terminaux qu’il faudrait pour surfer sur ces pages web ultra lourdes, sans compter les serveurs pour leur propres services.



Parce que le CPU que vous avez dans votre ordinateur coûte plus cher que le salaire annuel de beaucoup d’humains.



Mais c’est votre droit d’aller dans le mur et on vous souhaite bonne chance avec la fin de la loi de moore…







Oui enfin les développement lourd en javascript coté client ne concernent que très rarement les sites web publics et encore dans ce cas là c’est une erreur de choix effectivement.



Ceux qui n’ont pas les moyens d’avoir la puissance nécessaire, non de toutes manières pas internet non plus… Et enfin sous prétexte que des gens vivent plus mal que nous, le JS devient une merde ?



Ton discours est plutôt sensé d’habitude, tu nous fais quoi là ? <img data-src=" />









goldbergg a écrit :



C’est pas le langage qui est pourri, mais les devs qui ne veulent pas se cassé le cul a apprendre a l’utiliser



   &nbsp;





Globalement, oui.




  Ca n'empêche pas que certaines parties dudit langage sont basés sur des choix malheureux (genre l'objet global), et le livre de Douglas Crockford l'explique incroyablement bien: JS a de formidables atouts et quelques ratés, mais il suffit de ne pas utiliser les 'ratés' et on a en main quelque chose d'extrêmement puissant.       

&nbsp;

Parmi ces choix malheureux on a justement certains bouts de concept de classes qui sont là alors que JS c'est censé être du 'ptotoype based' (opérateur new, ...). Et ce qui génère la majorité des critiques de ceux qui jugent un peu vite JS: ce sont en général des gens qui viennent avec leur bagage de connaissances en 'class-based OO' (typiquement C++, Java, C#, etc...), croient (parce que les specs du langages le laissent croire) qu'ils vont réappliquer leur préceptes déjà connus au JS (je fait des types, j'hérite, ...), voient que ça pose tout un tas de soucis, et en concluent que le JS est merdique parce qu'il ne fait pas bien du 'class-based OO'.






  En fait, le JS est 'prototype-based' ; ça se résume en 9 mots: on n'hérite pas des types, mais des instances.     





Quand on a appris et intégré ça, qu’on a désappris un peu certains de ses vieux réflexes de dév. Java/C++/wtf qui ne doivent pas s’appliquer ici (même si le langage le permettrait ou pourrait le laisser penser), on comprend enfin sa vraie philosophie et ensuite (et seulement) on accède à tout le potentiel du langage et ses atouts.



  &nbsp;


+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é …&nbsp; “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.&nbsp;&nbsp;

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



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

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.


Faut vraiment pas aimer programmer pour ‘toucher’ a ces mer…








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.









CryoGen a écrit :



Oui enfin les développement lourd en javascript coté client ne concernent que très rarement les sites web publics et encore dans ce cas là c’est une erreur de choix effectivement.







Aujourd’hui, de plus en plus de sites web utilisent une palanquée de frameworks.



Soit on considère que ce n’est pas un mal : Mais dans ce cas, il faut être logique et comprendre que certains langages diminuent le cout de l’abstraction beaucoup mieux que d’autres. Si on veut augmenter le niveau d’abstraction, il faut abandonner Javascript.



Soit on considère que c’est un mal et l’on apprends a faire un usage raisonné.



Mais il n’empêche qu’il existe quand même des cas ou la programmation côté client peut apporter un très gros plus, voir se révéler indispensable. Et il y existe de très gros logiciels programmés côté client.



J’ai vu des choses fabuleuses écrites en Javascript qui ont du être jetées parce que c’était devenu simplement impossible à reprendre et à maintenir.





Ceux qui n’ont pas les moyens d’avoir la puissance nécessaire, non de toutes manières pas internet non plus… Et enfin sous prétexte que des gens vivent plus mal que nous, le JS devient une merde ?





Internet se répand dans les pays pauvres. Mais ils n’ont pas pour autant les moyens de se payer le dernier PC ou le dernier mac pour pouvoir surfer sur nos pages ultra lourdes.



Et le pire, c’est que c’est aussi le cas de beaucoup de nos concitoyens.



Beaucoup de webmasters n’imaginent pas à quel point leur pages web pondues sur le dernier mac avec un grand écran et testées sur le dernier smartphone haut de gamme peuvent exaspérer l’internaute de base avec son matériel modeste.



Face à ce problème, tu as deux possibilités.



Soit de faire des pages plus légères, de réduire les effets dynamiques, etc…



Soit d’améliorer le browser (et son langage) pour les remplacer par des outils plus performants permettant un meilleur usage de la puissance disponible.



Je suis bien sûr au courant pour le ===, mais qu’ils aient été obligé d’ajouter un nouvel opérateur pour corriger les incohérences de l’opérateur de base montre bien que le langage a été mal pensé à l’origine.



Vous allez me dire que le comportement du == était fait pour faciliter certains développements mais au final c’est un choix initial pourri qui cause plus de mal que de bien.



Dans le même genre ça me fait penser au choix de MS de rendre les chemins de fichiers insensibles à la casse. Choix qui a simplifié la vie des utilisateurs du DOS mais qui aujourd’hui n’a plus d’intérêt et qui pause des problèmes de sécurité car un fichier peut se faire passer pour un autre.








brazomyna a écrit :



Globalement, oui.




  Ca n'empêche pas que certaines parties dudit langage sont basés sur des choix malheureux (genre l'objet global), et le livre de Douglas Crockford l'explique incroyablement bien: JS a de formidables atouts et quelques ratés, mais il suffit de ne pas utiliser les 'ratés' et on a en main quelque chose d'extrêmement puissant.       

 

Parmi ces choix malheureux on a justement certains bouts de concept de classes qui sont là alors que JS c'est censé être du 'ptotoype based' (opérateur new, ...). Et ce qui génère la majorité des critiques de ceux qui jugent un peu vite JS: ce sont en général des gens qui viennent avec leur bagage de connaissances en 'class-based OO' (typiquement C++, Java, C#, etc...), croient (parce que les specs du langages le laissent croire) qu'ils vont réappliquer leur préceptes déjà connus au JS (je fait des types, j'hérite, ...), voient que ça pose tout un tas de soucis, et en concluent que le JS est merdique parce qu'il ne fait pas bien du 'class-based OO'.






  En fait, le JS est 'prototype-based' ; ça se résume en 9 mots: on n'hérite pas des types, mais des instances.     





Quand on a appris et intégré ça, qu’on a désappris un peu certains de ses vieux réflexes de dév. Java/C++/wtf qui ne doivent pas s’appliquer ici (même si le langage le permettrait ou pourrait le laisser penser), on comprend enfin sa vraie philosophie et ensuite (et seulement) on accède à tout le potentiel du langage et ses atouts.







Non, les problèmes de Javascript ne sont pas seulement une question d’apprentissage.



D’une part, il y a un problème d’efficience. Un langage typé dynamiquement et orienté prototype, on ne sait pas le compiler efficacement.



D’autre part, il y a un problème de maintenabilité. Le typage fort, c’est aussi une manière de documenter un logiciel.










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.









megabigbug a écrit :



Je suis bien sûr au courant pour le ===, mais qu’ils aient été obligé d’ajouter un nouvel opérateur pour corriger les incohérences de l’opérateur de base montre bien que le langage a été mal pensé à l’origine.



Vous allez me dire que le comportement du == était fait pour faciliter certains développements mais au final c’est un choix initial pourri qui cause plus de mal que de bien.









Dire qu’a une époque, le C/C++ était lourdement critiqué (à juste titre, il faut le dire) pour son usage du “==”.



Quoique capillotractée en tant que notation, le triple égal “===” n’est pas le pire qu’on peut voir dans un langage. D’ailleurs PHP fait également usage de cette notation (mais bon, PHP n’est pas une référence…).



Dans un langage avec typage faible, il aurait été plus judicieux de noter == l’égalité stricte (valeur + type) et utiliser un autre symbole, par exemple =~ pour une égalité qui effectue des conversions avant de déterminer son résultat. De cette manière les développeurs utiliseraient par défaut l’égalité stricte et cela éviterait plein de situation buggées.


Je n’ai pas compris le problème avec le == du c++ peux-tu développer ?

C’est parce qu’il n’était pas assez “intelligent” ?








sr17 a écrit :



Aujourd’hui, de plus en plus de sites web utilisent une palanquée de frameworks.



Soit on considère que ce n’est pas un mal : Mais dans ce cas, il faut être logique et comprendre que certains langages diminuent le cout de l’abstraction beaucoup mieux que d’autres. Si on veut augmenter le niveau d’abstraction, il faut abandonner Javascript.



Soit on considère que c’est un mal et l’on apprends a faire un usage raisonné.



Mais il n’empêche qu’il existe quand même des cas ou la programmation côté client peut apporter un très gros plus, voir se révéler indispensable. Et il y existe de très gros logiciels programmés côté client.



J’ai vu des choses fabuleuses écrites en Javascript qui ont du être jetées parce que c’était devenu simplement impossible à reprendre et à maintenir.







Internet se répand dans les pays pauvres. Mais ils n’ont pas pour autant les moyens de se payer le dernier PC ou le dernier mac pour pouvoir surfer sur nos pages ultra lourdes.



Et le pire, c’est que c’est aussi le cas de beaucoup de nos concitoyens.



Beaucoup de webmasters n’imaginent pas à quel point leur pages web pondues sur le dernier mac avec un grand écran et testées sur le dernier smartphone haut de gamme peuvent exaspérer l’internaute de base avec son matériel modeste.



Face à ce problème, tu as deux possibilités.



Soit de faire des pages plus légères, de réduire les effets dynamiques, etc…



Soit d’améliorer le browser (et son langage) pour les remplacer par des outils plus performants permettant un meilleur usage de la puissance disponible.







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 :)



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.









sr17 a écrit :



D’autre part, il y a un problème de maintenabilité. Le typage fort, c’est aussi une manière de documenter un logiciel.





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.



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

&nbsp;var maChaine;//String&nbsp;

&nbsp;var maDate;//Date&nbsp;

&nbsp;

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

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

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

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



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

&nbsp;

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.









sr17 a écrit :



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.



&nbsp;

&nbsp;C’est précisément ce que je disais en filigrane et avec ce smiley , ceci est une bataille de sensibilité et LA vérité n’existe pas, des vérités au pluriel, et des vérités du moment, oui.









sr17 a écrit :



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.





C’est sûr, c’est tellement merdique JS et spécifiquement NodeJS, que les sociétés qui forme la foundation ne sont que des inconnus.https://nodejs.org/en/foundation/members/

http://www.ecma-international.org/memento/members.htm

http://apmblog.dynatrace.com/2015/04/09/node-js-is-hitting-the-big-time-in-enter…

(mention spéciale à la citation de Kiran prasad)

&nbsp;&nbsp;

Et la V8 engine, qui appartient à Google, n’est pas du tout optimisée , ils s’en foutent en fait, de la performance, chez Google. Et s’il te plait arrête de parler de difficulté de compilation, c’est juste ridicule, notamment depuis 2010 et Crankshaft.



Non mais concrètement tu proposes quoi ? Que la somme considérable de projets et d’efforts autour de JS soit abandonnée du jour au lendemain au profit d’un hypothétique new player qui écraserait tout, d’un coup de baguette magique. Tu as quoi dans tes tiroirs, pour le web comme pour le mobile, comme langage de scripting client-side permettant de s’interfacer facilement avec http-html-dom-css et qui a une facilité naturelle avec le JSON, sans marshalling ?

&nbsp;

Et l’idée de NodeJS, l’idée du JS coté serveur, c’était simplement la réalisation que l’efficacité de la V8, couplé à la puissance de la programmation fonctionnelle, dés lors multithreadée, avait du sens coté serveur/réseau, avec un moteur I/O basé events . Et le marché leur a bien rendu, cette idée tient la route et les “big fish” la sponsorise.&nbsp;









Tamadadoo a écrit :



C’est sûr, c’est tellement merdique JS et spécifiquement NodeJS, que les sociétés qui forme la foundation ne sont que des inconnus.https://nodejs.org/en/foundation/members/

http://www.ecma-international.org/memento/members.htm

http://apmblog.dynatrace.com/2015/04/09/node-js-is-hitting-the-big-time-in-enter…

(mention spéciale à la citation de Kiran prasad)







Si l’on devait faire la liste de tous les standard médiocres qui ont été poussé par de très grandes sociétés dans l’histoire de l’informatique, on n’en finirait plus.



J’ai d’ailleurs un exemple très célèbre : le PC.



Je pourrais d’ailleurs te recommander la lecture d’ouvrages écrits par des gens très célèbres qui t’expliqueront mieux que moi pourquoi le monde commercial se moque éperdument de la qualité technique.

  



Et la V8 engine, qui appartient à Google, n’est pas du tout optimisée , ils s’en foutent en fait, de la performance, chez Google. Et s’il te plait arrête de parler de difficulté de compilation, c’est juste ridicule, notamment depuis 2010 et Crankshaft.





Personne n’a prétendu que la V8 engine n’est pas optimisée. Elle l’est certainement autant qu’elle peut l’être.



C’est juste qu’il y a des programmeurs qui croient dans une illusion : le grand mythe du compilateur magique.



Le mythe du compilateur magique, c’est le fait de croire que l’on peut écrire dans n’importe quel langage et que des compilateurs “magique”, “optimisés” et surtout “écrits par des grandes entreprises très célèbres” pourront optimiser de manière magique, parfaite et égale quel que soit le langage utilisé.



Mais tout ceux qui connaissent bien les langages de programmation savent que cela n’est pas vrai.



Cela s’explique d’ailleurs très simplement. Moins un langage est précis sur ce qu’un compilateur doit faire, moins le compilateur peut appliquer d’optimisations.



Une idée reçue fortement répandue, c’est de croire qu’un compilateur pourrait tout déduire. Ce n’est malheureusement pas vrai.



Même dans un langage fortement typé comme C/C++, les spécialistes de l’optimisation savent tout l’importance de certains mot clés pour produire un code optimal.





Non mais concrètement tu proposes quoi ? Que la somme considérable de projets et d’efforts autour de JS soit abandonnée du jour au lendemain au profit d’un hypothétique new player qui écraserait tout, d’un coup de baguette magique.





Non, tu as raison, c’est beaucoup mieux de perdre son temps et ses efforts à rustiner année après année un langage qui traînera éternellement ses tares de jeunesse…



Quand tu aura mon age, tu comprendra qu’a s’obstiner à vouloir construire des cathédrales sur un mauvais terrain, on ne fait qu’augmenter de manière inéluctable la quantité de travail qui devra être jetée.





Tu as quoi dans tes tiroirs, pour le web comme pour le mobile, comme langage de scripting client-side permettant de s’interfacer facilement avec http-html-dom-css et qui a une facilité naturelle avec le JSON, sans marshalling ?





Si j’ai bien compris, parce que tu ne vois rien qui soit susceptible de remplacer Javascript en moins d’un quart d’heure, l’humanité devrait se traîner ce boulet pendant 50 ans ?





Et l’idée de NodeJS, l’idée du JS coté serveur, c’était simplement la réalisation que l’efficacité de la V8, couplé à la puissance de la programmation fonctionnelle, dés lors multithreadée, avait du sens coté serveur/réseau, avec un moteur I/O basé events . Et le marché leur a bien rendu, cette idée tient la route et les “big fish” la sponsorise.





Et biens honnêtement, je pense que tu devrais étudier mieux le fonctionnement de NodeJS. <img data-src=" />



Tu comprendrait d’ailleurs que son fonctionnement n’est pas une “feature”, mais découle irrémédiablement de la fonction que ce langage avait dans un navigateur.



Cette façon de fonctionner avait un sens dans le cadre de la gestion d’événement d’une page web au sein d’une boucle d’affichage monothreadée. Mais en dehors de son cadre initial, le concept est pour le moins controversé…



Et parce que le débat est complexe et dépassera le cadre de ces commentaires, je t’engage à étudier les débats de spécialistes que l’on trouve sur le web à ce sujet. Tu comprendra mieux pourquoi les concepts qu’utilise NodeJS ne font pas l’unanimité.



Et sur un autre plan, celui de la maintenabilité, je suis persuadé que tant que vous utiliserez ce système pour des exemples simples (genre 100 lignes de code), vous ne comprendrez pas les vrais problèmes. Quand vous verrez à quoi ressemble un vrai projet industriel de plusieurs centaines de milliers de lignes de code, vous comprendrez ce que les vieux programmeurs vous disent.









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.









megabigbug a écrit :



Je n’ai pas compris le problème avec le == du c++ peux-tu développer ?

C’est parce qu’il n’était pas assez “intelligent” ?







Disons qu’avant la généralisation de la syntaxe du C, la plupart des langages utilisaient le “=” comme opérateur de comparaison. Le choix du C d’utiliser le “==” comme opérateur de comparaison paraissait alors totalement incongru autant que source d’erreur(les compilateurs de l’époque étaient beaucoup moins prévenants).



Mais (sans rentrer dans les détails) ce choix avait aussi de gros avantages, c’est pourquoi il a perduré.



Et sinon c’était encore un bon moyen pour les informaticiens de faire chier les mathématiciens…












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.



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.



&nbsp;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…



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é.








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.