Connaissez-vous réellement le javascript? - Page 2

les closures, ça doit arriver bientôt aussi en PHP ; c'est prévu pour PHP 5.3, qui a passé l'étape de feature freeze aujourd'hui (pour la rfc, cf : http://wiki.php.net/rfc/closures )

heu du JS interperté dans un VM en bytecode pourrais bien arriver en terme de vitesse a qq chose de grossierement similiaire au Java et n'importe quel autre language fonctionnant dans une VM

oui, la différence de vitesse sera peut-être pas majeure, mais elle ne peut que exister. Toute structure de données en Java est fixée à la compilation, pas en JS (c'est le seul intéret pour moi de js d'ailleurs ). Donc l'accès à une propriété ou une fonction d'un object en Java va se faire avec un simple offset, alors que le js faudra qu'il fasse une sorte de lookup dans une map.

onur (./29) :
Je pense que tu as mal appri le javascript. Pourquoi tu n'utilisais pas les classes? C'est pas parce qu'il n'y a pas de mot clé class qu'il n'y a pas d'objet. On peut tout à fait faire du modulaire en js, meme dans la version 1.5.

Je sais qu'on peut. Ce qui me dérange moi c'est qu'avec cette approche "tout dynamique" tu n'as aucune aide du compilateur pour détecter des erreurs. C'est pas gênant pour les petits projets, mais dès que tu veux faire plus, c'est très vite embêtant. J'ai pas envie de passer mon temps à tester tous les chemins d'exécution de mes programmes pour être sûr que j'ai pas mis un objet Foo à la place d'un objet Bar.

Avec haXe je suis plus confiant : le typage à l'exécution reste dynamique donc tu peux faire un peu ce que tu veux en terme de manipulations, introspections, closure, etc. mais le compilateur et son inférence de type permettent de détecter la plupart des erreurs de typage à la compilation.

Bah sur des gros projets faut se mettre des conventions et si tu développes de facon modulaire, tu n'as pas de probleme (tu peux tester chacun de tes "modules")

sinon le typage tout dynamique n'est pas vraiment "grave". En fait, il m'a fallu un peu d'expérience dans les deux et je me suis rendu compte de ça:

Dans les langages compilés, la compilation nous sauve que des erreurs avec les variables typés statiquement, les autres sont à la merci des casts dynamiques qu'on met dans tous les sens. Or, les variables typés statiquement ne constituent pas vraiment un danger, un int, on sait qu'on va l'utiliser comme un int: qu'on le déclare avec int ou avec var. Et le polymorphisme reste avec autant de danger, donc finalement on a l'impression qu'on perd bcp avec l'absence de types statiques mais en fait pas tant que ça.

Sans parler du fait qu'un VM optimise mieux les cas de polymorphisme grâce à son JIT-compiler.

nitro > je vais regarder haXe là. ca m'intrigue

onur (./35) :
à la merci des casts dynamiques qu'on met dans tous les sens

heu... je crois que je sais où tu peux commencer à chercher l'origine de tes problèmes

quels problèmes?

le fait que la compilation ne t'aide pas tant que ça à détecter tes erreurs à cause de casts dynamiques que tu mettrais dans tous les sens (enfin de façon plus générale, tous les problèmes qui peuvent être liés à l'utilisation intensive de casts dynamiques, mais je t'invite à aller lire les topics qui parlent déjà de ce sujet pour ne pas avoir à tout recopier)

Ouais enfin les templates, ca existait pas en java il y a encore quelques années... donc faire/utiliser une liste chainée un peu générique, c'était pas un cadeau.
Sinon, globalement : même si c'est compilé, on n'est pas à l'abri des erreurs à l'execution (ça on le savait) mais on est obligé d'en tenir compte à l'écriture du programme (d'où l'existence des exceptions etc.). Y a pas une fossé entre un prog écrit en C++ et un prog écrit en langage dynamique où on fait (un peu plus) attention.

onur (./39) :
Ouais enfin les templates, ca existait pas en java il y a encore quelques années... donc faire/utiliser une liste chainée un peu générique, c'était pas un cadeau.

