/* Topic des codeurs [8] */

grim7reaper · Le 27/01/2013, à 05:51

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)

Elzen · Le 27/01/2013, à 15:18

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)

grim7reaper · Le 27/01/2013, à 15:54

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à.

Elzen · Le 27/01/2013, à 16:14

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…

Rolinh · Le 27/01/2013, à 17:10

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>

Elzen · Le 27/01/2013, à 19:34

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

Pour ceux qui veulent tester mon pendu…

Rolinh · Le 27/01/2013, à 21:20

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

dans les colonnes du sites

Il marche bien ton pendu.

:!pakman · Le 27/01/2013, à 21:27

Ouaip, le pendu fonctionne bien

Elzen · Le 27/01/2013, à 21:49

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

grim7reaper · Le 27/01/2013, à 21:51

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

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.

Elzen · Le 27/01/2013, à 22:04

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

The Uploader · Le 27/01/2013, à 22:13

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...

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)

Rolinh · Le 27/01/2013, à 22:37

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.

grim7reaper · Le 27/01/2013, à 22:38

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

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

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)

The Uploader · Le 27/01/2013, à 22:45

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.

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

Elzen · Le 27/01/2013, à 22:54

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)

grim7reaper · Le 27/01/2013, à 23:04

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

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é…)
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 ?

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)

HP · Le 28/01/2013, à 00:02

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)…

The Uploader · Le 28/01/2013, à 12:01

Ça va faire plaisir au Rouge :
Le créateur de Ruby explique l'influence d'Emacs sur le langage et reconnait que l'éditeur a changé sa vie

Elzen · Le 28/01/2013, à 12:11

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 (Mais j'aime bien les parenthèses (c'est cool, les parenthèses (même hors programmation )))

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 ?

Rolinh · Le 28/01/2013, à 12:14

Elzen a écrit :

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

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

Dr Le Rouge · Le 28/01/2013, à 12:24

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

Elzen · Le 28/01/2013, à 12:25

Elzen a écrit :

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

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

Rolinh · Le 28/01/2013, à 12:53

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

Elzen · Le 28/01/2013, à 14:12

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)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pied de page des forums