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

Celui-ci est plutôt classe
http://en.wikipedia.org/wiki/Duff%27s_device

Ha ouais j'aime bien ça ! Je n'y avais pas pensé.

C'est un grand classique

http://www.jansch.nl/2007/03/09/systemoutprint-in-php/ (vu dans l'article)
Le PHP ne cesse de m'étonner. Y'a une vraie inventivité en matière de misfeatures dans ce langage.

Arg

J'imagine que c'est pour pas casser ce genre de construction qui était valide il y a quelques siècles en PHP : $tableau[index] (index devient "index", et hop miracle, sauf si par malheur il y a effectivement une constante "index" définie). J'ai encore ~100mo de log d'erreur/jour à cause de trucs comme ça qui traînent encore un peu partout dans le code de yN d'ailleurs :/

100Mo par jour ?!
Ouch

http://www.eecs.qmul.ac.uk/~mmh/APD/hacknot_book_a4.pdf
Un livre de chroniques diverses et grinçantes sur le développement. Attention, le mec est anti-design patterns, XP et Agile

Quand j'en vois qui critiquent CakePHP que j'utilise dans tous mes projets professionnels comme quoi il s'agit d'un framework vieillissant (le premier framework MVC de PHP), traînant des casseroles (la 1.x nécessite PHP4 minimum, la 2.x PHP5.2), imposant le système Ruby "conventions > configuration" (ce qui peut être overwrité pourtant), qui copie sur ses voisins (parce qu'adopter pour la v3 des concepts déjà existants dans Symfony 2, Zend ou Lavari, c'est admettre qu'on n'est pas le top du top), j'aimerai leur parler que leur framework "tellement supérieur" se base sur un langage daté, incohérent et très largement critiqué, vu comme un mal nécessaire, et que s'ils allaient au bout de leur réflexion il leur serait inutile de défendre le framework PHP de leur choix puisqu'ils auraient déjà transité sur un autre langage pour faire du web.

Et accessoirement leur coller des baffes. Cela m'est venu après avoir vu sur un forum PHP généraliste quelqu'un demander des news sur l'avancée de CakePHP3, un admin (un admin, merde quoi) s'est cru bon de répondre (et insister par la suite) que CakePHP était rempli de défauts et qu'au lieu de songer à la version suivante, il devrait transiter sur un "vrai" framework.

Ouais, par exemple ASP.NET WebAPI + AngularJS

Vous utilisez JSON, mais la concision et la légèreté légendaires du XML vous manquent ? Rassurez-vous, IBM a une solution pour vous !
http://what.thedailywtf.com/t/ibms-jsonx-or-how-to-represent-json-in-xml/3972

Han !

Meowcate (./399) :
Quand j'en vois qui critiquent CakePHP que j'utilise dans tous mes projets professionnels comme quoi il s'agit d'un framework vieillissant (le premier framework MVC de PHP), traînant des casseroles (la 1.x nécessite PHP4 minimum, la 2.x PHP5.2), imposant le système Ruby "conventions > configuration" (ce qui peut être overwrité pourtant), qui copie sur ses voisins (parce qu'adopter pour la v3 des concepts déjà existants dans Symfony 2, Zend ou Lavari, c'est admettre qu'on n'est pas le top du top), j'aimerai leur parler que leur framework "tellement supérieur" se base sur un langage daté, incohérent et très largement critiqué, vu comme un mal nécessaire, et que s'ils allaient au bout de leur réflexion il leur serait inutile de défendre le framework PHP de leur choix puisqu'ils auraient déjà transité sur un autre langage pour faire du web.

Et accessoirement leur coller des baffes. Cela m'est venu après avoir vu sur un forum PHP généraliste quelqu'un demander des news sur l'avancée de CakePHP3, un admin (un admin, merde quoi) s'est cru bon de répondre (et insister par la suite) que CakePHP était rempli de défauts et qu'au lieu de songer à la version suivante, il devrait transiter sur un "vrai" framework.

Je regarderai quand la version 3 sortira, je connais symfony2 perso, mais pour des petits projets des fois ca fait un peu overkill. Du coup je m'interesse a Laravel et Silex, mais je jetterai un coup d'oeil a cake a l'occasion

Zerosquare (./402) :
Vous utilisez JSON, mais la concision et la légèreté légendaires du XML vous manquent ? Rassurez-vous, IBM a une solution pour vous !
http://what.thedailywtf.com/t/ibms-jsonx-or-how-to-represent-json-in-xml/3972

Ce n'est pas forcément idiot suivant les cas d'utilisations. Bien évidement, ce genre de chose n'est clairement pas fait pour être utilisé dans le cas le plus courant ou on veut un document concis et facilement lisible.
Par contre ça peut être utile si on a besoin d’intégrer un Json quelconques dans des applications qui a été conçues pour traiter automatiquement des xml quelconques.

