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

bob > si tu veux te sacrifier en m'expliquant les avantages du système par prototypes par rapport aux classes, je suis preneur

Mais pourquoi il devrait absolument y avoir un avantage d'un côté ou de l'autre ? Ça permet de faire autant de choses et la syntaxe (<- cette fois je parle de syntaxe, GC !) n'est pas plus compliquée, pourquoi voudrais-tu absolument remplacer ça par des classes ? C'est comme si je voulais absolument remplacer le scoping Python par des paires d'accolades au lieu de l'indentation au seul prétexte que j'y suis plus habitué, c'est un peu léger comme justification

Je "parle de syntaxe" (même pas, je montrais juste une version différente, sur un langage différent, donc langage différent. Bref syntaxe…langage) parce que du coup j'aimerais savoir si tu trouves que l'implementation de Scala est pourrie aussi. (Oui, c'est une question )
Sinon pour simplifier, y'a une implémentation d'asynchronisme que tu trouves particulièrement bandante/supérieure aux autres, et qui illustrerait mieux où tu veux en venir ? (en dehors de la rétrocompatibilité)
Parce que plus ça va, moins je comprends, et pourtant je pense qu'on a fait le tour des angles d'approche

(Y'a sans doute des trucs auquel je dois répondre dans ton post mais je relirai tout ça plus tard, pour l'instant, c'était réponse à l'arrache )

Tu parles de l'implémentation de quoi en Scala, les futures/promises ? (ça pour être précis, puisqu'il n'y a pas que ça de disponible)

Si oui, oui je les trouve beaucoup plus saines, il y a une séparation claire entre fournisseur et consommateur (deux traits différents), ce qui permet par exemple au client d'une API de faire tout ce qu'il veut sur le résultat qu'on lui a envoyé (par exemple l'annuler, faire de la composition fonctionnelle ou juste "wait") sans rien lui exposer qui ne fasse partie de l'autre côté (comme par exemple "start", ou bien compléter l'action). Sinon voilà un autre article avec lequel je suis totalement d'accord, regarde en particulier le critère "minimal" concernant les Task .NET qui recoupe exactement ce que je n'arrive pas à t'expliquer : http://blog.softmemes.com/2012/06/18/the-way-of-the-future-futures-in-net-java-and-javascript/.

Ben justement, je comprends pas ce que tu trouves de "beaucoup plus sain" quand Future (Scala) == Task/Task<T> (.NET) et Promise (Scala) == TaskCompletionSource<T>. C'est bien ma remarque (à la quelle tu as agréé ? ), c'est exactement la même chose, juste avec des noms différents et une syntaxe (mots-clés) différente, juste parce que c'est du Scala.

