J’aime le droit de réponse, et puisque cette personne n’a visiblement pas de blog (et que ça risque de se perdre dans le fin fond du web), je le publie ici, avec son autorisation.

C’est quand Google a enfin pu donner des perfs décentes – c’est à dire celles qu’ont d’autres langage depuis une décennie – à Javascript que les gens ont envisagé de l’utiliser sur le serveur.

Nan, c’est parce que Ryan Dahl a compris l’importance de la programmation asynchrone et que les gens qui font du JS sont déjà dans le moule de l’asynchrone et que c’était donc une communauté facile à convaincre.
C’est juste une bonne coïncidence qu’au moins une VM très performante est dispo.

Node.js massacre beaucoup d’autres langages en performance grâce à l’asynchrone, pas grand chose d’autre, sûrement pas la “vitesse du langage”.

Javascript (…) ne sert absolument à rien sans un framework côté serveur

On compare des choux et des carottes. Un langage (syntaxe, sémantique) ne sert à rien. Il faut toujours des trucs en plus. Dans un contexte web, à quoi sert Ruby sans Rails ?

côté client il est parfaitement improductif sans une lib pour gommer les incompatibilités entre les implémentations.

Le web est un pari ambitieux qui a des coûts. Mais il faut aussi comprendre les enjeux du web. Aucun téléphone ne sort sans navigateur web aujourd’hui. Ca n’est même pas une discussion. Ca a des coûts qui vont avec. On peut rêver d’un autre monde, mais essayons d’avancer dans celui qu’on a entre temps ;-)

Au cas où vous ne l’aurez pas encore compris, je vomis sur Javascript. Mais je code avec, et j’offre même des formations dessus, car je suis pragmatique. Les besoins de l’industrie, l’inertie technologie et le contexte social / technique / économique dictent bien plus souvent les standards que nous utilisons que leurs qualités intrasèques. Sinon nous n’aurions pas utilisé le format .doc ou les VHS.
En fait, je ne détesterais pas autant Javascript si je n’en avais pas besoin quotidiennement. Je le hais du plus profond de mon âme justement parce que c’est non seulement une contrainte inamovible de mon métier, mais en plus une tumeur que les chercheurs annoncent voir grossir de jour en jour. Avec le sourire, les connards !

Bienvenue dans l’humanité ;-)

Les experts recommandent d’éviter la moitié du langage

Du fat d’être langage du web et de la contrainte de backward-compat du web, JS ne peut pas se débarrasser de ses bad parts. J’ai donné un talk sur le sujet. Être efficace en JS nécessite de comprendre un peu son histoire et les pièges à éviter. C’est le coût d’être le langage du web. Mais c’est bien le web, non ? Ca vaut le coup, non ?

En fait activer use strict dès que possible pour éviter l’insertion de ; automatiques.

wtf? N’importe quoi ! La spec ECMAScript 5 est la référence pour les différences entre strict et “sloppy” mode. Pour des ressources un peu plus digestes :
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions_and_function_scope/Strict_mode
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions_and_function_scope/Strict_mode/Transitioning_to_strict_mode

Cependant, faites gaffe quand vous convertissez du code parce que :

=> a = 1
1
=> var a = 1
undefined

Mais c’est quoi ce business de la désinformation !!
a = 1 est une expression qui permet de faire a = b = 1, donc sa valeur est la valeur de la sous-expression de droite. var a = 1 n’est pas une expression (if(var a = 1){} est une SyntaxError), donc le REPL se contente de retourner undefined, mais ça n’a aucune importance en pratique.

Ah oui, et ne pas utiliser les mots clés new ou with pour vos propres libs. Si, si, on bannit carrément des mots clés, c’est écrit dans le livre.

Douglas Crockford est une seule personne. On a le droit aussi de ne pas être d’accord. Utiliser with, c’est souvent se tirer une balle dans le pied, d’où le bannissement dans le strict mode. Mais new, c’est plus une question de style. Je suis assez expert JS, j’utilise new et je le vis bien.