Tiens, MS trolle les utilisateurs de SQL Server.

Les enfoirés...

Je ne comprends pas son souci, selon la description ça ne fait ça que jusqu'à 1000, donc même dans son exemple avec 32767 à partir de 1000 il est tranquille et peut y aller avant de remplir la table…

Apparemment, dans les versions précédentes les valeurs étaient toujours consécutives, sauf cas rares. Et pas mal de gens ont utilisé ces valeurs dans des processus où il ne faut pas qu'il y ait de "trous" dans la numérotation (des numéros de facture, par exemple). Du coup, ils sont bien embêtés

Ouais ben alors là ce sont eux les cons. C'est souvent comme ça et pas seulement chez MS. Par exemple on incrémente le n° d'enregistrement par 3 ou 5 pour laisser de la place au besoin (et tracker les scripts de migration qui font n'importe quoi ).

Certes, MS n'a jamais garanti que les valeurs soient consécutives. Après, c'était une supposition assez largement répandue apparemment, et la modif dans la nouvelle version est uniquement pour avoir de meilleures perfs (et elle est désactivable). Du coup, c'est pas une super idée de l'avoir activée par défaut, je trouve.

Ceci dit, ça s'inscrit bien dans la mentalité actuelle de MS : avant ils étaient très conservateurs et privilégiaient la rétrocompatibilité, maintenant ils n'hésitent plus à faire des changements lourds et à casser des trucs.

Et ils ont mes encouragements à 200%. Ras le cul de se trainer des casseroles ms-dossiennes, de toute façon ça n'aurait pas été supportable à l'infini...

./411 > Y'a le même comportement chez Sybase je crois, du moins d'après ce que j'ai compris… Mais je l'ai jamais constaté en pratique. (Faut quand même te trouver dans un cas bien particulier pour que ça se produise)
./412 > Ils sont malgré tout assez conservateurs là dessus, mais ils essayent d'orienter les décisions dans le bon sens quand ils peuvent. C'est surtout qu'ils ont du finir par se rendre compte que même en se pliant en 4 pour que le code de merde des clients ne plante pas sur leur nouvelle plateforme, quand il y a un souci, c'est toujours pour leur gueule. Ça permet peut-être de relativiser un peu et de te dire que quitte à péter un truc, autant le faire pour une bonne raison (Par contre, ils ont toujours un boulot de dingue pour maintenir les nombreux hacks de compatibilité de Windows, spécifiques aux applications, mais peu de gens le réalisent)

Pour faire un parallèle (en rapport avec le topic, je pense), c'est un peu comme en JavaScript. Tu peux énumérer les propriétés d'un objet, et la spec JavaECMAScript te garantit explicitement que l'ordre n'est pas prévisible. Pour autant il y a toujours des gens qui se croient trop malins et décident de supposer que l’ordre est prévisible (PS: C'est plus simple que de coder proprement): De fait, c'était le cas avec les anciens navigateurs. Du coup par souci de rétro-compatibilité, c'est aussi le cas des nouveaux (dans une certaine limite…), sauf que ça empêche en toute logique certaines optimisations de performances (et/ou mémoire).
Bref, ça te fait un cercle vicieux, et il n'y a que deux solution: soit foutre cette mécanique rétro-compatible en l'air, soit la normaliser définitivement. (Perso je suis presque toujours dans le 1er camp )

(pour le JS, la bonne solution serait surtout d'abandonner ce langage)

(pour l'instant, y'a pas trop le choix d'autre chose pour faire du code qui tourne dans une page web côté client)

GC > je pense que ça se produira tôt ou tard, le monde du dév web privilégie plus les évolutions que la compatibilité (et la stabilité de manière générale).

Il faudrait concevoir un langage plus efficace, créer des plugins pour chaque navigateur afin que cela puisse le faire tourner, et attendre qu'il soit suffisamment répandu pour être intégré aux navigateurs... que de chemin à parcourir.

Comme Flash par exemple.

-

./414 : je ne vois vraiment pas l'intérêt d'abandonner le seul langage de script implémenté dans tous les browsers principaux, d'autant plus qu'il est suffisamment simple pour pouvoir servir de langage cible à tous les gens qui veulent un remplacement pour des raisons de syntaxe ou de performance, etc (CoffeeScript, TypeScript, asm.js, etc...)

Brunni (./417) :
Comme Flash par exemple.

Flash est un outil qui a réussi car il a su mettre a disposition des graphistes des outils fait pour eux et qu'il a su intégrer les fonctionnalités multimédia qui manquaient au HTML.
Mais au niveau du langage de programmation lui même, ça ne vaut pas mieux que du JavaScript.