1

J'attends des réponses à mon autre topic, mais celle de squalyl me fait réfléchir : il m'a proposé meteor, qui est un framework js qui propose de concevoir une appli web entièrement en JS, côté client comme serveur.

Je suis alors en train de me demander : pensez-vous que c'est l'avenir, que le PHP, Perl, Python, et autres langages non-compilés sont voués à disparaître (dans un court-moyen terme j'entends bien sûr) des langages web au profil du JS (ou une de ses évolutions) à concevoir l'ensemble de l'appli avec un unique langage non-compilé en retour (qui, avec une couche de framework, permet d'éliminer la majorité des trucs pénibles qui font que l'on n'aime pas coder en JS) ?
Certes, on aura toujours besoin de ces codeurs pour maintenir de vieilles applis et des boites qui ne bossent qu'avec leur langage/framework favori (voire framework/cms maison), mais professionnellement parlant je m'inquiète toujours de suivre le courant pour toujours savoir rebondir.
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

2

Non, l'avenir, c'est ça: http://cutelyst.org/
Les langages interprétés (dont le JavaScript fait partie), c'est nul.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

3

Meow: justement j'ai connu meteor au taf, mais on s'en est pas servi finalement.

je te l'ai proposé parce qu'il propose des trucs cools, genre il met a jour la page en temps réel quand des variables changent coté serveur.

ceci dit je suis d'accord avec toi, c'est assez douteux la vitesse de dev de ces framework, toute connaissance semble obsolète en 3 mois, ca va trop vite amha, du coup aucune techno ne se solidifie.

4

./2 Non. Tu ne viens pas expliquer ce qu'est l'avenir du développement web quand pour toi le web aurait dû rester aux textes et liens et refuser tout le reste jusqu'aux balises img. Allez zou, laisse les grandes personnes parler.

./3 Le côté connecté client/serveur me tente.
Pour la vitesse des changements de frameworks et technos, c'est sûr qu'il faut bien se lancer quelque part. Mais il semble se dégager une nouvelle tendance où les frameworks JS assurent tout le travail. Je ne comparais pas Meteor avec un autre framework JS, plutôt l'idée d'utiliser un framework "complet" JS (comprendre qui fait à la fois serveur et client) par rapport à des architectures plus classiques (avec PHP, Python ou Ruby pour le serveur).
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

5

Meowcate (./4) :
./3 Pour la vitesse des changements de frameworks et technos, c'est sûr qu'il faut bien se lancer quelque part.

Ça me ferait quand même vachement peur d'investir dans une techno qui aura probablement une durée de vie inférieure à la durée de vie d'un projet. Autrement dit, ça revient à maintenir autant de technos en parallèle que de projets…
Mais il semble se dégager une nouvelle tendance où les frameworks JS assurent tout le travail.

J'ai un peu l'impression que ça se calme à ce niveau, au contraire.

De plus, on se retrouve avec deux constantes sur ces frameworks JS (à ma connaissance, je n'ai jamais joué avec donc je me trompe peut-être) :
* c'est vraiment orienté vers des applis sur une seule page (donc tu auras toujours une seconde techno à connaître pour des applis conséquentes),
* ça permet d'utiliser facilement du MongoDB ou du Redis… mais beaucoup moins du PostgreSQL ou du MySQL (qui sont pourtant bien pratiques quand on a plein de relations entre les tables, vu que c'est un peu leur but ^^). Et si c'est pour écrire du SQL à la main comme en 2000, non merci couic

Bref, c'est bien joli, mais si tu veux faire autre chose qu'une toute petite appli, tu vas te retrouver à avoir une autre techno ; et si ton appli grandit, soit tu auras une partie serveur mixte (nodeJS + autre chose), soit tu n'auras que du nodeJS et tu vas pleurer vu que ce n'est pas fait pour.
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

6

Passer du Python (par exemple) à du JS + un truc pour cacher la misère, ce serait une belle régression quand même.

Mais ça n'est pas impossible que ça se produise pour autant, l'informatique étant une discipline où les modes ont bien plus de poids que les réflexions rationnelles.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7

Voilà des avis qui auraient tendance à me rassurer. Mais quelque part je me demande si ça n'a pas un côté "dev campant sur ses habitudes qui ne veut pas évoluer" (je ne parle qu'en mon nom).
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

8

Bin si tu veux regarder autre chose, tu peux tester RoR, Django, Play, etc. les technos ne manquent pas ^^

Cela dit, ces frameworks vont devoir évoluer de leur côté (pour passer au websocket et HTTP/2, ce qui demande de grosses refontes).
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

9