Faire du JS propre présuppose l’utilisation de design patterns
En l’état, on ne peut pas écrire du JS propre.

En français aussi, il y a des figures de style. En l’état, on peut écrire du JS propre. Je veux bien admettre que ça exige beaucoup plus de disciplines que d’autres langages, mais ça s’arrête là. Encore une fois, JS est obligé de porter le poids de son histoire parce que c’est le langage du web.

Au fait, vous avez déjà essayé d’expliquer le prototypage à quelqu’un ? Bonne chance !

http://davidbruant.github.io/ObjectViz/

J’ouvre Firefox, je tape [] + {}

J’écris ça quotidiennement aussi, ça m’aide beaucoup pour écrire des interfaces facilement utilisables par les utilisateurs. [] + {} créé aussi des méta-promesses qui permettent de faire de l’asynchrone un peu plus rapide que la vitesse de la lumière.

Si tu additionnes des choux et des carottes, faut pas s’étonner. Si des fois, tu es fatigué, utilise TypeScript pour aider avec la discipline.

chaines multilignes

Ca arrive dans ES6 https://gist.github.com/lukehoban/9303054#template-strings

list compréhension à la Python

ES6 : https://gist.github.com/lukehoban/9303054#comprehensions
Implémenté dans Firefox et dans la Nightly depuis la semaine dernière.

Et encore, je suis cool, je mets un code JS qui utilise l.length directement dans la boucle et pas de variable pour l[i].

Nan, mais c’est bon, on est en 2014, plus besoin de ces conneries :-) Y’en a jamais eu besoin, c’était juste de la micro-optimisations de gens qui pensaient que ça avait un impact significatif après qu’ils aient fait un micro-benchmark sur le sujet.

Array.map arrive avec JS 1.6 et les arrays comprehensions avec la 1.7…

Cute :-)
Array.prototype.map, on peut le polyfiller

JavaScript 1.6, 1.7, ça n’existe pas. C’est des gens chez Mozilla, ils étaient bourrés (Brendan Eich a continué à boire même après avoir créé et shippé JS en 10 jours), ils ont donné des numéros de version, après le mot “JavaScript”, mais c’était pour rire (c’était lié au numéro de version de SpiderMonkey, moteur JS de Firefox). Seuls les numéros de spec d’ECMAScript ont un sens un peu sérieux.

que vous pourrez utiliser sur tous les navigateurs d’ici 2056.

.map tu peux l’utiliser depuis des années. Les array compréhension, ça marche sur Traceur

PASramètre
Comment on fait ça en Javascript ?

Tiens https://gist.github.com/lukehoban/9303054#default–rest–spread
J’ai utilisé ça en TypeScript (mais ceux qui préfèrent Traceur peuvent aussi choisir ça) sur un vrai projet qui tourne sur de vrais mobiles il y a presque un an.

Ah mais il faut utiliser coffeescript !
Oui donc pas Javascript. Point made.

Jeremy Ashkenas, inventeur de CoffeeScript le décrit en disant “it’s just JavaScript”. Je dis ça…

Vous trouvez ça normal ?
Vous trouvez que c’est le signe d’un BON langage ?

Aucune importance. C’est ce qu’on a, il faut vivre avec, bon gré mal gré.

Gros bisous,

David

Ruby and Python. Two languages. Two communities. Both have a similar target: to make software development better. Better than Java, better than PHP and better for everyone. But where is the difference? And what language is “better”? For the last question I can say: none is better. Both camps are awesome and do tons of great stuff. But for the first question the answer is longer. And I hope to provide that in this little article

Is the difference in the toolset around the language? No, I don’t think so. Both have good package managers, tons of libraries for all kind of stuff and a few decent web frameworks.

Heu… si. Il y a une énorme différence.

Ruby a RVM, un truc enorme et très difficile à mettre en oeuvre. Python a virtualenv, un truc léger et très simple à faire passer. Conséquence ? Une grande partie des rubistes n’utilisent pas RVM et leurs projets souffrent de problèmes constant de compatibilité. Combien de fois j’ai vu des gems install planter à cause de ça…