Je n'avais même pas pensé au Java à vrai dire, mais l'absence de templates qui oblige à utiliser des dynamic casts c'est un manque du langage, pas un problème lié aux langages typés à la compilation. Pour rappel, quand tu utilises un cast dynamique, c'est que tu en es arrivé à un point de ton code où tu as perdu l'information sur la nature de ce que tu manipules : sauf exceptions, c'est une erreur de conception.

Sinon, globalement : même si c'est compilé, on n'est pas à l'abri des erreurs à l'execution (ça on le savait) mais on est obligé d'en tenir compte à l'écriture du programme (d'où l'existence des exceptions etc.). Y a pas une fossé entre un prog écrit en C++ et un prog écrit en langage dynamique où on fait (un peu plus) attention.

Je ne suis pas du tout d'accord avec ce que j'ai compris de ces affirmations, mais peut-être que j'ai mal interprété ; tu peux détailler ?

Perso je n'ai pas eu à faire à des casts dynamiques dans mes progs C++ (cf le code d'ETP qui est public maintenant), je parle de ça parce que j'en vois tout le temps dans les codes des autres et sur internet. Et ça, je trouve ça plus moche que quand on code avec un langage typé dynamiquement.

Zephyr (./40) :
Je ne suis pas du tout d'accord avec ce que j'ai compris de ces affirmations, mais peut-être que j'ai mal interprété ; tu peux détailler ?

Ce que je dis, c'est que meme quand c'est du compilé, on est amené à vérifier si le pointeur est null, si le fichier qu'on écrit est bien généré, et vérifier d'autres aléas de ce genre. Et c'est pareil en JS: quand c'est critique, on hésite pas à ajouter une vérification typeof(x)=="number"

c'est vraiment pas de la programmation propre je trouve

Non ca l'est pas, et on le fait pas. Quand on sait ce qu'on écrit comme programme, on n'a pas besoin de ce genre de vérification (sauf éventuellement pour le début, on met (alert(typeof(x))...

(enfin là je parle de l'exemple de vérifier typeof(...))

c'est encore plus sale le débogage à coup d'alert pour moi!

Non, vraiment, je peux pas blairer le JS. Pour moi c'est anti rentable, à chaque fois que je l'ai touché j'y ai perdu du temps sans réaliser ce que je voulais vraiment.

onur (./41) :
Perso je n'ai pas eu à faire à des casts dynamiques dans mes progs C++ (cf le code d'ETP qui est public maintenant), je parle de ça parce que j'en vois tout le temps dans les codes des autres et sur internet.

Et alors, si tu trouves un mauvais code dans un langage c'est que le langage est pourri ? Que les gens codent n'importe comment, c'est un autre problème et ça les regarde, mais je ne vois pas trop en quoi ça appuie ton ./35

Ce que je dis, c'est que meme quand c'est du compilé, on est amené à vérifier si le pointeur est null, si le fichier qu'on écrit est bien généré, et vérifier d'autres aléas de ce genre. Et c'est pareil en JS: quand c'est critique, on hésite pas à ajouter une vérification typeof(x)=="number"

Oui mais ce genre de vérifications, on s'en tape quand même deux fois plus en JS où tout est autorisé que dans un langage plus strict où une bonne partie des vérifications "basiques" (types & co) n'ont pas à être effectuées puisque le compilateur s'en charge.

squalyl (./44) :
c'est encore plus sale le débogage à coup d'alert pour moi!

Avec des outils adaptés, on peut executer pas à pas aussi et lire la valeur actuelle des variables.

Zephyr (./45) :
Oui mais ce genre de vérifications, on s'en tape quand même deux fois plus en JS où tout est autorisé que dans un langage plus strict où une bonne partie des vérifications "basiques" (types & co) n'ont pas à être effectuées puisque le compilateur s'en charge.

Non pas "deux" fois plus. Normalement, quand tu as bien "designé" ton projet comme tu dis, en C++ ou autre tu as plus besoin de cast dynamique et en js, tu n'as plus besoin de ce genre de survérification.

squalyl (./44) :
c'est encore plus sale le débogage à coup d'alert pour moi!

Non, vraiment, je peux pas blairer le JS. Pour moi c'est anti rentable, à chaque fois que je l'ai touché j'y ai perdu du temps sans réaliser ce que je voulais vraiment.

Heureusement qu'il y a de vrai débugguer pour le JS...

ah ué? jamais trouvé de truc qui me plaise pour ma part.

je sais que visual studio le fait avec IE/FF. Mais bon, faut l'avoir quoi.

squalyl (./48) :
ah ué? jamais trouvé de truc qui me plaise pour ma part.

FireBug pour Fx, Safari en inclu un de base, Visual studio (san garantie) et j'en passe d'autres sous linux

onur (./46) :
Non pas "deux" fois plus. Normalement, quand tu as bien "designé" ton projet comme tu dis, en C++ ou autre tu as plus besoin de cast dynamique et en js, tu n'as plus besoin de ce genre de survérification.

Ah ok je viens de comprendre ce que tu voulais dire. Alors oui effectivement si tu es vraiment extrêmement rigoureux, a priori il n'y a pas besoin non plus en JS de multiplier les vérifications. En pratique (et je pense que c'est dans ce sens que nitro en parlait), ça devient probablement très difficile sur des gros projets.

Zephyr (./40) :
Je n'avais même pas pensé au Java à vrai dire, mais l'absence de templates qui oblige à utiliser des dynamic casts c'est un manque du langage, pas un problème lié aux langages typés à la compilation. Pour rappel, quand tu utilises un cast dynamique, c'est que tu en es arrivé à un point de ton code où tu as perdu l'information sur la nature de ce que tu manipules : sauf exceptions, c'est une erreur de conception.

Et bon dieu que c'est dur à faire comprendre!

Zephyr (./51) :

onur (./46) :
Non pas "deux" fois plus. Normalement, quand tu as bien "designé" ton projet comme tu dis, en C++ ou autre tu as plus besoin de cast dynamique et en js, tu n'as plus besoin de ce genre de survérification.

Ah ok je viens de comprendre ce que tu voulais dire. Alors oui effectivement si tu es vraiment extrêmement rigoureux, a priori il n'y a pas besoin non plus en JS de multiplier les vérifications. En pratique (et je pense que c'est dans ce sens que nitro en parlait), ça devient probablement très difficile sur des gros projets.

et y'en a même qui vont encore faire des tests unitaires, des tes fonctionnels pour encore vérifier une fois que ce qu'ils ont codé est bon.
Ca me rappelle une discussion sur ce même débat, typé vs dynamique. L'un remarquait qu'il passait son temps à faire des tests unitaires (il aimait presque faire ca .... ). Et il trouvait qu'en fait le typage l'emmerdait car si il avait un pb de structure de données, ses tests unitaires le détecteraient. Moi je préfère typer et faire moins de test unitaire. Et même typer c'est aussi quelques fois documenter.

Bon, pour répondre au sujet initiale :

Le JavaScript est un langage que je ne connais vraiment pas bien (et ça me manque, mais il est très difficile d'avoir de vrais formations correctes à ce niveau).
Visuellement, je n'accroche pas. Mais, là aussi, c'est probablement parce que je le vois dans des usages liés aux applications web, où on fait du JS un peu en vrac, sans se soucier de la lisibilité du code (mais il n'empêche que j'ai quand même plus de mal à lire un programme fait en JS qu'en Java, par exemple).

C'est à peu près tout ce que j'ai à dire sur la question

- les formations pour apprendre un language... je suis vraiment dubitatif, se plonger dedans et y passer des heures oki plutot
- JS est carrement moins verbeux que Java, donc ca peut etre moins facile a lire ouep, mais c'est comme tout, ca depend avant tout du dev qui a fait le source

moi je trouve le js joli

Rien de tel que de lire la spec pour apprendre un langage (et je suis sérieux... enfin bon ok pas tout de suite tout de suite, faut déjà coder deux-trois petits trucs à partir d'exemples ou tutos, mais bon si on veut vraiment savoir utiliser le langage ^^)

En fait, c'est aussi et surtout parce que je n'ai jamais eu de projet nécessitant vraiment beaucoup de js... donc jamais de vraie motivation pour m'y mettre.

hibou (./53) :
Moi je préfère typer et faire moins de test unitaire.

Et moi je préfère typer et faire aucun test unitaire.

et corriger les bugs uniquement après que les utilisateurs se soient plains?

Même pas besoin. Kevin ne fait pas de bug, Il ne fait que des features incomprises