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

de toute façon le while(1) c'est mal !

Me semble que j'ai déjà eu le problème avec des compilateurs C qui virait des boucles (si je me souviens bien, avec celui d'un constructeur de microcontrôleur, si vous voyez duquel je veux parler .

Non, je ne vois pas du tout

SCPCD (./241) :
de toute façon le while(1) c'est mal

bra * FTW !!!

Au passage, une boucle infinie avec goto peut également être dégagée...

et en inlinant une boucle infinie en asm au fait, ça le ferait pas ?

Si. On peut aussi rajouter un accès bidon à une variable volatile dans la boucle, d'après la spéc ça empêche l'optimisation. Mais c'est anormal de devoir en arriver là.

C'est sûr. Mais pour les compilos pas trop cons, ça rentrera dans la catégorie des optimisations unsafes, à débloquer avec force switches et confirmation. Foutue régression de la norme cependant...

Le problème, c'est qu'il y a justement plusieurs compilos actuels qui font cette "optimisation" par défaut (ils en parlent ici)

Oui il n'est pas completement déterministe, mais suffisement pour pouvoir faire du systeme, et faire du systeme laisse peu de choix a l'inconnu...

int i=random(100);
while (i<101){
...

nitro (./234) :
http://langpop.corger.nl
http://lang-index.sourceforge.net
http://langpop.com
https://sites.google.com/site/pydatalog/pypl/PyPL-PopularitY-of-Programming-Language

Et un petit nouveau, qui a le mérite d'être interactif et on peut donc classer en fonction de ce qui nous intéresse le plus parmi les sources proposées : http://spectrum.ieee.org/static/interactive-the-top-programming-languages

Merci pour l'info

C'est très vrai oui (peut être trop, ça ne m'a pas vraiment décroché de rire ^^).

comicstrip est down

http://stackoverflow.com/questions/5464362/javascript-using-a-condition-in-switch-case/9055603#9055603

C'est à la fois ingénieux et horrible

Pas de hack, c'est tout à fait valide bien qu'assez inhabituel comme pas mal de trucs en JS ; par contre comment t'es tombé là-dessus ?

-

Ah bah c'est sûr que si le langage était pensé aujourd'hui, ce genre de choses aurait été pensé différemment. Ça avait probablement du sens à l'époque (ça simplifie la grammaire et ça fait quelques opcodes en moins à gérer côté VM, donc implémentation plus facile) quand les performances étaient très loin dans les considérations à prendre en compte pour ce langage.

-