Et combien y a-t-il de RAD pour faire des applications en Ruby ? Ca influe sur le nombre d’applications desktop écrites en Ruby.

Combien y a-t-il d’outils pour facilement interfacer Ruby avec d’autres technologies ? Python est utilisé massivement comme langage d’extensions à cause de ça (Sublime Text, Blender, Nautilus, Inscape, etc).

Quant aux libs. On utilise Ruby pour quoi en dehors du Web ? Développement de jeu ? Sur tablette tactile ? Simulation scientifique ? Application desktop ? Très peu. Alors que Python est utilisé pour tout ça. La raison est justement le large panel de libs. Python a beaucoup, beaucoup, beaucoup plus de libs que Ruby.

Youhou ! Pour accéder à Internet, on utilise un ordinateur plein de trucs qui ne sont pas sur Internet ! Pour servir un site Web aussi !

L’écosystème, c’est la moitié de l’intérêt d’un langage. Je ne retire pas à Ruby le mérite de la qualité du sien: il est innovant, dynamique, sa communauté est fantastique. Mais on est loin d’avoir dans Ruby le dixième des outils et libs qu’on a en Python. C’est pour ça que Mac embarque embarquait Python par défaut et pas Ruby. C’est pour ça qu’Ubuntu est massivement codé en Python et pas en Ruby. Ca fait toute la différence.

I think there is something else that is way more important. The culture.

+ 1. Et Ruby en a une excellente. Faites un bisou aux gars de 37 signals.

Okay, now what is the difference in the culture? It is pretty easy. Python folks are really conservative and afraid of change, Ruby folks love the new shiny stuff even if it breaks older things. It’s that simple. But it has huge consequences.

Ce n’est pas la seule différence, mec. Les rubistes sont vachement plus sympa, d’une manière générale. Les pythonistes que je connais sont généralement assez blafards. Compétents, mais pas funny fun. Et les rubistes sont plus actifs socialement, du coup: plus d’events, plus d’articles de blog, plus de vidéos… Et ça, c’est un gros plus pour Ruby.

Mais d’un autre côté, Python a la culture des comptable: du code lisible, et de la documentation. Et comme c’est un peu mon job de lire le code 500 fois par jour et de fouiller dans la doc, c’est très important pour moi. Les docs Ruby, parfois, c’est vraiment une grosse blague. Regarder dans le code source n’est pas un bon palliatif. Une doc indique une manière officielle de faire, une manière figée, stable, qu’on va pouvoir utiliser et supporter sur des années. C’est important.

One you can see for example in the adaption of Ruby 1.9 vs Python 3. Both new versions did tons of breaking changes. A lot of code needed changes to run on the new plattform. In the Ruby world the transition went pretty quick. In the Python world it is very troublesome. Some Python people even say that Python 3 is broken and all energy should be focused on the 2.x-branch of the language. The Ruby community saw the opportunities. The Python community only saw the update problems. Yes, there have been update problems in the Ruby world, but we found an easy way to fix this: isitruby19.com. A simple plattform that showed if the gem is ready for 1.9. And if it wasn’t and the gem was important, it got fixed with pull requests or something similar. And the problems went away fast.

Ouai mais tu vois (tu me permet de te tutoyer ? en anglais on s’en fou de toute façon…), c’est vachement plus facile de tout péter quand on a pas deux OS majeurs qui se basent dessus. Je sais pas si tu as déjà essayé de faire upgrader un repo complet de milliers d’apps open sources, mais ça prend du temps.

Oh, et Python est là depuis vachement plus longtemps que Ruby. Python était même là avant Java. Chaque corps de métier à un sacret paquet de code à faire migrer, et ils sont pas tous en lean management super agile mega scrum mode, eux. Les biologistes qui utilisent Python pour faire leurs simulations depuis 10 ans, ils ont pas que ça à foutre d’upgrader leur code. Pour eux la prog, c’est pas “Fuck yeah, new features, I’m going to touch myself on Vx and migrate”. Pour eux c’est 7 ans de scripts d’analyse de génome à se retaper alors que ce n’est qu’un outil ennuyeux à leurs yeux.