Je n'ai pas utilisé non plus, mais je ne pense pas que s'attarder sur une limitation théorique "ça ne fait que des sites sur une seule page" soit le bon critère. Ça n'est pas tellement une limitation (je n'en ai utilisé aucuns mais plein de frameworks fonctionnent sans souci sur des sites multi-page) mais une conséquence à mon avis. Ces frameworks partent du principe que quasiment tous les browsers ont JavaScript activé et disposent de moteurs corrects, donc il devient possible de faire des applications qui évitent de tout recharger entre chaque page.

C'est sujet à débat, mais c'est un débat qui a été abordé de nombreuses fois sur yN et les détracteurs ici comptent une grosse proportion de gens qui ne font de toutes façons pas de développement web, donc je pense qu'il vaut mieux l'éviter. En revanche ce qui est clair c'est qu'en ce moment ça part un peu dans tous les sens et que les frameworks se créent aussi vite qu'ils disparaissent. Il y a plein d'outils pas secs, et même les fers de lance de cet écosystème chaotique mériteraient une réflexion un peu plus poussée avant d'être crédibles (les 350 gestionnaires de paquets, AngularJS qui casse son API, GruntJS qui impose un développement d'une lourdeur sans nom, une confusion totale entre les 1000 "loaders JavaScript" et les 3 ou 4 patterns qu'ils essaient tous d'implémenter simultanément, etc.).

Du coup pour faire un site durable aujourd'hui, mieux vaut être plutôt conservateur sur les technologies à utiliser. Mais ça peut quand même valoir le coup de suivre ça de loin, s'il y a autant d'itérations ça n'est pas forcément parce que tous les développeurs sont des abrutis, mais peut-être surtout que les problèmes ne sont pas si évidents que ça à résoudre.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

10

(ah, c'est pour ça qu'on voit de plus en plus de sites qui mettent tout sur la même page ? j'avais remarqué ça, mais en pensant que c'était juste une mode de design)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

11

flanker (./5) :
Et si c'est pour écrire du SQL à la main comme en 2000, non merci couic

DELETE FROM DEVELOPERS WHERE KNOWS_SQL = FALSE;
Ras le bol des "développeurs" qui veulent "développer" sans connaître et/ou sans vouloir utiliser les technologies de développement.
Zeph (./9) :
Je n'ai pas utilisé non plus, mais je ne pense pas que s'attarder sur une limitation théorique "ça ne fait que des sites sur une seule page" soit le bon critère. Ça n'est pas tellement une limitation (je n'en ai utilisé aucuns mais plein de frameworks fonctionnent sans souci sur des sites multi-page) mais une conséquence à mon avis. Ces frameworks partent du principe que quasiment tous les browsers ont JavaScript activé et disposent de moteurs corrects, donc il devient possible de faire des applications qui évitent de tout recharger entre chaque page.

Ce genre de "sites web" horribles vient de "développeurs web" qui n'ont rien compris au principe de graceful degradation, un des principes de base du WWW! C'est aussi pourri au niveau accessibilité. Le JavaScript est censé être optionnel, un site web est censé être utilisable si JavaScript est désactivé voire pas du tout géré par le navigateur.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

12

Kevin Kofler (./11) :
Ras le bol des "développeurs" qui veulent "développer" sans connaître et/ou sans vouloir utiliser les technologies de développement.

Journal de bord Meowcate, année grégorienne 2015, septième jour du septième mois : je suis d'accord avec Kevin Kofler.
Quand je vois le niveau de dev de certaines filiale à la sortie... on leur apprend à faire de l'intégration beaucoup plus avec du Bootstrap qu'avec du CSS3, sacré niveau après.
Kevin Kofler (./11) :
Ce genre de "sites web" horribles vient de "développeurs web" qui n'ont rien compris au principe de graceful degradation, un des principes de base du WWW! C'est aussi pourri au niveau accessibilité.

Wow, combo, doublement d'accord avec Kevin.
Enfin presque, je le ferais en sens inverse, pas de dégradation mais l'amélioration progressive : partir d'un site simple (et en cas de multi-support, commencer par la version petit écran, autrement dit version smartphone) pour ajouter au fur et à mesure des possibilités : d'abord la version uniquement liens, où chaque enregistrement de formulaire redirige vers une page de traitement, ENSUITE ajouter une version AJAX qui permet d'enregistrer le formulaire sans recharger (backup no-JS). D'abord le template smartphone, PUIS ajouter une version tablette, puis grand écran (le responsive doit commencer de bas en haut, ce qui rentre dans un petit rentre bien dans un grand, et non ce qui rentre dans un grand doit être ciselé pour s'adapter au petit).
C'est sur le même principe qu'un site doit être consultable (car ça arrive, même temporairement) quand ses ressources externes sont inaccessibles (CSS, JS, images non chargées) et que même moche, le HTML restant doit être lisible et utilisable.
Je confesse avoir rarement le temps de faire ces choses là (le JS optionnel), contraintes professionnels, mais pour ls projets où le client n'est pas pressé je fais les choses comme il faut.