Oui, mais le JS était prévu uniquement pour insérer 2 ou 3 lignes histoire d'avoir un compteur qui défile ou une textbox qui apparaît quand on coche un bouton. C'est très loin de l'utilisation actuelle, et il n'y avait absolument pas besoin de performance pour ça (rien que tenter de faire du JIT aurait couté 100 fois le prix de l'exécution directe du bytecode).

(Javascript a été originellement créé pour etre coté serveur et non client)

ECMAScript, pas Javascript

Zeph (./261) :
Ah bah c'est sûr que si le langage était pensé aujourd'hui, ce genre de choses aurait été pensé différemment. Ça avait probablement du sens à l'époque (ça simplifie la grammaire et ça fait quelques opcodes en moins à gérer côté VM, donc implémentation plus facile) quand les performances étaient très loin dans les considérations à prendre en compte pour ce langage.

Ça, on est d'accord : le JS n'a pas spécialement été pensé

Moi je le trouve au contraire plutôt très bien foutu, malgré son age il continue à être largement utilisable aujourd'hui et à accueillir des concepts "modernes" (enfin pas tant que ça, mais disons qu'ils deviennent grand public aujourd'hui) de façon assez naturelle. Il suffit par exemple de jeter un coup d'oeil à ce qui se fait au niveau programmation asynchrone, à l'heure où .NET ne sait pas sur quel pied danser d'une version à l'autre et Java se traine des implémentations pétées au point d'envisager de piquer toutes celles de Scala. Alors qu'en JS on a jQuery qui propose des futures/promises très élégantes depuis un bon moment

Y'a quand même un truc qu'il ne faut pas oublier si tu veux parler d'asynchrone, c'est que .NET et Java sont des environnements multithreads, alors que JavaScript, non. Faire de l'asynchrone mono-thread c'est beaucoup plus facile (pour ne pas dire un jeu d'enfant) que de le faire en multi-thread. Et à ce niveau là, l'implementation de Task de .NET est plutôt très bien fichue (Et Java, j'en sais fichtrement rien. La dernière fois que je me suis renseigné, il me semblait qu'il ne faisait rien à ce niveau)

Quand à dire si JavaScript est mal fichu ou bien fichu. Il peut avoir bien évolué (cf. Différentes révisions de ECMAScript), ça n'en reste pas moins que les bases sont pourries à nombre d'endroits. (Les conversions automatiques pourrissent le langage... Comme en PHP.)
Après, si on arrive à passer outre ces erreurs primitives, on peut faire de super trucs assez facilement en JS. Y'en a même qui s'en servent pour faire des éditeurs de texte (https://github.com/atom/atom) ou des outils de dev... Bon par contre c'est assez risible parce que dès qu'il faut plus que la ligne de commande, on embarque tout chromium, et chromium c'est lourd.
(Et parlons donc du fonctionnement des proxy d'entreprise avec nodejs ou atom... De la grosse daube, ça marche juste pas . C'est la première fois que je vois des mec arriver à pondre une version Windows d'un outil qui par défaut n'utilise pas les réglages Internet pour aller sur internet Je vous souhaite de ne jamais vivre ça…)

Faire de l'asynchrone en mono-thread ça veut juste dire ne pas avoir de problème d'accès concurrents. C'est une bonne chose, mais c'est un problème qui n'influe pas sur le paradigme à choisir. D'ailleurs, avoir un seul thread impose justement de bien l'utiliser (impossible d'avoir une sale boucle qui tourne en background) sous peine de freezer toute l'application ; c'est probablement ce qui explique pourquoi les bibliothèques JS sont en général asynchrones alors que dans d'autres environnements c'est loin d'être automatique.

Pour .NET c'est un peu n'importe quoi. Ils ont commencé à mettre des callbacks partout, sauf qu'ils ne savaient pas trop comment faire entrer synchrone et asynchrone dans les mêmes APIs du coup on a des "IAsyncResult" qui ne ressemblent à rien avec une douzaine de propriétés pour savoir si un truc a été fini de façon synchrone, s'il a été lancé, s'il tourne toujours, s'il faut l'attendre ou s'il va nous rappeler quand il aura fini. Ensuite on a eu les Task, sauf qu'ils ont voulu comme d'habitude être compatibles avec tout l'historique donc c'est pareil : on a des Task qui sont à la fois des futures, des promises, des machins qui ressemblent à des WaitHandle sur lesquels on peut faire "Wait()" et tout un tas d'autres méthodes obscures. Je suis désolé mais en regardant l'API de "Task" je trouve qu'il faudrait être de sacrément mauvaise fois pour prétendre que c'est bien pensé ou élégant

P.S. : pour ton anecdote, c'est pas la première fois : Firefox n'utilisait par défaut pas les réglages internet de Windows pour aller sur internet, et encore aujourd'hui il embarque son propre cache DNS ^^

Zeph (./267) :
Moi je le trouve au contraire plutôt très bien foutu, malgré son age il continue à être largement utilisable aujourd'hui et à accueillir des concepts "modernes" (enfin pas tant que ça, mais disons qu'ils deviennent grand public aujourd'hui) de façon assez naturelle. Il suffit par exemple de jeter un coup d'oeil à ce qui se fait au niveau programmation asynchrone, à l'heure où .NET ne sait pas sur quel pied danser d'une version à l'autre et Java se traine des implémentations pétées au point d'envisager de piquer toutes celles de Scala. Alors qu'en JS on a jQuery qui propose des futures/promises très élégantes depuis un bon moment

J'ai regardé deux ou trois tutos pour comprendre les bases du JS. À chaque fois, ils commencent par dire que c'est un modèle objet par prototypes, que c'est fantastique et bien mieux que les modèles par classes. Et l'étape suivante, c'est comment implémenter un système de classes, parce que c'est quand même vachement plus pratique
Sans compter le == dont il ne faut surtout pas se servir (mais pourquoi l'avoir mis, alors ?), l'absence de hashmap utilisables (enfin, tu as le object, mais dès que tu fais une boucle sur les clefs, il faut faire du filtrage pour supprimer les clefs indésirables — et il faut donc pouvoir faire la distinction ), l'utilisation périlleuse de this, …