Both models of thinking have pros and cons. The Python world is more stable, you can update your django installation without much troubles. But that also means new technology is only added very slowly. The Ruby world loves changes.

La différence majeur entre Rails et Django ? Rails: chaque version stable possède des gros trous qu’ils bouchent au fur et à mesure, parce que c’est pas grâve, on est flexible et adaptif mec, on release early et often. Django, en version 0.96, tout le monde l’utilisait déjà en production car le truc était rock solide.

Alors oui, y a moins de features. Mais ma plateforme ne m’explose pas à la gueule. Et pip installe fonctionne.

So much that most of the “new stuff” in the Python world was tested in the Ruby world first.

Ca c’est vrai. Merci d’ailleurs. Mais encore une fois, on parle d’une catégorie de libs qui se limitent au dev Web. C’est le même débat que “Mac est innovant”. C’est certain, quand on a une archi et 3 modèles à supporter, c’est plus facile de faire un truc innovant: on a pas à supporter de compatibilité.

We love changes so much that the Rails core is build around that idea. You can easily change nearly everything and extend everything. Most of the new stuff the Rails Core Team is testing right now for version 4 is available as plugin for Rails 3. This is pretty interesting if you love new things, love change, and love playing around with stuff. If you don’t and hate the idea of breaking changes, you maybe are better suited with the Python way. But don’t be afraid of breaking changes. They are all pretty well documented in the release guides. It’s not voodoo.

Si. C’est carrément du voodoo. Le monkey patching des objets built-in, c’est la porte ouverte à toutes les fenêtres, et quand deux libs le font en même temps, BOUM.

Et le nouveau, c’est marrant. Je suis pour le nouveau. Max m’engueule tout le temps car je veux essayer les trucs nouveaux. Mais pas instable. L’écosystème de Ruby est instable. Si les langages étaient des OS, Java serait Debian, Python serait Ubuntu LTS, Ruby serait Ubuntu RC. J’utilise la dernière Ubuntu pour mon desktop, parce qu’avoir Unity qui plante une fois par jour ne me dérange pas. Mais sur le serveur, je prends la version la plus stable, parce que j’ai pas besoin de <blink>, j’ai besoin de <strong>.

I for myself love the Ruby mindset. Something like Rails or Asset Pipelines or all the other things would not be possible if we are stuck with “no, don’t change that, it works pretty well that way”. Someone has to be the leader. Someone has to play around with new ideas. Yes, some ideas won’t fly, some are removed pretty quickly. But at least we tried them. Yes, I know that some people prefer the conservative way. If you consider yourself to be like that, you should at least try Python. I stay with Ruby.

C’est vrai qu’on ne fait rien d’innovant en Python: programmation du rasberry py, simulation neurale, facilitation du parsing d’arguments, création du meilleur protocole d’échange en P2P au monde… Ah, par innovation tu veux dire une énième lib Web ? Pardon, je croyais qu’on parlait de programmation au sens large du terme.

Dans ce cas: Twisted était là bien avant event-machine (ou même NodeJs). Wep.py était là avant Sinatra. Virtualenv était là avant RVM. Zope était là 6 ans avant ROR avec son ORM et son langage de template.

Et oui, vous avez bien amélioré tout ça. Et c’est génial. C’est comme ça que ce doit être. Mais arrêtez de vous prendre pour l’élément indispensable de l’innonvation de la programmation Web moderne. Vous n’êtes pas tous des Jason Fried. Et là plupart des choses que l’on fait aujourd’hui on été inventé par les mecs de Lisp, Haskel et Smalltalk de toute façon, qui eux même se sont inspirés de l’amont. On giant shoulders, tout ça, tout ça…