Et donc, cf. le lien que tu poste, tu admettras donc que Task<T> est excellent si tu retires Start() et RunSynchronously()… ?
(Perso je vois mal le besoin de minimalisme poussé à l'extrême mais bon, comme je t'ai déjà dit je ne suis pas le plus grand fan de ces fonctions, c'est juste qu'elles sont indispensables dans *certains scénarios* qui probablement ne nous concernent ni toi ni moi (pour l'instant))

(Honnêtement j'ai un peu l'impression que tu te bats contre des moulins à vent pour le coup. Enfin j'espère que tu ne le prendras pas mal )

Task<T> serait excellent si on retirait RunSynchronously() et Start(), puis (moins important mais ça reste mal placé à mon sens) : AsyncState, CreationOptions, CurrentId, Exception, Factory et Id. C'est peut-être là qu'on est pas d'accord, mais non "Future" n'est pas du tout la même chose que "Task" à cause de l'existence de RunSynchronously() et Start() qui changent fondamentalement la nature de cet objet. Ça te semble peut-être être juste deux méthodes en trop, mais fonctionnellement c'est pour moi une anomalie (et une anomalie qui ne pourra pas être corrigée en plus, c'est trop tard, il faudra attendre leur n-ième prochaine proposition de paradigme asynchrone pour avoir peut-être quelque chose de propre).

Mais je ne me bats contre personne tu sais, je me permets juste d'avoir mon avis, c'est un peu gros que ce soit toi qui me fasse ce genre de commentaire alors que le premier message kilométrique qui a déclenché une discussion dont je me serais bien passé vient de toi :/

Non mais c'est un peu toi qui a commencé en disant que c'est absolument n'importe quoi de tous les côtés… Enfin je schématise mais c'est à peu près ça
Enfin, bref, y'a encore des trucs avec lesquels je suis pas d'accord dans ce post, mais je pense qu'on va arrêter là.

Vu l'apport jusqu'ici je pense qu'on peut arrêter, oui.

Après le détecteur de mensonges, voici le détecteur de mauvais code :
http://www.theregister.co.uk/2014/07/15/microsoft_wires_up_developers/

Un article très critique sur le Javascript : http://sametmax.com/un-gros-troll-de-plus-sur-javacscript/

Pas totalement d'accord pour Chrome : la course à la vitesse est arrivée un peu avant.

Mais pour le reste, tout à fait d'accord.

Lire un fichier ligne à ligne ? Une opération vraiment rare et compliquée…
Python :

for line in open('fichier'):
    print line[/pre
En JS… Heu, enfin avec NodeJS:
[pre]var fs  = require("fs");
fs.readFileSync('./input.txt').toString().split('\n').forEach(function (line) {
    console.log(line);
});

Il oublie que la version JS va charger tout le fichier en mémoire et faire un split

À part 2-3 petites erreurs, c'est plutôt réaliste comme article mine de rien… même si le gars voulait partir en troll.

JavaScript est une merde avec laquelle on est obligé de composer.
A noter quand même que les petites merdes surprenantes dans les bouts de code en exemple, on peut en trouver dans la plupart des langages comme Java, C, ... même s'il faut reconnaitre que c'est bien en JavaScript qu'on a le plus de chance que ça arrive.

Je n'y connais pas grand chose en développement web, mais je ne comprend pas trop en quoi on est obligé d'utiliser javascript de nos jours, à part pour faire comme tout le monde (ce qui est déjà une raison en soi, mais bon quand on voit certains publier des articles interminables remplis d'insultes on se dit qu'il y a quand même une certaine motivation pour utiliser autre chose). Il y a beaucoup de langages plus matures qui permettent de générer du javascript, il me semble même qu'on a l'embarras du choix.
https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS

S'il y a des développeurs web qui passent par là, ce serait intéressant de savoir pour quelles raisons ils font du js plutôt que du haxe ou autre...

Y'a une explication assez simple que j'ai lue à ce sujet y'a pas très longtemps, et si je devais résumer, c'est plus ou moins cela que j'ai retenu :
 • Tout le monde connait le JavaScript. Ça fait un peu echo avec toutes les raisons possible, mais il faut voir la quantité d'implications que ça a. (Quantité/qualité du support, facilité de trouver des réponses/exemples sur Google, facilité de trouver des développeurs « qualifiés », …)
 • Quelle que soit la merde avec laquelle tu code, ça ne te dispense pas de connaître le JavaScript (faut bien savoir déboguer)
 • Si tu publies un projet web avec un langage autre que JavaScript, tu imposes ta merde aux autres, et ça peut être un grave frein au développement: Tu imposes aux autres de maîtriser les tenants et aboutissants de ta techno en plus de la leur, et y'a de grandes chances que ça te fasse perdre de potentiels contributeurs qui n'ont pas autant de temps à perdre que toi.
 • Ta technologie « supérieure » est pas forcément meilleure ou plus simple que JavaScript
 • Comme tout le monde fait du JavaScript, c'est juste plus simple de faire également du JavaScript
(C'est sans doute plus ou moins adapté à ma vision des choses. Mais de fait, je suis totalement d'accord avec ce que je viens d'écrire )

Maintenant, je n'ai pas « sérieusement » été confronté au problème (genre incité à faire un choix), mais j'ai déjà été voir ce qui se fait ailleurs, donc voilà mes raisons perso :
 • Je connais suffisamment JavaScript (rapport aux pièges / trucs qui fonctionnenet mal, etc.) pour me démerder. C'est pas une raison en soi mais un prérequis à tout le reste
 • J'utilise exclusivement des librairies JavaScript, qui ont été conçues exclusivement pour le JavaScript (i.e. son modèle objet), et non je ne sais quel autre langage plus ou moins proche
 • Quel que soit la technologie autre, cela nécessitera de mettre en place un workflow de compilation à la noix avec conversion automatique des fichiers au build, et ça te fait un outil en plus à gérer dans ta chaîne. Perso, étant un gros connard de fainéant, si ça marche pas tout seul, ça dégage, et je ne me pose pas de questions. (À noter ici l'avantage si l'on bosse avec Visual Studio, le process de build est facilement extensible, donc il existe à priori déjà des Task MSBuild pour gérer ces merdes à nos places)
 • Hmm… Comment dire… Je… n'ai pas de besoin ?
 • Un nouveau truc à apprendre ? Ok mais pour quoi faire ? cf. point précédent
 • Si ça me fait chier de coder X en JavaScript, je vois difficilement comment ça serait moins le cas avec un langage Y compilé en JavaScript
 • JavaScript est déjà là, et y'a rien à faire pour que ça marche

Bref, honnêtement, je dirais que ça n'en vaut pas la peine : Cost >> Benefit.

Sérieusement, faudrait quand même vraiment être atteint pour contester que JavaScript soit un langage de merde. Mais en même temps, faut lui reconnaître ses qualités. Le langage, en tant que lui même (donc en excluant toutes ces questions de DOM et autres choses liées au navigateur), permet d'écrire du code très rapidement, dès que l'on l'a pris en main. On peut créer des structures objet avec une facilité déconcertante. La nature « pâte à modeler du langage » fait que tu peux faire pratiquement tout ce que tu veux avec (hors étendre le langage lui-même, il s'entend…), d'où la foison de frameworks Web JavaScript qui existent.
Maintenant voilà, c'est un cauchemard à déboguer, parce que l’absence de typage statique permet de faire passer n'importe quoi comme du code valide, parce que les conversions implicites provoquent des scénarios tordus, parce que tu as du mal à visualiser à quelle variable exactement tu accèdes… C'est exactement pour ça que c'est un langage de merde. Mais on ne va pas magiquement résoudre les problèmes de débogage en utilisant un autre langage par dessus. En général, en empilant des technos, on a plutôt tendance à ajouter des problèmes qu'à en retirer.

Ok, je comprends la plupart de tes arguments. Pour rester dans Visual Studio, avec un truc qui marche tout seul et du typage statique, tout en restant proche du JavaScript, tu as déjà regardé TypeScript ?

GoldenCrystal :
En général, en empilant des technos, on a plutôt tendance à ajouter des problèmes qu'à en retirer.

Ou comment assassiner le dév moderne dans son ensemble en quelques mots (note que je suis plutôt de ton avis)

nitro (./315) :
Je n'y connais pas grand chose en développement web, mais je ne comprend pas trop en quoi on est obligé d'utiliser javascript de nos jours, à part pour faire comme tout le monde (ce qui est déjà une raison en soi, mais bon quand on voit certains publier des articles interminables remplis d'insultes on se dit qu'il y a quand même une certaine motivation pour utiliser autre chose). Il y a beaucoup de langages plus matures qui permettent de générer du javascript, il me semble même qu'on a l'embarras du choix.
https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS

S'il y a des développeurs web qui passent par là, ce serait intéressant de savoir pour quelles raisons ils font du js plutôt que du haxe ou autre...

Je me demande à quel point les promesses sont vraiment tenues. Perso, j'ai peur que :
* ça soit impossible à débugguer parce que tu as les erreurs en JS et tu es incapable de trouver la ligne correspondante dans ton Haxe/CoffeeScript/Objective-J
* la bibliothèque standard soit lourde (normalement, dans un langage de script, les structures de bases sont codés en natif, pas dans le langage lui-même !)
* les perfs globales
* j'ai un peu du mal à croire qu'on puisse réellement corriger le problème du typage en JS. Par exemple, en Python, je peux utiliser 1 et "1" comme clefs dans une hashmap, et ça sera deux éléments différents. En JS, ça sera la même clef (même si on a 1 !== "1"). Je ne vois pas comment un surlangage pourrait éviter ça sans un coût prohibitif.

./317 > J'avais regardé il y a quelques temps (dur de ne pas en entendre parler ^^), mais je ne suis pas vraiment allé plus loin que leur page d'accueil. J'aime l'idée qu'ils aient codé leur truc en se basant sur le JavaScript et en y intégrant quelques bouts de ES6 (du coup c'est « juste » du JavaScript amélioré) mais comme je disais, pas le besoin.

./318 > Honnêtement, les dernières technos web sont plutôt orientées retour aux bases (dans la philosophie) qu'empilage de trucs inutiles… Bien qu'on continue toujours d'empiler des trucs pour que ça marche (Après, c'est un peu le principe d'un framework)
Par exemple, infrastructure d'une application web moderne: UI en HTML5* + CSS3, Cœur d'application (côté client) en JavaScript, et backend via services REST (HTTP, avec habituellement du JSON)
* Selon la techno utilisée, le serveur ne reçoit pas forcément du HTML, mais avec un truc comme Knockout ou AngularJS, tu te démerdes quand même pour générer un document conforme HTML5 ou XHTML5, bien que celui-ci soit d'une utilité nulle sans le JavaScript qui lui est associé.
Ça fait des choses assez lourdes à gérer côté clientnavigateur (va quand même falloir que les gens finissent par capter un jour…) mais ça rapproche le développement Web du développement d'une application classique, tout en simplifiant la vie des développeurs web. (Perso, je continue de penser que c'est une sombre connerie de remplacer partout les « clients lourds » par des navigateurs web, mais j'avoue que coder une appli avec AngularJS est quand même assez agréable.)

Bof. Il reste plein de choses super compliquées à faire en HTML par rapport à un client lourd classique.

Imaginons un cas de travail classique : j'ouvre deux fois le même document, une fois sans y toucher (comme référence), une fois en écriture avec plusieurs vues à chaque fois.

Même pour un truc de base, il faut :
* émuler une mémoire partagée entre les vues correspondant à la même ouverture de document, et répercuter les changements faits dans une vue sur les autres vues
* réécrire un explorateur de fichiers (bah oui, ça serait dommage de pouvoir utiliser un truc tout fait)
* sauvegarder les opérations sur le serveur (faudrait pas que l'utilisateur perde tout avec un F5 malencontreux), mais pas trop quand même (il n'avait pas forcément envie de sauvegarder !)
* exporter sous forme de fichier (parce que l'utilisateur a peut-être envie de le mettre sur clef USB)
* avoir un format de stockage côté serveur qui se prête bien aux lectures/écritures intensives (donc une BDD, mais tous les documents ne s'y prêtent pas) pour toutes les opérations de modification entre deux sauvegardes ; et tu ne peux pas le faire en local parce que l'utilisateur bosse peut-être sur deux machines

Bref, que des trucs fournis naturellement par l'OS mais que chaque application va devoir recoder…

Je ne pense pas que la comparaison soit intéressante. HTML, JS & co ont été conçus pour faire des pages web qu'on consulte, pas des applications lourdes. On essaie de tordre ces technos dans tous les sens et peut-être un peu prématurément, mais s'il n'est par exemple pas possible de gérer des fichiers en JS c'est juste parce que ça n'a volontairement pas été prévu. Si la mode des applications "web" continue je suis à peu près sûr qu'on finira par voir des implémentations standard pour gérer des fichiers, mais bien sûr pour l'instant c'est assez boiteux.

Ça me fait la même impression que si j'avais lu que Java était moins bien pensé qu'HTML parce qu'il faut beaucoup plus de lignes de code pour écrire une page avec un hyperlien cliquable.

[edit] Visiblement l'API en question existe, mais ça doit encore évoluer pas mal.

Flan > Bref, on réinvente l'informatique avec une couche d'abstraction en plus, et au final on n'y a pas vraiment gagné. Mais c'est pas la première fois que ça arrive

Zeph (./322) :
Je ne pense pas que la comparaison soit intéressante. HTML, JS & co ont été conçus pour faire des pages web qu'on consulte, pas des applications lourdes. On essaie de tordre ces technos dans tous les sens et peut-être un peu prématurément, mais s'il n'est par exemple pas possible de gérer des fichiers en JS c'est juste parce que ça n'a volontairement pas été prévu. Si la mode des applications "web" continue je suis à peu près sûr qu'on finira par voir des implémentations standard pour gérer des fichiers, mais bien sûr pour l'instant c'est assez boiteux.

Si l'application web commence à charger les fichiers locaux et à ne plus stocker sur le serveur, il n'y aura plus franchement de différence avec les clients lourds traditionnels, à part que les applis web ne s'installent que dans le cache du navigateur.
Et si on continue à stocker sur le serveur, on aura toujours les problèmes que je cite.

Mais je suis d'accord avec toi, JS n'a pas du tout été pensé pour faire ça à la base, c'est bien pour ça qu'il est chiant. Après, on commence à se retrouver avec des OS complets dans un navigateur web, ça me chagrine un peu de me retrouver avec un OS dans un OS.

./321 > Je vois pas trop le rapport avec ce que j'ai dit en fait…
Tu donnes un exemple « clasique » qui est en réalité un truc assez spécifique (en gros Google drive + Google documents ou One Drive + Office live, quoi… Y'a quelques exemples, mais ça ne court pas les rues non plus )
La plupart des « applications » web tendent à être orientées document plutôt que « fichier » (Soundcloud, DeviantArt, Twitter, Gmail), et en dehors des plateformes collaboratives « temps réel » (ex. Google Docs), tu n'as pas besoin d'une synchronisation active entre "documents". (Genre, c'est une fonction qui a été ajoutée avec Office 2013 chez Microsoft, autant dire que ce n'est pas vieux)
Si tu voulais faire ça tu utiliserais par exemple un truc comme SignalR (i.e. un équivalent dans la techno de ton choix) qui fonctionnerait nickel pour ce scénario.
Exporter sous forme de fichier est bizarrement assez simple, même si pas forcément élégant. (Tu peux faire un round-trip serveur (Oui, j'ai dit que c'était pas très élégant hein), ou bien tenter ta chance avec les API HTML5 relativement bien supportées sur les navigateurs dernier cri.)
Pour ce qui est du stockage côté serveur, même s'il y a une différence notable pour le cas spécifique que tu rencontres, ce n'est pas si souvent le cas en réalité (on a une base de données, relationnelle ou NoSQL, et on stocke des trucs dedans)
Dans le cas que tu mentionnes, une base de données NoSQL pourrait assez facilement faire l'affaire, mais tu pourrais te tourner vers une solution custom avec un cache mémoire dupliqué géographiquement et un service de stockage (mémoire => disque) sur base classique (métadonnées) + disque (répliqué aussi, bien sûr…). Et la ouais pour le coup, ça devient chiant. (Je dirais surtout cher, en réalité )

Bref, oui, y'a certains trucs vraiment chiants que l'on a pas trop intérêt à faire en Web (ça n'empêche pas certains d'essayer), et c'est justement pour ça que je suis plutôt contre la volonté de tout passer en « client léger ». (Et, oui, y'a forcément un jour un gars qui va te demander de coder un éditeur de PDF dans une application web )
Mais quand tu parles de « chaque application », personnellement, je vois ça plus comme une minorité. Si tu regardes les applications populaires auprès des gens, et ce qui se fait en entreprise, c'est quand même relativement simple au niveau interface. (Niveau serveur, après chacun sa merde, mais faut pas croire que la technologie web actuelle aggrave les choses à ce niveau )

Au final, j'aurais tendance à dire que si tu choisis un problème compliqué, la solution va forcément être compliquée à implémenter, mais faut pas foutre ça sur le dos de la technologie

Et c'est quoi le rapport?
Si tu trouve que c'est verbeux, certes mais c'est pas dramatique c'est certainement pas le genre d'objet qu'on utilise 10 fois par jour.

Ça m'amuse, c'est tout.

Ca semble bien corse (cors-ai j'ai pas d'accents ici ) (pas lu la page encore)

http://www.dadhacker.com/blog/?p=2233
Pour Godzil.