[F] [mOved] Mon langage est mieux que le tien - Page 16

Ouais c'est la même chose avec coffeescript, tu retournes la dernière valeur d'expression (un peu comme la TI89 par défaut, ou alors un registre r0 qui contiendrait par hasard un truc utile à la fin d'une fonction en ASM).
Perso j'ai du mal à voir l'utilité mais ça fait plus "fonctionnel" donc bon c'est le futur, toussa…

En-dehors du fait que c'est moins clair, il reste un problème : contrairement au "vrai" return, on ne peut pas avoir plusieurs points de sortie, parce que l'exécution ne s'arrête pas.

D'aucuns te diraient que c'est très bien comme ça, n'est-ce pas Ximoon ?

(j'ai pensé très fort à lui, ouais ^^)

(les returns multiples c'est effectivement pas très beau )

(on ne va pas relancer le troll, mais je maintiens que dans certains cas, c'est bien plus propre que les alternatives)

(Mmmm )

Avoir quelques early return, par exemple pour les paramètres invalides, puis un seul return à la fin, se défend largement, en effet. Ca limite la profondeur d'indentation ou l'usage du goto.

(oui, les early à la rigueur, je suis d'accord que c'est plus clair, d'où le mmm )

Godzil (./450) :
Le fait qu'il y ai des {} et ; rends le language plus simple a parser, moins verbeux

Erreur, très cher !
Les ; ne sont pas (toujours) obligatoires en JavaScript, donc c'est pas "si simple" à parser.

Sinon pour le reste dans l'ensemble, je suis d'accord avec toi ^^

GC: je ne pensais pas forcement au JS en parlant des {} et ;

Pour les ; soit c'est obligatoire, soit ca ne l'est pas. On ne fait pas entre deux.


Sinon un seul return et goto FTW

(rien de mieux qu'un seul point de sortie facilement identifiable, qu'on peux facilemetn hooker ou surveiller a coup de printf... )

Zeph (./430) :
Ben non, en l'occurrence c'est simplement que Object est une structure qui n'accepte que des strings comme clé, c'est sa définition. N'importe quelle surcouche typée se basera là-dessus et n'utilisera Object que dans ce cas (ce qui n'empêche par ailleurs pas qu'utiliser n'importe quoi d'autre, comme par exemple des nombres, soit quand même défini par le standard).

Mais Object est aussi la seule structure qui ressemble vaguement à une table de hash en JS…
Mais bon, une table de hash dont certaines clefs sont accessibles directement (table.my_key), d'autres uniquement avec des [] (table['my key']), et qui ne possède pas de méthodes extrêmement complexes telles que .size().

Ça ressemble à une table de hash, ça a l'odeur d'une table de hash, c'est vendu comme une table de hash, ça se comporte presque comme une table de hash, il n'y a pas d'autre structure de table de hash, mais ce n'est pas une table de hash… Et après, on s'étonne qu'on l'utilise comme une table de hash

Le JS pousse à l'erreur de tous les côtés. Certes, on peut les éviter quand on connaît toutes les subtilités du langages et en sachant qu'il ne faut surtout pas faire confiance à 99% des sites web qui parlent de JS. Perso, j'appelle ça un mauvais langage. Le seul disponible, mais mauvais quand même.

Ça n'est à aucun moment vendu comme une table de hash, ça c'est ton interprétation

C'est précisément pour cette raison que JS te fournit un autre objet "Array" qui est une extension de "Object" et fournit les mécanismes habituels d'un tableau. Si tu veux une table de hash rien de plus facile que de procéder exactement de la même façon. Premier lien que je trouve sur Google à ce sujet, et qui semble correspondre à ce que tu veux : http://www.mojavelinux.com/articles/javascript_hashes.html.

Tu es quand même subtilement de mauvaise foi

D'une part, 99% des sites web qui parlent de JS vont te dire d'utiliser object comme une table de hash
D'autre part, object a une méthode keys() qui fournit la liste des attributs (mais la méthode s'appelle keys), les valeurs des attributs sont accessibles par [] (comme pour les tables de hash dans 99% des langages de programmation).
D'ailleurs, même le site que tu proposes :

A short example of an associative array (hash table) in JavaScript is as follows:
var h = new Object(); // or just {}

Et pour avoir une structure qui donne la taille, on refait une « classe », qui va stocker les propriétés… dans un Object.

Sinon, petite citation trouvée sur un blog amateur (la doc JS chez Mozilla) :

Les objets en JavaScript sont simplement des collections de paires nom-valeur. Dans ce sens, ils sont similaires aux :

dictionnaires en Python,
hashs en Perl et Ruby,
tables de hashing en C et C++,
HashMaps en Java,tableaux associatifs en PHP.

Mais non, c'est uniquement mon interprétation


Et je reprends mon argument plus haut : un langage qui pousse à l'erreur 99% des gens *est* un mauvais langage.

flanker (./464) :
Et pour avoir une structure qui donne la taille, on refait une « classe », qui va stocker les propriétés… dans un Object.

Bah oui, c'est bien le but. Après je ne sais pas ce que tu appelles "hash table" exactement, tu semblais partir du principe que c'est une structure qui propose une méthode "size()". Ça n'est pas le cas de Object, donc si tu veux cette propriété tu dois implémenter ton type et l'appeler HashMap si ça te chante. Ou bien tu n'en as pas besoin, une simple association clé/valeur te convient, et dans ce cas Object est là.

Je ne vois pas franchement ce qu'il y a de confus ici, ni d'où sortent tes 99% de gens perdus ? Si je reprends ton argument, la seule chose qui te déplait c'est qu'il n'y ait pas de méthode "size()" par défaut sur Object ? Quelle serait la justification de ce cas particulier ? Au contraire je trouve plutôt sensé d'avoir un type racine réellement vide. Le terme "similaire" de ta citation a un sens assez large, puisqu'il s'agit comme c'est indiqué d'une collection de paires nom-valeur et rien de plus.

oh non : il n'y a pas de méthode size, certains attributs sont accessibles directement mais pas tous, on ne peut utiliser que des string comme clef, … Et dès qu'on veut une vrai hashtable, il faut le faire à la main vu que la lib standard est moisie (franchement, quel autre langage ne propose pas de table de hash ?).

(puis je croyais que ce n'était jamais vendu comme une table de hash ? )

Il n'y a pas de lib standard en JS en-dehors des quelques types builtin (string, array, regex), ça fait partie des choix de design du langage, entre autres parce qu'il est difficile d'en définir une en-dehors de tout contexte. À quoi doit ressembler la lib standard de quelque chose qui sert d'interface pour MongoDB, de langage de script dans des pages web, de techno serveur-side et d'outil pour faire des macros dans OpenOffice ? jQuery est un outil très pratique pour faire du web par exemple, mais n'aurait aucun sens dans node.js.

Sinon pour "table de hash", comme je viens de le dire ça dépend de ta définition. Si pour toi une table de hash est quelque chose d'autre que des clé/valeurs, alors Object n'est pas une table de hash. Comme il est trivial d'implémenter ce que tu appelles une table de hash avec Object, je ne vois pas en quoi c'est un problème.

De même je ne comprends pas ta fixation sur les clés des Object qui doivent être des strings. Il est défini comme ça, à quel moment est-ce quelqu'un t'a laissé croire qu'il en serait autrement ? Tu as déjà hurlé au scandale parcequ'utiliser des lists en tant que clés dans des dictionnaires en Python ne faisait pas ce à quoi tu t'attendais alors que ça fonctionne très bien avec des tuples ? Pourtant je ne vois pas en quoi ça serait une convention plus légitime.

./467 >

(je vais arrêter vu que de toute façon, on n'arrivera jamais à se convaincre mutuellement )

rien à voir, mais je suis tombé sur un LinuxMag récent, avec un article qui compare les perfs de différents langages sur des algos complexes (le quicksort, en l'occurrence).
Pour bencher, l'auteur prend 1 000 mesures de l'exécution (sur un petit jeu de données).

Mais pour Java (au moins, je n'ai pas tout lu), il lance 1 000 fois le programme

The Effect of Programming Language On Software Quality
http://macbeth.cs.ucdavis.edu/lang_study.pdf (from http://developers.slashdot.org/story/14/11/05/0530228/the-effect-of-programming-language-on-software-quality )

./469 : si, il faut continuer jusqu'à ce que l'un de nous deux soit convaincu sinon c'est pas un vrai troll !!1 ()
./470 : c'est TypeScript le langage dans lequel on fait le moins d'erreur ? voilà de quoi alimenter encore le débat pendant un moment

flanker (./466) :
(franchement, quel autre langage ne propose pas de table de hash ?).

Mmm... Le C ?

Va pas chercher loin : le 68k

Si, c'est dans gtools

Oui, écrit par un membre d'honneur d'une team célèbre pour son infatigable travail

Mouarf

C'est pas cool, ouais… Je retiens pour le jour où je serais confronté au même problème.

Non, je n'ai pas d'explication
Ça ne semble pas être un fake, ç'a été posté par un habitué des forums de TheDailyWTF.