Quand on demande pourquoi je préfère Python à PHP, je réponds souvent que Python est beaucoup plus simple à utiliser. C’est généralement le moment où tout le monde me répond que PHP est justement un langage qui a eu du succès parcequ’il était simple.

Faux.

PHP a eu du succès parcequ’il a une excellente doc, des tutoriaux partout sur le net, et une méthode de déploiement facile proposée pour la plupart des hébergeurs.

Le code lui-même, n’est pas simple du tout. Prenez par exemple la fonction de base pour ouvrir un fichier, fopen().

@fopen('http://example.com/not-existing-file', 'r');

Savez vous ce que ce code va faire ?

Si PHP a été compilé avec --disable-url-fopen-wrapper, ça ne marchera pas. “Ne marchera pas” veut-il dire retourner null ou lever une exception ? Aucune idée, la doc ne le dit pas. De toute façon cette option est retirée avec PHP 5.2.5, et nous sommes en PHP 5.3.10 sur la plupart des distribs. Sauf sur la plupart des hébergeurs…

Si allow_url_fopen est désactivé dans php.ini, ça ne marchera pas non plus. Aucune idée de pourquoi.

Grâve à ce merveilleux “@”, le warning en cas de fichier n’existant pas ne sera pas affiché pas vrai ?

Sauf bien sur si scream.enabled est activé dans le php.ini ou manuellement avec ini_set.

A condition que le niveau error_reporting soit ajusté en conséquence.

Mais alors sa sortie dépend du paramètre display_errors, lui même activable dans le php.ini ou par ini_set.

Et si par un hasard incroyable vous savez tout cela, savez-vous comment est configuré votre hébergeur ?

This is going to be legend…

Après il est vrai que l’écosystème de Python, lui, possède une richesse qui le rend complexe. et le déploiement n’est pas aussi simple qu’avec PHP. D’ailleurs, je ne prétend pas qu’on ne puisse pas coder d’excellents produits avec PHP. Mais ce n’est pas grâce à la prétendue simplicité du langage (Ruby et même Javascript sont plus simples).

Le Web utilise par exemple massivement le JSON. Mais saviez-vous que json_decode retourne null en cas d’erreur de décodage ? Ce qui est aussi une valeur de retour de décoage de JSON valide, vous forçant donc à a vérifier json_last_error à chaque appel.

Je vous passe l’habituelle critique de la surabondance de fonctions PHP pour faire des choses similaires, mais avec des noms complètement à l’arrache (chercher du texte: ereg, eregi, mb_ereg, mb_eregi, preg_match, strstr, strchr, stristr, strrchr, strpos, stripos, strrpos, strripos, mb_strpos, mb_strrpos) ainsi que de l’inutilité totale du signe == ("foo" == true, et "foo" == 0 mais true != 0).

Par contre, quelqu’un pourrait m’expliquer pourquoi les noms des variables sont sensibles à la casse, mais PAS ceux des fonctions et classes ?

Et vous voulez vérifier qu’une variable est vide ou n’existe pas ? empty() est là pour ça ! Sauf que empty($var) marche, mais empty($var1 || $var2) lève une exception.

…wait for it…

En parlant d’exception, amusons nous un peu avec la gestions des erreurs:

• la généricité c’est pas pour demain: curl_error, json_last_error, openssl_error_string, imap_errors, mysql_error, xml_get_error_code, bzerror, date_get_last_errors…
• on autorise à rendre les erreurs silencieuses avec ‘@’ (wtf ?)
• pas de stack trace. Un bug ? Démerde toi. Le langage est en typage faible, tu vas t’amuser !
• :: est nommé T_PAAMAYIM_NEKUDOTAYIM et <<, T_SL, et la première fois qu'on le voit dans un message d'erreur, ça fait tout drôle. Il vaut mieux ne pas être déconnecté.
• E_ALL inclue toutes les catégories d'erreur. Sauf E_STRICT. Quelqu'un sait à quoi sert E_STRICT ?
• on a pas le droit de lever une exception dans __toString ! Si on le fait, PHP balance une erreur fatale, et ...
• ... les erreurs fatales ne peuvent pas être gérées dans un try/catch. Et de toute façon il n'y a pas de clause finally.

Et quand PHP évolue, au lieu de corriger ce bordel, on rajoute une couche !

Par exemple, PHP est faiblement typé. Sauf qu'on peut maintenant forcer le type des paramètres d'une fonction en donnant ce qu'on appelle des type hints. Sauf qu'on qu'on ne peut pas choisir "string" ou "int" ni aucun type de base pour cela. Sauf que les fontions de les bibliothèques standards elles, le font sans problème. Il faut donc utiliser une classe que l'on fait soit même. Sauf que les "type hints" acceptent une classe non déclarée comme type (faute de frappe mon ami...). Sauf que dans ce cas on ne peut passer aucun argument à la fonction. Absolument aucun.

Par contre, mettre des arguments nommés pour les fonctions, ça, on ne le rajoute pas. Ca rendrait le code plus bordélique, et il faut garder le langage simple. C'est d'ailleurs, j'en suis certain, au nom de cette simplicité que mktime a pour ordre d'arguments: heure, minute, seconde, mois, jour, année.

... dary !

Heureusement il y a des fonctions cachées qui font que PHP est vraiment un langage pour faciliter la vie du débutant:

preg_replace avec le flag /e prend la chaine, effectue le remplacement, et ensuite fait un eval() dessus !

scandir retourne une liste de fichiers dans un dossier, mais pas dans l'ordre du dossier. Non, ce serait pas fun. Il les retourne dans l'ordre alphabetique, ou l'inverse si on lui passe un argument. Ce qui est logique, puisque PHP est bien connu pour manque de fontions de tris: array_multisort, arsort, asort, ksort, krsort, natsort, natcasesort, sort, rsort, uasort, uksort, usort.

parse_str ne parse pas une chaîne, mais une "query string". Qu'il dump ensuite dans l'espace de nom local. A moins qu'on lui passe un array à populer. Mais dans tous les cas la fonction ne retourne rien.

gzgetss parse les lignes d'un fichier *.gz et en retire les ligne HTML. Indispensable dans la vie de tous les jours, ça valait le coup d'en faire une fonction built-in. Hier encore je me demandais comme j'aillais rajouter cette opération à toutes mes vues Django.

php_uname retourne l'OS courrant, mais en cas d'échec, il retourne silencieusement l'OS sur lequel il a été compilé.

Et les arrays... Cette structure de donnée magique qu'on aime tant quand on commence à programmer. Ca fait tout, tout je vous dis !

Les arrays sont une combinaisons de lists, ordered hashes, ordered sets et sparse lists. Là ou c'est amusant, c'est quand on tente de les comparer:

array_diff(array("marc" => 12, "alice" => 23),
           array("marc" => 23, "alice" => 12));

Quel comportement vérifier, celui d'une liste, d'un set ou d'un mapping ?

Ici la réponse est un set, ce qui fait que les deux arrays sont considérés comme égaux.

Par contre:

array("foo", "bar") != array("bar", "foo")

Et:

array("foo" => 1, "bar" => 2) == array("bar" => 2, "foo" => 1)

Tient, tant qu'on est dans la prédictibilité de comportement. Puisque PHP est un langage simple, quelqu'un peut me prédire ce que ça fait ?

php > $a = null;
php > $a++;
php > echo $a;

Non ?

Ben ça a affiche 1. Si, si.

Mais comme on aime bien la congruence chez Zend:

php > $a = null;
php > $a--;
php > echo $a;

Ça n'affiche rien.

Et pour finir sur une petite note de sécurité spécial noob: include accepte une url en paramètre.

J'ai passé des années à coder en PHP. J'ai vu du code très propre faire des choses très belles. Ce n'est pas grâce au langage, mais en dépit de lui.

Je suis heureux que le langage ai eu un tel succès. Il a permis au Web de devenir ce qu'il est. Il est temps maintenant de passer à autre chose.