Oui, il y a déjà assez de langages pour en créer d'autres
Oui, ce sont les bibliothèques qui rendent un langage productif
Non, on ne peut pas corriger les défauts d’un langage avec des bibliothèques
Non, c’est le langage qui détermine le genre de bibliothèques possibles
Non, un nouveau langage tire des leçons des défauts des anciens langages
Pas d’avis
Autres (à préciser dans les commentaires)
Comme dirait ma fille (14 ans). Non, mais t'es sérieux là! Qu'est-ce qu'on va bien pouvoir faire avec du bytecode lorsque l'on développe pour le web ? Le seul debuggeur que j'utilise lorsque je développe en javascript, c'est Firebug. C'est suffisant, pourquoi tu veux coller des débuggeurs bas niveau à Javascript Le développement JS n'a rien à voir avec le dev C ou C++, faut juste accepter le changement.
"La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"
Hormis des questions économiques, un nouveau langage apporte un nouveau moyen d'abstraction, comme UML par exemple, ou d'autres outils, l'interface cité par MikeRowSoft, ou une nouvelle application. Pourquoi devrait-on programmer toujours pour des machines? Pourquoi ne pas programmer pour des animaux ou des humains ? Ex : Programmer le démontage d'une usine.
Y a quelques années, je voulais compiler l'ensemble de mon expérience en dev de site web pour faire un outil qui permettrait à n'importe qui de faire un site web "sur mesure", juste en répondant à des questions.
Il choisi le type de site (parmis une liste), puis en fonction du type il a un questionnaire qui permet d'affiner les fonctionnalités.
"La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"
Attends, on a pas encore eu les pro/contre Java...
L'informatique est en constante évolution. Il n'y a pas de raison que les langages soient figés. Comme dit plus haut (Luckyluke34) l'évolution de toute l'informatique entraînera la création de nouveaux paradigmes et donc de nouveaux outils y répondant et en particulier les langages de programmation.
M. Lebowski : Avez-vous un emploi, monsieur ?
Le Duc : Un emploi ?
M. Lebowski : Ne me dites pas que vous cherchez un emploi dans cette tenue un jour de semaine ?
Le Duc : Un jour de… Quel jour on est ?
C'est surtout que ça n'a aucun sens qu'une chaîne vide soit évaluée à false, alors qu'un tableau ou objet vide est évalué à true (enfin pour l'array, si t'utilises l'opérateur !, si tu fais la comparaison avec == false, cette fois ça vaut false, mais WTF), et autres joyeusetés du genre
Et je parle même pas des immondices avec les instanceof qui retournent pas du tout ce qu'on est en droit d'attendre
Et le passage sur l'addition/concaténation de chaînes et chiffres qui finit d'achever tout ça
De là à dire que javascript ça part dans tous les sens et fait n'importe quoi.. c'est plutôt simple à franchir comme pas
En face tu prends LUA qui a une syntaxe équivalente, un système de prototypage équivalent, il a bien moins d'immondices à l'utilisation. Ou bien Python
Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
Un peu de programmation réseau ?
Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.
Personnellement, je trouve que le foisonnement de langages et de librairies actuelles est détestable.
Mais pire que ça, c'est le changement permanent qui est pénible.
On a pas fini de débugger une nouvelle techno et de la rendre à peu près stable que déjà il faut se jeter sur le dernier truc à la mode.
Mon choix va au langage qui évolue le moins ou en tout cas qui n'évolue qu'après avoir bien pesé pour et contre.
Un langage où le code que j'écris aujourd'hui ne sera pas obsolète dans 2 ans.
Pour la même raison, mon choix va aux bibliothèques qui ont le moins d'interdépendances et dont l'API reste stable.
Ben non. C'est le WebAssembly qui est parsé et débuggué au moment de sa compilation en bytecode. Comme pour du C# serveur. C'est juste que dans le navigateurs, après, ce sera du bytecode. Et c'est cool, on ne verra plus ton code en clair !
Sinon pour la vidéo ci-dessus, le mec a testé des bases. Des choses qu'on pourrait utiliser n'importe quand n'importe où selon les situations. Il y a des situations particulières qui peuvent obliger à des manipulations relativement stupides, parce que le langage exige un workaround. Ca n'arrive pas qu'à Javascript, mais plus souvent à Javascript.
Quand on te dit que 2=="2" => true, la messe est dite... C'est le principal reproche fait à JS, en plus du debuggage. Ou encore que 2+"2"= 4 au lieu de 22.
Quand ParseInt("08") = 0 aussi.
Ou quand 0.1 + 0.2 != 0.3, encore aussi. Car 0.1 n'est pas le 0.1 qu'on écrit habituellement. C'est un truc du style 0.10000000000034.
Ou encore quand Math.max < Math.min, c'est encore problématique.
Pour moi le fait d'avoir un paradigme différent n'est certainement pas le problème de JavaScript, J'ai appris des langages avec de paradigmes bien plus éloignés de l'objet par classe, que le JavaScript.
Son typage contre naturel est pour moi de loin son premier défaut. Il y a la célèbre vidéo "Wat" qui présente très bien le problème de manière drôle. Tu rétorqueras a raison, que tous les langages ont ce genre de petites subtilités, mais en JavaScript il y en a partout, et tout le temps .
Autant je suis d'accord sur le reste, autant sur ce point, le responsable c'est la norme IEEE 754. Tu auras le même problème sur presque tous les langages car ils utilisent cette norme (ou des variation légères de celle ci). Vu qu'elle est basée sur une représentation binaire des nombre a virgule flottante, on ne peut absolument pas considérer les valeurs, même littérales, comme exactes.
J'ai jamais compris cette obsessions chez certains de vouloir cacher le code.cool, on ne verra plus ton code en clair !
Si tu veut pas qu'on voient ton code, tu le mets pas sur internet voila, compiler ou pas, sa n'offre aucune protection, seul une licence le peut.
Sa me parait dangereux d’exécuter du bytecode a distance quand meme, le compiler dans le navigateur permeterais au moins au compilateur d'analyser le code et d'éviter de lancer des instructions de ce type:
J'extrapole et je me doute que se sera pas aussi simple, mais quand on voit les failles de Flash et des Applets java j'suis pas trop chaud.
Code : Sélectionner tout - Visualiser dans une fenêtre à part format c:
Je trouve que sa offre une sécurité supplémentaire de pouvoir voir le code source. Sa permettras aussi d'installer/crée des plugins qui pourrons modifier interdire certaines instructions.
Ba, comme je l'ai dit précédemment, un langage sa s’apprend et la pire des erreur que l'on puise faire, c'est de vouloir faire en sorte qu'il fonctionne comme les autres.
Dans les spécificité du langage il y a un certain nombre de valeur qui retourne false si elle sont évalué parce qu'il y a des conversion implicite lors de l'utilisation de certain opérateur que l'on peut évité en faisant les chose bien.
Si c'est trop compliqué pour d'apprendre les spécificité du langage, vous n'avez qu'a pas évaluer d'expression sans l'opérateur "===" qui est là pour sa et utilisé toString() { (42).toString(); } pour convertir les nombre en chaines.
Bref, faut arrêter de faire n'importe quoi et chercher à comprendre en lisant la doc...
C'est tout à fait normal, il faut utiliser le "===" pour comparer la valeur et le type en JS, le "==" fait des conversion implicite.Quand on te dit que 2=="2" => true, la messe est dite...
Chez moi sa fait bien "22", mais bon au pire on mélange pas les torchon et les serviette et tu convertie ton nombre en chaine si tu veux les concaténé...Ou encore que 2+"2"= 4 au lieu de 22.
Chez moi ça sa péte une erreur...Quand Math.Round(8) = 0 aussi.
et oui la magie des float que l'on retrouve dans beaucoup de langageOu quand 0.1 + 0.2 != 0.3, encore aussi. Car 0.1 n'est pas le 0.1 qu'on écrit habituellement. C'est un truc du style 0.10000000000034.
Tu m'explique se que tous fous à utiliser une méthode (qui est censé prendre au moins un argument) sans paramètre?Ou encore quand Math.max < Math.min, c'est encore problématique.
C'est utiliser les api n'importe comment qui est problématique et ça, sa vaut pour tous les langage!
La plupart des problème que vous cité résulte d'une mauvaise utilisation du langage, alors certe certain truc peuvent paraître étrange, mais en codant normalement et en respectant certaine convention, se genre de chose n'arrive jamais (ou que rarement) et quand on apprend à les utiliser, dans bien des cas sa facilite les chose.
Sauf que justement un langage moderne comme JavaScript aurait vraiment du d'éviter au maximum les comportements contre intuitifs, surtout qu'il n'a pas l'excuse de vieux langages comme le C qui à 40 ans d'histoire avait des contraintes très différentes.
D'autres langages (comme le Python qui précède le JavaScript de quelques années) font beaucoup mieux là dessus.
Non y a d'autres moyens pour ça, comme JScrambler. Ce que je veux vraiment, c'est débugger, c'est voir des erreurs de compilation avant l'exécution, des trucs soulignés, pas parce que la syntaxe est pas bonne, mais parce que le résultat a un soucis, un inspecteurs d'objets pour voir quels sont les types de chaque variable, l'évolution de leur valeur à chaque ligne de code,...
Le problème de Javascript, c'est que ça passe, mais qu'après on ne sait pas ce qui se passe... Ca pourrait être un proverbe ça ^^
Quand on te dit que 2=="2" => true, la messe est dite... C'est le principal reproche fait à JS, en plus du debuggage. Ou encore que 2+"2"= 4 au lieu de 22.
Quand Math.Round(8) = 0 aussi.
Ou quand 0.1 + 0.2 != 0.3, encore aussi. Car 0.1 n'est pas le 0.1 qu'on écrit habituellement. C'est un truc du style 0.10000000000034.
Ou encore quand Math.max < Math.min, c'est encore problématique.
Répondre avec citation Répondre avec citation Multi-citer ce message 0 0 Créer une entrée Blog
Quand on te dit que 2=="2" il faut répondre c'est normale car en javascript il existe le triple égale (moderne) qui vérifie le type la bonne syntaxe est 2==="2"
Ou encore que 2+"2"= 4 pourquoi ça doit retourné automatiquement 22 dans ce cas on a deux choix pour l'implémentation soit on favorise l'addition soit on favorise la concaténation en final le deux sont faux le meilleur choix devrait être une erreur mais au fait chez moi aussi ca retourne 22.
0.1 + 0.2 != 0.3 n'est pas le 0.1 c'est la précision mais comme ça a déjà été dit c'est pas la faute a js
Math.max < Math.min ca a été dit
(Math.round(8) retourne 0 il teste avec ie 3 son code ? car avec chrome et firefox Math.round(8) retourne 8
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31 <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>tt</title> <style type="text/css"> body{ background-color:gray; } </style> <script> function teste(){ alert(2+"2") alert(Math.round(8)) alert(2=="2") alert(2==="2") } </script> </head> <body> <button onclick="teste()">teste</button> </body> </html>
Plus vite encore plus vite toujours plus vite.
Disons que plutôt que d'avoir des refresh en passant par le serveur, c'est bien d'avoir des trucs ultra réactifs via un langage client. Et malgré une licence, tout le monde peut te voler ton code, en le modifiant un petit peu pour ensuite te faire concurrence. WebGL pour les jeux, c'est aussi du JS. Donc on est pas prêts de laisser tomber Flash pour des jeux comme Angry Bird.
Sans oublier, mais bon, t'expose aussi ta médiocrité, la mise à nue de failles de sécurité, genre injection JS.
C'est sensé être validé par le W3C. Donc ils prendront bien 10 ans pour le tester ^^'
Non mais pour le "===" ou d'autres trucs, ceux qui pratiquent JS le savent, et le mec de la vidéo aussi. Il dit bien qu'il a beaucoup pratiqué JS. Il montre juste à quel point le langage est inintuitif pour le premier venu.Envoyé par melka one
Par contre, Mea-Culpa. C'était pas Math.Floor(8) = 0, ma mémoire m'a joué des tours (et je trouvais ça bizarre quand même). C'était ParseInt("08") = 0 alors que ParseInt("06")=6. Il faut préciser que c'est en base 10 avec ParseInt("08",10). Bref, c'est logique pour le commun des mortel (ironie inside). Ton code marchera à des moments, et si tu tombes sur un multiple de 8 par hasard selon ce que saisit l'utilisateur, ben tu comprends pas si tu ne connais pas le comportement de JS pour ce genre de choses... Si le mec n'avait pas parlé du 2ème paramètres, j'aurais mis des jours à tilter là dessus.
Merci pour l'info sur la norme des float. Je la connaissais pas. Faut croire que .NET a su gérer ça. J'étais jamais tombé sur ce genre de problème. D'ailleurs quelle idée de pondre une norme impliquant qu'un nombre n'a pas la valeur de ce qu'on écrit et voit à l'écran... Enfin bon, ça permet de comprendre l'intérêt du type Number, ou de mettre Math.Round de partout.
Quand tu sors de l'école (Bac+5), tu as quoi, 4 heures de Javascript sous le bras ? Et on t'auras appris que le DOM et la base du prototypage. Je vois pas comment tu peux t'en sortir correctement en entreprise sans des mois à ne faire QUE ça ou une formation dédiée, avec un super débuggueur.
Ce langage a sa cohérence à lui, différente des langages plus contemporains et des concepts de base qu'on t'apprend à l'école. Donc à qui la faute ?
Ca me réconcilie un peu, voyant qu'il y a une logique, mais je ne démords pas qu'il faudrait qu'il soit compilé et qu'il y ait de vrais cours dessus.
ne fait pas de remarque trop futuriste. Faudrait bien garder la possibilité de faire faire la même chose mais de deux façon différentes au minimum.Hormis des questions économiques, un nouveau langage apporte un nouveau moyen d'abstraction, comme UML par exemple, ou d'autres outils, l'interface cité par MikeRowSoft, ou une nouvelle application. Pourquoi devrait-on programmer toujours pour des machines? Pourquoi ne pas programmer pour des animaux ou des humains ? Ex : Programmer le démontage d'une usine.
encore faux chez moi sa retourne 8Par contre, Mea-Culpa. C'était pas Math.Floor(8) = 0, ma mémoire m'a joué des tours (et je trouvais ça bizarre quand même). C'était ParseInt("08") = 0 alors que ParseInt("06")=6. Il faut préciser que c'est en base 10 avec ParseInt("08",10).
je connais pas les motivations du gars mais je pense qu'il a voulu jouer sur le fait que javascript est mal vu c'est plus un sketch qu'autre chose.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33 <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>tt</title> <style type="text/css"> body{ background-color:gray; } </style> <script> function teste(){ alert(parseInt("06")) alert(parseInt("08")) } </script> </head> <body> <button onclick="teste()">teste</button> <div style="margin:auto"></div> </body> </html>
pour en revenir au sujet qui dit qu' un bon langage semble etre un langage qui permet la création de framework efficaces vu le nombre de framework en js javascrpt semble etre the langage
Plus vite encore plus vite toujours plus vite.
C'est pas pour être utilisé par un autre corps de métier qu'il y a quelques fois des zones de textes accueillant un code "interprétable" ?En face tu prends LUA qui a une syntaxe équivalente, un système de prototypage équivalent, il a bien moins d'immondices à l'utilisation.
Il y a pas que LUA dans se cas, les scripts systèmes sont aussi concernés...
Je crois que SQL pointe le bout de son nez...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager