Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#576 Le 27/01/2013, à 05:51

grim7reaper

Re : /* Topic des codeurs [8] */

Javascript :

> ['10','10','10','10','10'].map(parseInt)
[10, NaN, 2, 3, 4]

WTF…
(Bon il y a une explication à ça, mais c’est quand même un comportement de merde pas du tout intuitif…)

Source.

Dernière modification par grim7reaper (Le 27/01/2013, à 05:56)

Hors ligne

#577 Le 27/01/2013, à 15:18

Elzen

Re : /* Topic des codeurs [8] */

Ouaip, en effet. T'aurais des détails ?

Sinon, à propos de JavaScript, justement : j'suis en train de me bricoler un petit jeu de pendu, et je me disais que je pourrais aller chercher des mots au hasard dans le Wiktionnaire. Sauf que la requête AJAX entre deux sites, ça n'a pas l'air de marcher très fort.
Quelqu'un aurait une suggestion, ou bien pensez-vous qu'il serait préférable que je mette une réserve de mots à utiliser dans le JavaScript ? (je préfère éviter de rajouter un truc ad hoc côté serveur)

Pour info, mon code de test :

var xhr = new XMLHttpRequest();
xhr.open("GET", "http://toolserver.org/~darkdadaah/wiktio/outils/hasard.php?langue=fr", true);
xhr.send(null);
xhr.onreadystatechange = function() {
	if (xhr.readyState == 4)
		alert(xhr.responseText);
}

Qui apparemment me renvoie une chaîne vide, ou un truc du genre (idem pour les autres trucs que j'essaye de chercher dans l'objet)

Hors ligne

#578 Le 27/01/2013, à 15:54

grim7reaper

Re : /* Topic des codeurs [8] */

Elzen a écrit :

Ouaip, en effet. T'aurais des détails ?

Ouais.
map passe la valeur et l’index, et c’est là le truc un peu foireux je trouve.
parseInt prends deux arguments : la chaîne à convertir et la base.
10, 0 => par défaut, 0 signifie base 10 (comme strtol en C) donc ça parse bien.
10, 1 => 10 est pas un nombre en base unaire, donc ça chie.
10, 2 => 10 en binaire ça donne 2.

Voilà.

Hors ligne

#579 Le 27/01/2013, à 16:14

Elzen

Re : /* Topic des codeurs [8] */

Logique, en effet.

Je n'connaissais pas la fonction map ; mais de toute façon, d'une manière générale, j'n'aime pas trop de genre d'appels, je préfère les boucles, ç'plus lisible.

Sinon, pour mon pendu, disons que je vais mettre des mots en dur pour le moment, et que je modifierait pour ajouter la récupération auto plus tard…

Hors ligne

#580 Le 27/01/2013, à 17:10

Rolinh

Re : /* Topic des codeurs [8] */

Ah ouais, faut le savoir. Après, c'est facile d'avoir le comportement attendu:

js> x = ["10", "10", "10", "10", "10"];
["10", "10", "10", "10", "10"]
js> function toInt(x) { return parseInt(x); }
js> x.map(toInt)
[10, 10, 10, 10, 10]
js> 

Hors ligne

#581 Le 27/01/2013, à 19:34

Elzen

Re : /* Topic des codeurs [8] */

Yep, en effet ; mais ça reste moins chouette qu'une boucle tongue

Pour ceux qui veulent tester mon pendu…

Hors ligne

#582 Le 27/01/2013, à 21:20

Rolinh

Re : /* Topic des codeurs [8] */

http://fadrienn.irlnc.org/galeries/jeux/pendu/ a écrit :

dans les colonnes du sites

Il marche bien ton pendu. smile

Hors ligne

#583 Le 27/01/2013, à 21:27

:!pakman

Re : /* Topic des codeurs [8] */

Ouaip, le pendu fonctionne bien smile


...

Hors ligne

#584 Le 27/01/2013, à 21:49

Elzen

Re : /* Topic des codeurs [8] */

Faute de frappe corrigée, et merci pour les retours ^^

Hors ligne

#585 Le 27/01/2013, à 21:51

grim7reaper

Re : /* Topic des codeurs [8] */

Rolinh a écrit :

Ah ouais, faut le savoir. Après, c'est facile d'avoir le comportement attendu:

js> x = ["10", "10", "10", "10", "10"];
["10", "10", "10", "10", "10"]
js> function toInt(x) { return parseInt(x); }
js> x.map(toInt)
[10, 10, 10, 10, 10]
js> 

Oui c’est pas compliqué, ce que je reproche c’est le comportement de map
Tu connais un autre langage qui implémente map comme ça ?
C++ ne le fait pas, Haskell ne le fait pas, Python ne le fait pas, Ruby ne le fait pas, Perl ne le fait pas, …

Donc c’est vraiment pour le plaisir de faire un langage avec les pieds (ils veulent peut-être concurrencer PHP au niveau « langage qui se bat contre le développeur »…).



Elzen a écrit :

Yep, en effet ; mais ça reste moins chouette qu'une boucle tongue

map à un nombre certains d’avantages sur une boucle.
Mais bon j’ai cru comprendre que ta préférence était du à un ressenti visuel personnel, pas technique donc y’a pas à débattre.

Hors ligne

#586 Le 27/01/2013, à 22:04

Elzen

Re : /* Topic des codeurs [8] */

grim7reaper a écrit :

Donc c’est vraiment pour le plaisir de faire un langage avec les pieds (ils veulent peut-être concurrencer PHP au niveau « langage qui se bat contre le développeur »…).

Y a quand même une différence fondamentale avec PHP, qui est le fait que, pour JavaScript, il existe une norme. Par contre, je ne sais pas si ce comportement-là est posé par la norme ECMAScript, ou si c'est venu autrement.

Après, sur le principe, renvoyer l'indice en même temps que la valeur ne me semble pas particulièrement saugrenu… ça peut même éventuellement être assez intéressant. D'une manière générale, j'ai tendance à penser que ce n'est pas parce que seul un langage présente une caractéristique donnée que cette caractéristique est forcément mauvaise.

grim7reaper a écrit :

map à un nombre certains d’avantages sur une boucle.
Mais bon j’ai cru comprendre que ta préférence était du à un ressenti visuel personnel, pas technique donc y’a pas à débattre.

Ma préférence est effectivement due à un ressenti visuel personnel ; cependant, j'veux bien que tu développes les avantages en question, histoire que je sache smile

Hors ligne

#587 Le 27/01/2013, à 22:13

The Uploader

Re : /* Topic des codeurs [8] */

grim' a écrit :

Donc c’est vraiment pour le plaisir de faire un langage avec les pieds (ils veulent peut-être concurrencer PHP au niveau « langage qui se bat contre le développeur »…).

Au moins pour améliorer l'aspect visuel du langage, il y a le sucre syntaxique de coffeescript... neutral

grim' a écrit :

map à un nombre certains d’avantages sur une boucle.

Tiens bizarre le bench de map vs each en Ruby (au départ arrmap a une taille de 101):

irb(main):017:0> Benchmark.bm do |x|
irb(main):018:1* x.report {arrmap.map { |str| str + " prout!" }}
irb(main):019:1> x.report {arrloop.each do |str| ; str + 'prout!'; end }
irb(main):020:1> end
       user     system      total        real
   0.000000   0.000000   0.000000 (  0.000074)
   0.000000   0.000000   0.000000 (  0.000056)
=> [  0.000000   0.000000   0.000000 (  0.000074)
,   0.000000   0.000000   0.000000 (  0.000056)
]
irb(main):021:0> arrmap.first
=> "argh!"
irb(main):022:0> Benchmark.bm do |x|
irb(main):023:1* x.report {arrmap.map { |str| str + " prout!" }}
irb(main):024:1> x.report {arrmap.each do |str| ; str + "prout!"; end }
irb(main):025:1> end
       user     system      total        real
   0.000000   0.000000   0.000000 (  0.000093)
   0.000000   0.000000   0.000000 (  0.000053)
=> [  0.000000   0.000000   0.000000 (  0.000093)
,   0.000000   0.000000   0.000000 (  0.000053)
]
irb(main):026:0> arrmap
=> ["argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!", "argh!"]
irb(main):027:0> 10.times do ; arrmap += arrmap ; end
=> 10
irb(main):028:0> arrmap.size
=> 103424
irb(main):029:0> Benchmark.bm do |x|
irb(main):030:1* x.report {arrmap.map { |str| str + " prout!" }}
irb(main):031:1> x.report {arrmap.each do |str| ; str + "prout!"; end }
irb(main):032:1> end
       user     system      total        real
   0.110000   0.000000   0.110000 (  0.107851)
   0.050000   0.000000   0.050000 (  0.049461)
=> [  0.110000   0.000000   0.110000 (  0.107851)
,   0.050000   0.000000   0.050000 (  0.049461)
]
irb(main):033:0> 

j'croyais que l'un des avantages de map était la vitesse d'exécution ?
(comme quoi ça dépend de l'implémentation : Par exemple pour Perl)

Dernière modification par The Uploader (Le 27/01/2013, à 22:42)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#588 Le 27/01/2013, à 22:37

Rolinh

Re : /* Topic des codeurs [8] */

grim7reaper a écrit :

Tu connais un autre langage qui implémente map comme ça ?

Non, aucun. C'est clair que j'aurais moi aussi mis les pieds dedans avec un truc pareil et me serais certainement arraché quelques cheveux. ^^
La bonne nouvelle c'est que je n'ai jamais eu besoin de faire du javascript intensivement et que je ne connais donc qu'à peine ce langage. Mes cheveux peuvent donc rester sur ma tête et c'est très bien ainsi. tongue

Hors ligne

#589 Le 27/01/2013, à 22:38

grim7reaper

Re : /* Topic des codeurs [8] */

Elzen a écrit :

Après, sur le principe, renvoyer l'indice en même temps que la valeur ne me semble pas particulièrement saugrenu… ça peut même éventuellement être assez intéressant.

Mouais, ça me gêne un peu quand même. Le concept de map est bien plus générique que ça.
map s’applique à des collections, pas forcément des tableaux ou des listes (même si c’est le cas le plus fréquent) et pour certaines collections je ne
suis pas sûr qu’il y ai toujours un concept d’index pertinent.

Mais admettons, pourquoi pas.
Cela dit, il faudrait que ça soi implémenté mieux que ça.
Car là, on a quand mêle une interaction très malvenue hmm

Elzen a écrit :

D'une manière générale, j'ai tendance à penser que ce n'est pas parce que seul un langage présente une caractéristique donnée que cette caractéristique est forcément mauvaise.

Bien sûr, c’est à voir au cas par cas.
Mais là je trouve clairement le résultat pas satisfaisant. Alors oui, quand on le sait on peu l’éviter mais je trouve ça piégeux quand même.

Elzen a écrit :
grim7reaper a écrit :

map à un nombre certains d’avantages sur une boucle.
Mais bon j’ai cru comprendre que ta préférence était du à un ressenti visuel personnel, pas technique donc y’a pas à débattre.

Ma préférence est effectivement due à un ressenti visuel personnel ; cependant, j'veux bien que tu développes les avantages en question, histoire que je sache smile

Bah une boucle, c’est une boucle.
On n’a pas d’autres info mis à part qu’on répète un traitement.
Tu vois un while ou un for, tu sais pas trop à quoi t’attendre (et le compilo/interpréteur/VM non plus).
Le pire dans ce cas, étant le while bien sûr.
Un for, sous peine d’en respecter la sémantique, donne déjà plus d’info. On applique un traitement de A à B. C’est déjà mieux que le while.
Quand tu vois un map tu es sûr de deux choses :
- tu vas traiter tous les éléments de la collections (prédiction de saut bien plus aisée).
- chaque éléments va être traité indépendamment des autres (éventuelle parallèlisation).
Donc déjà d’un point de vue humain, c’est plus facile à lire. Un map, tu sais à quoi t’attendre : pas de break surprise, pas de relation caché, etc.
Et du point de vue compilo/interpréteur/VM ça peut aider à faire des trucs sympa.
Et encore plus dans les langages fonctionnels, style Haskell, qui supportent le composition de fonction. Genre :

(map f) ∘ (map g) <==> map (f ∘ g)

Après, tout ce que tu fais avec un map peut-être fait avec un for, l’inverse n’étant pas vrai.
De même pour for et while (bien que là la différence soit plus conceptuelle que réelle, la majorité des langages ne forçant pas le respect de la sémantique du for…).
Donc oui, on peut tout faire avec des boucles (en poussant plus loin, goto suffit en fait).
Mais moi je suis partisan pour utiliser la structure adapté à la sémantique de ce que l’on fait. On y gagne en lisibilité (et parfois performance, alors pourquoi s’en privé).
Après, je peux comprendre que beaucoup de gens étant bercé par l’impératif et n’ayant que peu côtoyé le fonctionnel préfère les boucles.
Mais je trouve ça un peu dommage quand même ^^



The Uploader a écrit :

j'croyais que l'un des avantages de map était la vitesse d'exécution ?

En théorie oui, tu peux avoir un gain.
En pratique, ça dépend comment le langage le considère.
Typiquement, en Python aussi je ne suis pas sûr que tu y gagnes  vu l’amour de GvR pour le fonctionnel (pas d’optim’ tail-call, préfère les boucles à map, filter, etc.)
Je trouve ça dommageable, mais bon chacun le fait comme il le sent.

Cela dit, dans ton cas la différence pourrait venir de là :

http://stackoverflow.com/questions/9586989/difference-between-map-and-each a écrit :

each simply iterates over the given enumerable, running the block for each value. It discards the return value of the block, and each simply returns the original object it was called on.
[…]
map, however, sets the current element being iterated over to the return value of the block, and then returns a new object with those changes:

Dernière modification par grim7reaper (Le 27/01/2013, à 22:45)

Hors ligne

#590 Le 27/01/2013, à 22:45

The Uploader

Re : /* Topic des codeurs [8] */

J'viens de découvrir que j'ai pas mal utilisé Array#map en Ruby sous le nom de Array#collect.

Moui parfois j'ai un peu l'impression que les méthodes ayant plusieurs noms pour la même chose spa forcément un avantage pour les reconnaitre.

edit : merci pour les infos. J'adore avoir des détails. smile

Dernière modification par The Uploader (Le 27/01/2013, à 22:46)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#591 Le 27/01/2013, à 22:54

Elzen

Re : /* Topic des codeurs [8] */

Bah j'pense que ce qui me dérange, visuellement, dans map, c'est le fait d'appeler une fonction en lui passant une autre fonction comme paramètre. Ça doit venir de ma formation en Java, j'n'ai pas pris l'habitude de les manipuler comme n'importe quel autre élément. Ceci dit, c'est vrai que je m'y suis habitué pour les setTimeout en JavaScript et pour les connect en Python/Glib, donc je devrais pouvoir m'y faire pour ça aussi.

L'aspect de possible parallélisation est effectivement bien sympa, ouaip, j'essayerai d'y penser…

Et t'fais bien de me rappeler que ça fait un moment que je dis que je dois me mettre sérieusement au fonctionnel, il serait peut-être temps que j'y pense. À votre avis, j'attaque plutôt par Lisp ou par Haskell ? (Sachant que j'ai déjà des bases en Lisp, même si elles commencent à être assez lointaines)

Hors ligne

#592 Le 27/01/2013, à 23:04

grim7reaper

Re : /* Topic des codeurs [8] */

Elzen a écrit :

Bah j'pense que ce qui me dérange, visuellement, dans map, c'est le fait d'appeler une fonction en lui passant une autre fonction comme paramètre.

Bah si tu fait du fonctionnel ça te choquera plus big_smile

Franchement, Java est très mal fichu sur ce point là. Il veut taper dans le 100% objet (vu qu’il veut tout mettre dans des classes, à un point que ça en est ridicule parfois…). Mais à côté de ça, on a les types primitifs qui ne sont pas des objets, les fonctions idem (faut passer par un foncteur, mais sans surcharge de l’opérateur () ça induit encore de la verbosité, mais avec Java on est habitué…) hmm
Pour le coup, le modèle objet dans python est bien plus souple. Même C++ est plus souple sur ce côté là.

Elzen a écrit :

À votre avis, j'attaque plutôt par Lisp ou par Haskell ? (Sachant que j'ai déjà des bases en Lisp, même si elles commencent à être assez lointaines)

Tu peux aussi te poser la question autrement : tu veux un typage dynamique qui peut potentiellement laisser plein de trucs mais est très souple ou tu veux un système de typage statique mais avec inférence de type ?
Lisp ou Haskell ?
Parenthèse ou pas ? big_smile

Franchement, j’aime bien le système de type d’Haskell il est strict mais extrêmement puissant. Je pense que ça vaut le coup d’y jeter un œil. Mais c’est toi qui voit.

Dernière modification par grim7reaper (Le 27/01/2013, à 23:06)

Hors ligne

#593 Le 28/01/2013, à 00:02

HP

Re : /* Topic des codeurs [8] */

The Uploader a écrit :

J'viens de découvrir que j'ai pas mal utilisé Array#map en Ruby sous le nom de Array#collect.

Ouais… Ruby est sympa sur ce coup (et bien d'autres)…


cat /dev/urandom >/dev/null 2>&1 #github

Hors ligne

#594 Le 28/01/2013, à 12:01

The Uploader

Re : /* Topic des codeurs [8] */


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#595 Le 28/01/2013, à 12:11

Elzen

Re : /* Topic des codeurs [8] */

grim7reaper a écrit :

Tu peux aussi te poser la question autrement : tu veux un typage dynamique qui peut potentiellement laisser plein de trucs mais est très souple ou tu veux un système de typage statique mais avec inférence de type ?

Pas la moindre idée yikes (Mais j'aime bien les parenthèses smile (c'est cool, les parenthèses cool (même hors programmation big_smile)))

grim7reaper a écrit :

Franchement, j’aime bien le système de type d’Haskell il est strict mais extrêmement puissant. Je pense que ça vaut le coup d’y jeter un œil. Mais c’est toi qui voit.

Bah j'pense qu'à terme, je vais essayer de me pencher un peu sur les deux, ne serait-ce que pour ma curiosité personnelle ; ç'juste qu'il faut bien débuter, je n'vais pas commencer par les deux en même temps.

On va prendre une autre approche : vous me conseillez quoi pour commencer, dans un cas et/ou dans l'autre ?

Hors ligne

#596 Le 28/01/2013, à 12:14

Rolinh

Re : /* Topic des codeurs [8] */

Elzen a écrit :

Pas la moindre idée yikes (Mais j'aime bien les parenthèses smile (c'est cool, les parenthèses cool ...

T'as jamais touché à Lisp, Scheme ou autre toi... tongue
Tu risques de vite trouver moins drôle. ^^

Hors ligne

#597 Le 28/01/2013, à 12:24

Dr Le Rouge

Re : /* Topic des codeurs [8] */

Le principal intérêt du Lisp c'est que ça permet de comprendre l'emacs lisp et donc de faire ses propres fonctions pour emacs tongue


C'est deux suites de Cauchy qui veulent aller à la soirée 'no limit'. Hélas, à l'entrée le videur leur dit : "désolé, c'est complet !".
mon site perso (π²/6.fr) et mon blog

Hors ligne

#598 Le 28/01/2013, à 12:25

Elzen

Re : /* Topic des codeurs [8] */

Elzen a écrit :

(Sachant que j'ai déjà des bases en Lisp, même si elles commencent à être assez lointaines)

tongue

Je maintiens qu'imbriquer les parenthèses m'a toujours semblé fun, y compris et surtout à l'époque où je faisais du Lisp tongue

Hors ligne

#599 Le 28/01/2013, à 12:53

Rolinh

Re : /* Topic des codeurs [8] */

ah voui, j'avais lu ça hier soir en plus >_<
Bah alors à ce moment je dois dire que je ne te comprend pas ^^

Hors ligne

#600 Le 28/01/2013, à 14:12

Elzen

Re : /* Topic des codeurs [8] */

Il paraît que je ne pense pas de la même façon que la plupart des gens.

Sinon, pour en revenir à la remarque de grim7reaper ci-dessus, j'pense que je serais plus à l'aise en commençant avec un typage statique, ce qui semble orienter en premier lieu vers le Haskell.

Tiens d'ailleurs, il y a moyen de faire du typage statique en Python ? Parce que le Python a pas mal de qualités pédagogiques, mais je trouve que le typage dynamique est moins bon sur ce plan-là (un truc bien carré avec déclaration de variables et types associés, ça me semble plus cadré pour débuter)

Hors ligne