Ceci dit, la question d'origine dévie, il s'agissait de se demander si l'avenir (pro) était au tout-JS ou si c'est un effet de mode. Et par là je ne parle pas du cas du tout-sur-une-page, qui reste pour moi une présentation de démo produit.
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

13

Je pense que les technos web toute récentes qui font une intégration trop poussée du client et du serveur peuvent être en effet intéressante, mais seulement si tu es pas près a assumer le risque qu'elle devine obsolescente prématurément. Cet environnement me parait vraiment instable.

Personnellement le JavaScript moins j'en vois, mieux je me porte, donc si je devais avoir un Langage unique je préfèrerais le Java via GWT.
avatar

14

Journal de bord Meowcate, année grégorienne 2015, septième jour du septième mois : je suis d'accord avec Kevin Kofler.Quand je vois le niveau de dev de certaines filiale à la sortie... on leur apprend à faire de l'intégration beaucoup plus avec du Bootstrap qu'avec du CSS3, sacré niveau après.

Sauf que Kevin ne fait pas la différence entre ne pas connaître et ne pas utiliser.

Faire du SQL direct, ça veut dire que tu es fortement couplé à une base en particulier (coucou tous les sites web en PHP qui ne permettent que MySQL et qui ne peuvent pas passer à Postgres ou SQLite ! ).
Ça veut aussi dire que tu dois faire à la main toutes les protections contre les injections SQL… autrement dit, tu vas forcément en rater quelques unes et tu vas te retrouver avec tout plein de failles que tu aurais évitées en passant par un ORM.
Et quand tu changes le format de ta base de données (ajout/suppression de colonnes, d'index, …), c'est la plaie pour modifier chaque instance de ton site, il faut appliquer les différentes modifs à la main, avec les risques associés de foire quelque chose couic, sachant qu'il faut savoir quelle version de la base est dispo sur chaque site pour déterminer les bons patchs sur la base…

Utiliser un ORM implique de connaître SQL de la même façon que si tu en faisais directement (autrement dit, tu peux obtenir des catastrophes dans les deux cas gni), mais tu enlèves les trois énormes inconvénients ci-dessus.
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

15

(pour ne pas pourrir le topic, je ne dirai pas qu'un ORM, c'est un peu le kernel de la base de données embarrassed)

16

gni

« une DLL qu'il ne faut surtout pas utiliser comme DLL » ©
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

17

flanker (./14) :
coucou tous les sites web en PHP qui ne permettent que MySQL et qui ne peuvent pas passer à Postgres ou SQLite

Euh ?
Si tu parles des commandes, ça fait longtemps qu'on n'utilise plus des commandes comme mysql_connect mais l'abstraction PDO.
Si tu parles de la syntaxe, je veux bien reconnaître quelques différences. Encore entre MySQL et SQLite, à part que SQLite n'a pas d'autre JOIN que LEFT (nécessitant alors de bien choisir l'ordre), les deux sont interchangeables avec quelques standards. En Postgre, il y a davantage de changements, je suis d'accord (plus qu'entre MySQL et Oracle ou SQLServeur à mon souvenir).

Mais il peut toujours arriver à mon sens des situations où les ORM ne peuvent avoir une couche d'abstraction suffisamment précises (pour les rares cas de requêtes vraiment complexes) et où il est nécessaire d'écrire la requête à la main.
Je ne dis pas qu'il faut se remettre au SQL à la main, mais qu'il est important (pour ne pas dire capital) de savoir faire sans. Si on connaît SQL, on peut se permettre d'utiliser des outils qui vont améliorer le travail. Quand on bute en ORM sur une requête complexe, un moyen d'y voir plus clair est de se demander comment on l'écrirait en pure SQL.

Et pis d'abord si tu dois changer le type BDD de tous tes sites du jour au lendemain, t'avais qu'à y penser avant, boloss !
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

18

Meowcate (./12) :
Enfin presque, je le ferais en sens inverse, pas de dégradation mais l'amélioration progressive.

Tu as raison, l'amélioration progressive est probablement une méthodologie meilleure pour arriver au résultat voulu. Cf. aussi http://www.w3.org/wiki/Graceful_degradation_versus_progressive_enhancement (que tu connais probablement, mais pour ceux qui nous lisent smile). Mais dans tous les cas, le but doit être d'avoir un site qui fonctionne sans JavaScript ou autres fonctionnalités optionnelles.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

19

Meowcate (./17) :
Euh ?Si tu parles des commandes, ça fait longtemps qu'on n'utilise plus des commandes comme mysql_connect mais l'abstraction PDO.

Encore heureux ! Sauf que ça n'abstrait pas grand'chose. Essaie de passer un Wordpress ou un PhpBB à du Postgres, tu vas rire.
Si tu parles de la syntaxe, je veux bien reconnaître quelques différences. Encore entre MySQL et SQLite, à part que SQLite n'a pas d'autre JOIN que LEFT (nécessitant alors de bien choisir l'ordre), les deux sont interchangeables avec quelques standards. En Postgres, il y a davantage de changements, je suis d'accord (plus qu'entre MySQL et Oracle ou SQLServeur à mon souvenir).

Perso, j'utilise quasi-systématiquement du SQLite (pour le dev) ET du Postgres (pour la finalisation et la mise en place), mais quand je fais un composant réutilisable, il *doit* être compatible avec n'importe quelle base.
Et si je fais un site utilisable par quelqu'un d'autre, c'est quand même beaucoup mieux de lui permettre d'utiliser MySQL, SQLite, Postgres, Oracle, MSSQL à sa convenance… (le truc totalement impensable quand tu écris tes requêtes à la main).

Mais il peut toujours arriver à mon sens des situations où les ORM ne peuvent avoir une couche d'abstraction suffisamment précises (pour les rares cas de requêtes vraiment complexes) et où il est nécessaire d'écrire la requête à la main.Je ne dis pas qu'il faut se remettre au SQL à la main, mais qu'il est important (pour ne pas dire capital) de savoir faire sans. Si on connaît SQL, on peut se permettre d'utiliser des outils qui vont améliorer le travail. Quand on bute en ORM sur une requête complexe, un moyen d'y voir plus clair est de se demander comment on l'écrirait en pure SQL.

Évidemment qu'il faut savoir se servir de ses outils cheeky Pour savoir utiliser un ORM, connaître le SQL est un prérequis ; tes requêtes via l'ORM seront aussi bonnes/mauvaises que si tu les faisais en SQL directement.
J'imagine que tout bon ORM va te laisser écrire du SQL pur s'il y en a vraiment besoin, mais ça va quand même limiter énormément les parties à contrôler quand tu vas changer de BDD.
Et pis d'abord si tu dois changer le type BDD de tous tes sites du jour au lendemain, t'avais qu'à y penser avant, boloss !

Quelle idée étrange de vouloir imposer la même BDD dans tous les cas. Ne fais-tu jamais de code réutilisable ? hum

puis tu oublies deux des trois arguments… tongue
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

20

Et moi qui pensais que le SQL était un standard, et qu'il n'y avait par conséquent besoin de couche d'abstraction par-dessus hehe

Sinon, pour les injections SQL, du moment que tu n'utilises que des requêtes paramétrées t'es tranquille, non ?
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

21

flanker (./19) :
Quelle idée étrange de vouloir imposer la même BDD dans tous les cas. Ne fais-tu jamais de code réutilisable ? hum


Ah mais c'est toi qui ne t'es pas arrêté sur mon :
Je ne dis pas qu'il faut se remettre au SQL à la main, mais qu'il est important (pour ne pas dire capital) de savoir faire sans.

Je parle du besoin de bien connaître le SQL smile pour le reste, en dehors des moments où je dois travailler sur de vieux projets de la boîte avec des requêtes SQL pure, je passe systématiquement par un ORM. On développe toujours sur MySQL et on a livré un gros projet pour un client en SQL Server.
C'est surtout utile pour des debugs : quand tu ne comprends pas pourquoi ta requête (ORM) ne donne pas les résultats attendus, voir le message de debug (en SQL) peut aider. Et bien sûr les ORM ont généralement une porte de sortie pour que tu places des requêtes SQL (ils gèrent rarement des concepts propres aux moteurs de BDD, comme les fonctions ou les procédures, même si généralement on les crée séparément).
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

22

et envoyer des requetes sql en ajax?

23

avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

24

Je suis un petit joueur, en effet. autant exécuter directement du php, anéfé !

25

Non c'est hasbeen autant injecter du code assembleur c'est plus mieux!
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

26

TF Javascript j’apprécie beaucoup celui là : ++[[]][+[]]+[+[]] === "10"Dans la grande série des W
avatar

27

C'est vrai pour toutes les implémentation JS ca?!!
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

28

Oui. C'est tout a fait conforme à la spécification : l'explication
avatar

29

30

Uther (./28) :
Oui. C'est tout a fait conforme à la spécification : l'explication

J'ai du mal à comprendre l'intérêt d'avoir ce comportement (même si c'est parfaitement décrit dans la spec). Ok, on n'est pas censé faire ça, mais le problème est qu'on se retrouve avec des résultats qui ne sont absolument pas prévisibles si on n'a pas testé avant.

Avec Python, additionner une liste et un dictionnaire renvoie une erreur, et ça semble logique.
En JS, je sais que ça va donner… quelque chose, mais a priori je n'ai aucune idée du résultat (et je ne suis pas le seul, suffit de lire wtfjs ^^). Et au final, c'est le bon plan pour laisser passer des bugs.
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant