Zerosquare (./2852) :Oh mais j'ai confiance, ce n'est pas parce qu'une chose est plus simple d'utilisation, ou d'apparence plus élégante, qu'elle en devient plus séduisante
Attention, si on en croit Flan, une fois que tu auras goûté au Python tu ne supporteras plus le PHP
Zeph (./2841) :Il n'y a pas que ça dans jQuery, quand même ^^ (même si c'est bien sûr le principal usage)
Pour les usages "page web" la bibliothèque telle que définie par le w3c est déjà pas mal. Tu citais par exemple jQuery, normalement il n'y a plus besoin de s'en servir depuis que document.querySelector est disponible partout (d'ailleurs c'est en partie pour ça que la lib est en train de mourir doucement).
Je ne suis doublement pas d'accord :flanker (./2839) :Mais justement : à aucun moment on ne t'a prétendu qu'il s'agissait de près ou de loin d'une table de hash, c'est simplement toi qui a tiré cette conclusion à partir de ta connaissance d'autres langages.
Et voilà, on retrouve une habitude de JS : ça ressemble à une table de hash, ça a le goût d'une table de hash, ça a l'odeur d'une table de hash, mais ce n'est pas une table de hash.
Je peux te donner quelques exemples, mais avant il me semble plus important de répéter mon argument précédent : au lieu d'essayer de résoudre un problème, on essaie de reproduire un moyen. Plutôt que de trouver comment implémenter ce que je veux en utilisant l'héritage prototypal on essaie de l'implémenter avec des classes, mais comme ça n'existe(ait) pas en JS on se retrouve à implémenter un machin hybride qui fait presque comme des classes mais en utilisant les prototypes de JS. Je pense que l'approche "je veux implémenter de cette façon parce que c'est comme ça que je l'aurais fait dans le langage que je connais" n'est pas efficace. Du coup prendre un cas d'école de l'utilisation des classes et essayer de l'écrire en JS est idiot : bien sûr que ça sera moche, mais quel problème essaie-t-on de résoudre ? J'imagine que la réponse n'est pas "je veux une classe Client qui hérite de Person" mais quelque chose d'un peu plus concret, qui peut très certainement s'écrire de 1001 autres façons. C'est pas comme si le C était à court de solutions pour implémenter tout et n'importe quoi, et pourtant il n'y a ni classes ni prototypes.Je ne suis pas d'accord. Simplement, je ne veux pas modifier les prototypes de base (cf. plus bas), donc je me retrouve à faire l'équivalent d'une classe (un nouvel objet que je vais peupler de propriétés).
Pour le coup, j'aurais surtout tendance à partir en courant !
À l'inverse je peux trouver des cas d'utilisation qui sont favorables à l'héritage par prototype. Mettons par exemple que j'écrive un programme dans lequel j'ai fréquemment besoin d'obtenir l'opposé de chaque élément d'un tableau, je pourrais avoir envie d'une fonction "negate" disponible facilement (bouh, elle n'est pas disponible de base, quelle bibliothèque standard ridicule !). Une solution simple à ça serait de l'ajouter directement sur l'objet Array
Plus généralement je viens d'étendre la bibliothèque standard, ce qui est une fonctionnalité que pas mal de langages ont essayé de proposer (C# avec les méthodes d'extension, Python avec la méthode magique "__init__" au lieu de constructeurs, etc.).Qu'est-ce que la méthode __init__ a de magique ? C'est un constructeur comme un autre, non ? Mais je ne vois pas trop en quoi elle étend la bibliothèque standard (je ne connais pas C#, donc je n'en dirais rien).
flanker (./2858) :Heu... tu sors ça d'où ? Ça ne marche pas dans mon browser et ça n'apparaît pas non plus dans la spécification ? (et pas plus dans celle de Mozilla, que je suis allé voir au cas où)
- ça ressemble quand même beaucoup à une table de hash, avec les méthodes keys(), values()
flanker (./2858) :Si jamais pour toi "utiliser les caractères { et } en commun" est un critère alors d'accord, mais pour moi non ça n'est pas exagéré, je pense réellement que le concept n'a rien en commun (pour des raisons déjà expliquées plus haut donc on tourne un peu en rond)
Donc dire que {} n'a aucun rapport, même de loin, avec une hash table me semble un tantinet exagéré
flanker (./2858) :Bah oui bien sûr, là encore c'est le postulat de départ : le JS a été conçu pour être exécuté dans un environnement isolé. Je ne conteste pas le fait qu'on le pousse trop loin en essayant de l'utiliser comme technologie côté serveur et lui faire faire des choses qui n'ont pas été prévues au moment de sa conception. Je dis simplement que replacé dans son contexte c'est un langage qui beaucoup de choix intéressants.
C'est viable quand on bosse sans aucune lib externe, mais sinon, je trouve ça beaucoup trop dangereux.
flanker (./2858) :Pas du tout non, c'est une méthode d'initialisation. La différence réside, entre autres, dans le fait qu'il s'agit d'une méthode tout à fait classique qui suit l'arbre d'héritage des objets. Ça veut dire que si j'ai une classe AbstractMachin qui expose une méthode def __init__(self, x, y) et que j'en fais hériter un ConcreteMachin qui ne redéfinit rien du tout, alors je peux quand même faire machin = ConcreteMachin(3, 5) et ça appelle ma fonction d'initialisation correctement. C'est utilisé dans pas mal d'endroits de la lib standard pour fournir des classes volontairement incomplètes qu'il faut étendre pour pouvoir s'en servir, mais qui ont quand même besoin d'arguments pour être initialisées. Ça fonctionne, mais je trouve qu'avoir troqué les constructeurs pour cette fonctionnalité est trompeur : si je redéfinis une méthode __init__ moi-même et que j'oublie d'appeler celle de mon parent par exemple (parce que j'ignorais qu'elle existait, ou tout simplement parce que je me suis planté) alors je vais me retrouver avec un code qui s'exécute correctement mais va planter ou faire n'importe quoi à l'exécution.
Qu'est-ce que la méthode __init__ a de magique ? C'est un constructeur comme un autre, non ?
Zeph (./2859) :pourtant : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/keys et https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/values (en effet, c'est expérimental, je n'avais pas vu)
Heu... tu sors ça d'où ? Ça ne marche pas dans mon browser et ça n'apparaît pas non plus dans la spécification ? (et pas plus dans celle de Mozilla, que je suis allé voir au cas où)
Bah il y a quand même la syntaxe toto["ma_clef"] et toto["ma_clef"] = "ma_valeur", qui fait aussi furieusement penser aux HashMap de beaucoup de langagesflanker (./2858) :Si jamais pour toi "utiliser les caractères { et } en commun" est un critère alors d'accord, mais pour moi non ça n'est pas exagéré, je pense réellement que le concept n'a rien en commun (pour des raisons déjà expliquées plus haut donc on tourne un peu en rond)
Donc dire que {} n'a aucun rapport, même de loin, avec une hash table me semble un tantinet exagéré
La doc officielle de Mozilla dit également que «[...] les objets JavaScript ont été utilisés comme des Maps », ou encore « Dans la plupart des scénarios, les objets restent une solution valide [pour une HashMap] ». Mais bon, à la base, ce n'était qu'un exemple d'un mauvais aspect de JS, qui pousse à l'erreur. Bien sûr, si on maîtrise la doc *officielle* et qu'on ne fait pas confiance à StackOverflow (au hasard), on ne tombera pas dans les pièges comme celui-ci. Même côté client. J'ai déjà eu des bugs très rigolos (malgré ma faible expérience JS), où justement l'inclusion d'une lib tierce-partie a flingué mon code parce qu'il ajoutait des méthodes à des objets de base.flanker (./2858) :Bah oui bien sûr, là encore c'est le postulat de départ : le JS a été conçu pour être exécuté dans un environnement isolé. Je ne conteste pas le fait qu'on le pousse trop loin en essayant de l'utiliser comme technologie côté serveur et lui faire faire des choses qui n'ont pas été prévues au moment de sa conception. Je dis simplement que replacé dans son contexte c'est un langage qui beaucoup de choix intéressants.
C'est viable quand on bosse sans aucune lib externe, mais sinon, je trouve ça beaucoup trop dangereux.
Ok, je n'avais pas la bonne définition de constructeur en tête. je connais la différence de comportement suivant les langages que j'utilise, mais pour le coup le comportement ne m'a pas spécialement choqué, il est simplement différent (ni meilleur, ni moins bon). Je n'avais jamais fait gaffe que la doc ne parlait jamais de constructeur mais seulement d'__init__.
Pas du tout non, c'est une méthode d'initialisation. [...]
Arvi89 (./2857) :Je ne sais pas ce que valent les tests de façon générale, j'ai regardé uniquement le n-body, dans lequel j'ai fait un petit changement :
https://benchmarksgame.alioth.debian.org/u64q/php.html
Dans des benchs (il faudrait tester des trucs plus courant aussi), PHP7 est bien plus performant que python 3 en tout cas.
def combinations(l):
result = []
for x in range(len(l) - 1):
ls = l[x+1:]
for y in ls:
result.append((l[x],y))
return resultremplacé pardef combinations(l):
for i, x in enumerate(l):
for y in l[i+1:]:
yield (x, y)Je suis passé de 220s à 30s*, puis à 28s en utilisant "itertools.combinations" qui est fournie de base (bon, le gain de perf est sûrement de l'erreur de mesure)Zeph (./2856) :Ca, c'est clair que dès qu'on veut faire des applications avec des traitements asynchrones, c'est la merde (et je le sens bien avec le projet que je gère, je suis obligé de passer par des fichiers de lock et d'échanges de données, c'est extrêmement gourmand en temps, sans certitude sur le fait que le script n'a pas planté au milieu (impossibilité de faire la différence entre un traitement long et un traitement planté). C'est une vraie plaie.
- Il manque certains concepts en PHP, globalement tout ce qui tourne autour du fait d'avoir une application persistante et non un script qui s'exécute et s'arrête : pas de threads, pas d'asynchronisme, pas de mémoire partagée, pas de mémoire qui survive au-delà d'une seule exécution ; ça limite pas mal les domaines d'application
Zeph (./2856) :PHP 7 a radicalement boosté les performances, c'est assez impressionnant
- Je n'ai jamais fait (ni cherché) de bench contre PHP 7 mais j'imagine que Python conserve une certaine avance en performance d'exécution. Après les deux restent des langages dynamiques donc si la performance est un critère pour toi alors ce sont probablement tous les deux des mauvais choix de toutes façons.
un même script qui tourne en PHP5 en une grosse demi-heure est tombé sous les 20 minutes (j'utilise PHP comme ETL).
flanker (./2864) :Fixed For Folco
Quand on a besoin de perfs, tout le jeu est de trouver la bonne lib qui va permettre d'utiliser du code C assembleur de façon transparente, mais ce n'est pas toujours faisable bien évidemment.
Zeph (./2856) :Je ne savais pas que tout ça n'existait pas en PHP, je pensais naïvement que ç'avait été rajouté au fil du temps, comme pour la plupart des autres langages. Rien que pour ça, je recommanderais à Meowcate d'essayer le Python (ou un autre langage dans lequel ces features existent), parce que ce sont des concepts utiles et devenus difficiles à contourner.
pas de threads, pas d'asynchronisme, pas de mémoire partagée, pas de mémoire qui survive au-delà d'une seule exécution
squalyl (./2866) :bin ça dépend, justement ^^
pour moi avec ces trucs, les perfs on s'en fout. par contre les libs de python sont sympas et le langage est moins bordélique.
Tricky Python quiz: why does the code on the left raise an UnboundLocalError while the code on the right works? pic.twitter.com/rtEiFiwZK3
— Régis Behmo (@regisb) May 17, 2017
Pen^2 (./2874) :Ce n'est plus le cas en Java 8, il suffit maintenant que la variable soit effectivement finale, il n'est plus nécessaire de la déclarer comme telle.
En java par exemple la variable c de portée plus large aurait dû être obligatoirement définie comme étant final pour éviter ce genre de surprise. Une bien belle machine
)
