Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
L'interface est implémentée explicitement si j'ai bien compris... La classe Student a toutes les propriétés déclarées dans l'interface Person, donc un Student est accepté là où un Person est attendu.Envoyé par hotcryx
Pourquoi un StringBuilder ? C'est du JS (enfin principalement), pas du C#...
Pas de questions techniques par MP ! Le forum est là pour ça...
Tutoriels : Les nouveautés de C# 6 - Accès aux données avec Dapper - Extraction de données de pages web à l'aide de HTML Agility Pack - La sérialisation XML avec .NET (Aller plus loin) - Les markup extensions en WPF
On va diverger si on commence maintenant à rentrer dans le débat langage à typage fort / faible, mais oui, pour des raisons de maintenance (entre autre) il faut les outils pour valider ton code. Ces outils existent en JavaScript: jslint, jshint, l'analyse statique du code via les IDE (Netbeans ou autre), documentation via jsdoc, ...il y a qu'en même de grosses lacunes comme le typage.
cela ne peut entrainer que des erreurs d'exécution ou lors de conversion de type. Comme ce fut le cas en VB6 avec les Variant.
un langage ne doit pas permettre de faire tout et n'importe quoi n'importe comment. Il faut un minimum de structure sinon ça devient de la bouillie, du code spagetti...
cela dit, je n'ai rien contre toi et javascript, c'est juste mon point de vue.
je suis du même avis, un mauvais codeur, restera mauvais mais malheureusement on doit parfois reprendre le code d'un autre et c'est là que ça peut coincer si le langage ne met pas des gardes fous
Je fait un fort distingo entre langage et environnement de dev te permettant de travailler sur le langage. En effet, combien de dev serait actuellement perdu sans leur Eclipse ou autre Visual Studio chérie.
Ici on un langage conçu au dessus de JavaScript... super, mais pour l'utiliser dans un cadre adéquat, il faut passer par Visual Studio. Microsoft n'aurait pas mieux fait d'améliorer leur IDE pour la reconnaissance de JavaScript ? Mais je crains que leur démarche soit la suivante:
1 - Microsoft créé un langage au dessus de JavaScript (donc compatible ECMAScript 5)
2 - Microsoft teste si la communauté est réceptif
3 - Si oui, alors Microsoft l'intègre à Visual
4 - Microsoft l'intègre à IE
5 - Microsoft force de facto la communauté responsable des spec ECMAScript 6 à s'inspirer fortement de ce qu'ils ont implémenté
On se retrouve alors avec Microsoft qui fait une OPA sur JavaScript.
Juste pour infos un excellent billet de Scott Hanselman pour mieux éclaircir les choses pour ceux qui y voient du flou par rapport aux autres tools déjà dispo
marts >> arrête de prendre les gens pour des idiots
tomlev >> pour éviter les allocations mémoires inutiles (pareil en java et C#). Dans le passé, il me semble avoir utilisé StringBuilder (ou alors un truc équivalent) mais pas le "+" sur des milliers d'opérations avec Greasemonkey.
Et j'aime autant te dire que la perf sur Firefox à l'époque (2.0) était très très rapide sur IE.
Tu as compris ... à moitié.marts >> arrête de prendre les gens pour des idiots
Mon propos se voulait aussi simpliste et radical que le tien.
Ce n'est pas un question de coder propement ou pas , c'est une question de productivité.Suis-je le seul à être choqué par ce type de remarque concernant JavaScript ?
J'en ai assez d'entendre que ce langage est un mauvais langage. Peu importe le langage, un mauvais codeur produira toujours du mauvais code. L'important est de maîtriser les outils que l'on a, et, désolé pour certains, JavaScript est langage pointu qui permet de faire de belles choses SI on s'en donne les moyens.
JavaScript n'est pas Java ou C++, donc oui, si vous voulez coder en JavaScript il vous faut d'abord apprendre à comment coder proprement.
C'est exactement le même débat que pour CSS vs SASS et LESS.
cela implique de connaitre le langage de base tout en exploitant des possibilité s qui rendent le code plus maintenable et permettent au développeur d'être productif. JShint et JSlint sont des outils de vérification de qualité du code , pas d'analyse "statique" ou d'extension du code.
TypeScript permet d'organiser ses librairies de code dans des fichiers séparés afin de créer des composant dépendants facilement réutilisables , et introduit des structures qui ne seront pas adhoc avant un bon bout de temps => donc plus productif.
Et si Javascript était si bon que ça , pourquoi TC39 veut mettre des modules , des classes des structs , des proxys , des iterateurs des générateurs dedans si les développeurs n'en ont pas besoin ? les développeurs avaient ils besoin d'ES3.5 ?
Le but de TC39 est précis : créer un meilleurs javascript et faire de javascript une meilleurs cible de compilation pour les langages third-party. C'est pas moi qui le dit ,c'est TC39.
Microsoft ne fait que répondre à un besoin.
Des solutions qui compilent vers JS il y en a des centaines déja : haxe, JSX , coffeescript , iced coffee , clojurescript ,emscripten ,GWT , etc ... et ce n'est pas près de s'arrêter.
Les développeurs compilent même du C/C++ vers javascript :
https://github.com/kripken/BananaBread/
On peut le faire en JavaScript actuellement, tout ce qui manque c'est une intégration digne de ce nom de JavaScript dans un IDE.
Je ne jamais dit que JavaScript étant exemp de défauts, le langage évolue et c'est tant mieux. Mais là je crains que l'on parte dans une direction où TypeScript soit de facto l'implémentation d'ECMAScript 6 sans passer par la case validation T39. Microsoft n'est pas Mozilla, son but s'est d'être rentable, alors je vois d'un mauvais oeuil autant d'énergie dépenser pour créer un "nouveau" langage au lieu de créer un bon écosystème autour de JavaScript.
Oui, mais pas de la bonne manière pour moi.
Tant mieux, mais après il ne faudra pas se plaindre de se trouver avec des dev web qui ne savent plus comment le web fonctionne.
Microsoft a fait sortir beaucoup de framework, de tools et aujourd'hui un surlangage de javascript. D'autres géants aussi du logiciel le font : Preuve de la puissance de ce langage.
L'auteur de la citation suivante a bien compris :Microsoft a fait sortir beaucoup de framework, de tools et aujourd'hui un surlangage de javascript. D'autres géants aussi du logiciel le font : Preuve de la puissance de ce langage.
Oui mais justement, si le résultat est le même ; MS, Google, Apple auraient pas plutôt intérêt a travailler sur un système commun? Ils y gagneraient en temps de développement, en correction des bugs, en clarté aussi... etc.Citation:
au final le code généré c'est du javascript parfaitement lisible , donc même si demain MS abandonne typescript , les librairies générées seront toujours totalement utilisables. Maintenant faut il apprendre typescript , coffeescript ou javascript ? débugger son application se fait toujours en javascript donc javascript est obligatoire , cela ne veut pas dire qu'on doit écrire du code js, c'est tout l'intérêt de ces langages.
Ils y a une raison particulière qui peut justifier ces choix de développement a part autre que la concurrence?
Ecrire du code TypeScript et debugger du javascript.
Dans ce cas pour corriger un bug, il faut deja bien maitriser le javascript..faire un mapping pour savoir ou modifier...
Edit:
Il y a ca: http://www.html5rocks.com/en/tutoria...ls/sourcemaps/
Je sais ce que c'est qu'un StringBuilder, mais à ma connaissance ça n'existe pas en JS... (cela dit ma connaisance de JS est assez limitée, je l'admets)
Au bout d'un moment il y aura surement un "JS++" qui les mettra tous d'accord. La question est de savoir s'il sera parmi les Dart, CoffeeScript et maintenant TypeScript. M'est avis que celui qui arrivera à outrepasser le JavaScript en ne générant pas de JS à partir du code écrit par le développeur et en ayant son propre moteur aura beaucoup de chances d'être ce langage.
Tu devrais plutôt comparer JS à d'autres langages de script comme Python ou Ruby...
et c'est toi qui dénigre les dévs qui ont besoin de visual studio chéri ?!?
si on doit se passer d'outil pour le c/c++ pour "savoir programmer", la même chose devrait être appliquée pour le javascript, et sans outil javascript est bien plus inutilisable que c/c++.
encore une fois le web ne fonctionne pas en javascript, faut arrêter avec ça, le boulot de javascript pourrait être fait avec n'importe quel langage ... encore faut il que les extrémistes du web arrêtent avec cette manie de considérer que le javacript doit être le seul langage du web.
Le problème est simple, les utilisateurs ne mettent pas leur navigateur à jour donc seul ce qui existe est utilisable pour les prochaines années... d'où les langages qui tentent d'améliorer le JS en rajoutant des trucs et en offrant une compilation.
Si il était facile d'ajouter à tout le monde un nouveau langage compréhensible par tous les navigateurs, ça ferait longtemps que ça serait fait !
A noter que contrairement à ce que certains disent, il ne faut pas forcément visual studio pour faire du typescript, ils ont fait un module node que tu installes en global et qui permet de compiler via une ligne de commande toute con (tsc nomdufichier), assez facile de modifier son IDE pour faire une compilation automatique à la sauvegarde ou à l'exécution je pense !
Et si MS s'investit autant dans le JS c'est tout simplement pour faciliter la vie des développeurs qui font des applis pour windows 8 en HTML5/JS !
Issu du blog de Scott Hanselman :
Ce type a cerné le problème :What I like about TypeScript - so far - is that TypeScript’s static typing could enable better tooling with warning squiggles, easy statement completion, plus smart refactoring. You also get easy navigation around code, as well as find references, rename, and more.
Voilà les avantages du typage statique, la détection d'erreur et le fait de rendre possible un support IDE poussé (refactoring, auto-complétion etc...).
Ces choses permettent justement de travailler efficacement en équipe, de s'y retrouver lorsque les bases de code deviennent importantes, d'être productif et d'économiser beaucoup de temps.
Dans l'état actuel de javascript, ceci n'est qu'à moitié possible justement. Ce n'est pas le seul langage dans cette situation, regarde PHP, tu verras que malgré la popularité et les années de bouteilles, aucun IDE ne peux t'offrir un support aussi avancé que C# ou java niveau refactoring et complétion.
L'IDE serait quasiment obligé d'exécuter le code from scratch pour savoir s'il est valide ou non.
Puis s'il vous plaît pour ceux que cela concerne, cessez de dire que c'est au développeur de faire attention. Vous n'utiliseriez pas les mêmes variables pour stocker des doubles, des chaînes et des pointeurs de fonction alors pourquoi tenez-vous tant à ce que ce soit possible niveau langage? En sachant que ça amène que des problèmes, tant pour les interpréteurs qui sont incapables d'optimiser, pour les IDE incapables de vous corriger, et pour vous qui risquez de vous faire avoir.
Pour ceux qui se croient tellement malins, vous êtes pas des machines mais des humains, en ce sens vous êtes faillibles et les autres membres de votre équipe aussi. Une fois sur 1000, 10000 ou 100000 lignes de code vous utiliserez une variable de façon inappropriée, ça marchera par bol dans vos tests (c'est là le plus traître) et ça posera problème en production.
Pour en revenir au sujet plus directement, je trouve qu'on a vraiment besoin de projets comme Dart ou TypeScript pour rendre le code JS plus sûr, plus maintenable et plus testable. Le seul point négatif c'est le danger de multiplication de ces JS-killers qui conduise à ce qu'aucun ne soit suffisamment répandu et viable.
D'accord avec toi _skip
Je serais curieux de voir le code JS généré de coffiescript...
Les codes générés seront différents, les perfs différentes...
Et que faire lorsque "ça merdouille" avec le générateur!?
Voilà une question qu'il faut se poser avant d'en utiliser un.
Je pense que _skip a mis le doigt sur les principaux arguments en faveur des langages à typage statique. Après, c'est sûr que les langages dynamiques ont aussi certains avantages, mais pour des grosses applications, le bénéfice du typage statique est évident.
Et que faire lorsque "ça merdouille" avec n'importe quel autre compilateur ? A un moment donné il faut bien faire confiance aux outils, sinon on fait plus rien...Et que faire lorsque "ça merdouille" avec le générateur!?
_skip: Je suis plutôt d'accord avec toi sur les lacunes de JS, je t'ai donc plussé. Comme tu l'as très bien mentionné, même le meilleur des cadors ne choisit pas forcément ceux avec qui il travaille...
Si je préfère moi aussi un typage statique à un typage dynamique, ce n'est pas la seule piste. Les autres langages de script que j'ai cité plus haut (Python et Ruby) ont aussi un typage dynamique et pourtant ils supportent mieux la mise à l'échelle que JS parce que :
- Ils ont de véritables systèmes de modules/packages, qui délimitent les visibilités des symboles et permettent de bien séparer les responsabilités.
- Ils ont un typage fort, qui interdit les conversions implicites. Par exemple, additionner un entier et une chaine de caractère est considéré comme une erreur et lance une exception de type TypeError au lieu de faire une conversion silencieuse. Ça permet par exemple de signaler au plus tôt une erreur au lieu de devoir essayer de comprendre pourquoi à la suite de plusieurs calculs, ce qu'on obtient est faux ou alors n'est pas un nombre...
Si déjà on pouvait avoir quelque chose dans ce goût là, je me considèrerais satisfait...
Répondre avec citation
Partager