Dès qu’il y a une tendance, on voit les fanboys sortir leurs dentiers éclatant pour vous faire des démos ventant le produit qui retire toutes les tâches et si vous appelez maintenant il y a 20% de réduction.
Mais tout comme à la télé le magic bullet fait le smoothie en seulement 2 minutes parce que le mec commence la vidéo avec 10 fruits déjà choisis/payés/livrés/lavés/épluchés/découpés, la techno qu’on vous vend a ses travers.
C’est normal. Mais c’est rarement dit.
Ces dernières années, NoSQL, la programmation asynchrone, la programmation fonctionnelle et les projets JS, Node en tête, ont été sur toutes les chaînes : si vous avez pas programmé votre chat avec Mongo + MeteorJS avant 50 ans, vous avez raté votre vie ! Appelez le 5555-5555 et recevez un pins Haskell qui vous créé une copie de votre pull quand vous l’accrochez.
C’est pas qu’il y a une arnaque, c’est juste qu’il y a un truc qu’on appelle la réalité.
Par exemple, aujourd’hui, je tombe sur un projet appelé pymaybe qui implémente le pattern fonctionnel monadique maybe. Je déconne pas, c’est le terme technique.
Je taquine, mais je trouve le projet sincèrement intéressant. Néanmoins la page d’exemple reflète typiquement l’esprit Pierre Bellemare.
Ca commence par un exemple Python soit disant trop long :
def get_user_name(): current_user = request.user if current_user: return current_user.name return '' |
Converti en :
def get_user_name() : return maybe(request.user).name.or_else('') |
Mais c’est très maladroit, car on résout ici un problème qui n’existe pas. En effet, personne écrivant du Python professionnellement (et qui serait donc intéressé par ce projet) n’écrirait le premier exemple ainsi. Un code de prod serait :
def get_user_name(): return getattr(request.user, 'name', '') |
Ce qui est plus court que les deux snippets ci-dessus, immédiatement reconnu par des pairs, et ne demande pas d’ajouter une dépendance externe à son code.
Le second exemple est plus trompeur encore, et commence par cet extrait :
stores = json.get('stores') if stores: products = stores[0].get('products') if products: product_name = products[0].get('details', {}).get('name') or 'unknown' |
Et avec “coder builder 3000″ vous pouvez faire :
product_name = maybe(stores)[0]['products'][0]['details']['name'].or_else('unknown') |
Impressionant ! C’est la barre de fer !
Sauf que… Avez-vous remarqué ? Le json.get() est passé à la trappe…
stores = json.get('stores') product_name = maybe(stores)[0]['products'][0]['details']['name'].or_else('unknown') |
Et puis d’où vient maybe() ? Ce n’est pas un builtin… Donc il faut l’importer, comme pour les fruits du mixer qui ne se découpent pas tout seuls.
from pymaybe import maybe stores = json.get('stores') product_name = maybe(stores)[0]['products'][0]['details']['name'].or_else('unknown') |
Et si vous avez un editeur bien réglé, la 3eme ligne va lever un warning PEP8 : 85 charaters, c’est 5 de trop (sinon on peut écrire tout son script sur une ligne aussi).
from pymaybe import maybe stores = json.get('stores') product_name = maybe(stores)[0]['products'][0]['details']['name'] product_name = product_name.or_else('unknown') |
Ah, plus qu’une seule ligne d’avantage par rapport à la version originale. Mais une seconde, cette version vous l’écririez ainsi ? Bien entendu que non :
try: product_name = json.get('stores')[0]['products'][0]['details']['name'] except (TypeError, KeyError, IndexError): product_name = 'unknown' |
Ce qui a en prime l’avantage de montrer explicitement les cas dans lequels product_name = 'unknown', plutôt que de devoir savoir ce que fait exactement une lib tierce partie (qui doit en plus être déployée). Et si il y a une erreur en plus qu’il faut gérer ? TypeError ? IoError ? C’est juste une clause de plus. Pour l’autre version, on rajoute 4 lignes.
Attendez, ce n’est pas fini. Il est facile de croire, quand on vient d’un autre langage, que Python est un langage simpliste. Il se traine sa réputation de langage jouet depuis bien longtemps. Erreur classique !
Car Python est très simple à prendre en main, mais possède énormément de profondeur.
__getitem__, anyone ?
(test) >>> class Test: def __getitem__(self, value): return 1 ...: (test) >>> maybe(Test())[0] --------------------------------------------------------------------------- AttributeError Traceback (most recent call last) <ipython-input-6-e4a755e77e5b> in <module>() ----> 1 maybe(Test())[0] /home/sam/.local/share/virtualenvs/test/local/lib/python2.7/site-packages/pymaybe/__init__.pyc in __getitem__(self, key) 212 213 def __getitem__(self, key): --> 214 return maybe(self.__value.get(key, None)) 215 216 def __setitem__(self, key, value): AttributeError: Test instance has no attribute 'get' (test) >>> Test()[0] 1 |
defaultdict ?
(test) >>> maybe(defaultdict(datetime.utcnow))[0] None (test) >>> defaultdict(datetime.utcnow)[0] datetime.datetime(2015, 7, 30, 19, 39, 28, 298488) |
Cela signifie-t-il que ce projet ne mérite pas d’être suivi ? Pas du tout, le principe est sympas, ça doit être creusé. Simplement il faut se méfier du mimi, du rara, du miracle.
Si vous relisez les articles sur WAMP et crossbar, vous noterez que je souligne clairement les problèmes de la techno : doc, debugging, syntax twisted… Personne ne demande d’être impartial, mais faut pas non plus vendre la vessie de l’ours avant la lanterne des boeufs.
Petite typo en fin d’article : “Pas du tout le principe est sympa, ça doit être creusé”
En tout cas article très intéressant. Comme dans tout les domaines, il ne faut ni se laisser influencer aveuglément par les modes, ni les rejeter en bloc.
Cimer
En fait c’est surtout une question de bonne pratique : je me refuse systématiquement à utiliser ce genre de “petites librairies tierces” qui à première vue semblent faciliter le boulot mais qui impliquent de se les coltiner tout le long du projet sans réelle garantie de maintenance future, et quand c’est possible je privilégie ce que la librairie standard m’offre, même si malheureusement je n’ai pas toujours les bons réflexes (typiquement defaultdict je n’y pense jamais).
Cependant, comme dans toute règle, il y a quelques exceptions notables comme requests.
Ça serait vraiment cool Max si tu nous faisais un petit article de trucs & astuces mal connus de la librairie standard qui facilitent la vie !
“Plus trompeur encode” c est la version unicode de “plus trompeur encore” ?
:p
En effet, toujours garder son esprit critique malgré le côté fashion de certaines personnes dans l’IT, cf. Docker, react.js, et surtout, surtout, surtout, AsyncIO #humour ;-)
Dis autrement, pour moi, il faut d’abord cartographier ses besoins, puis prendre la température dans l’existant et en fonction, prendre un produit tout fait, assembler un outil ou encore le construire soi-meme, mais clairement pas suivre religieusement la mode.
Un des + grand travers que nous avons dans le développement, c’est d’aimer les outils compliqués: bien que ça flatte l’ego et inconsciemment permet de faire du job protection, ça rend + complexe le debug, la prise en main pour les new comers, ça rend la solution moins agile pour s’adapter aux futurs besoins.
Dans ce cas précis, à part pour se la péter auprès de ses pairs parce qu’on fait des nomads en Python, non, je ne vois pas non plus l’intérêt.
Laissons Darwin faire pour voir si ce pattern émerge à l’avenir ;-)
Par contre, c’est aussi tout à fait possible que nous sommes juste des vieux cons et qu’en fait, il y a un p’tit jeune qui a trouvé une manière 14 fois + efficiente de travailler, Who knows?
@Ludovic :Certains ont surtout tendance à choisir la techno et ensuite à réfléchir à la solution.
Déjà eu affaire à des boites qui me demandait un produit développé avec Angular sans réel cahier des charges mais avec cette idée fixe en tête. (Le concurrent principal venait tout juste de dévoiler sa nouvelle application développée justement à l’aide d’Angular)
Pas tout compris mais il y a une typo :
plus trompeur encode, et => plus trompeur encore, et
Merci pour les typo. Rendons à Caesar ce qui lui appartient, l’auteur de la lib est très réactif et constructif : https://github.com/ekampf/pymaybe/issues/1
L’effet mode c’est horrible mais le pire c’est quand tu conjugues l’effet mode avec l’effet pas de documentation.
Genre je voulais tester le truc de kikoolol API-HOUR qui annonce en première page des benchmarks de dingue…Sauf que leur doc est pourrie voire inexistante.
Un projet sans doc pour moi, c’est même pas la peine d’essayer, ça me gave de lire les sources pour trouver comment ça marche quand je dois être opérationnel rapidement. C’est pour cela que je n’ai jamais accroché à Twisted, y a fallu attendre 10 ans avant d’avoir de la doc…
Les sources c’est bien de les lire mais pas comme objectif documentaire…Alors j’ai laissé API-HOUR et je repars sur un bon vieux Flask ;) qui lui a une doc magnifique ! De toute manière l’async c’est vraiment pour des besoins particulier…le MVC a encore de beaux jours devant lui !
” NoSQL, la programmation asynchrone, la programmation fonctionnelle et les projets JS, Node en tête, ont été sur toutes les chaînes ”
Autant je suis assez d’accord avec la critique des annonces type “téléachat”, et les exemples de l’article sont bons, autant NoSQL, les programmations asynchrone et fonctionnelle, le JS & co sont un véritable changement de paradigme, comparable au passage du Flash à l’HTML5.
L’HTML5 a été annoncé bien avant qu’il ne soit tout à fait prêt, et la transition depuis FLASH a pris beaucoup de temps pour de nombreuses compagnies. Aujourd’hui, 7-8 ans plus tard, le HTML5 est prêt pour une utilisation de masse, et le flash est sur le point de mourir. Il y a encore de nombreux codeurs flash très compétents, de nombreuses compagnies continuent à l’utiliser, mais FLASH est voué à disparaître.
Il en ira de même pour les solutions LAMP (PHP, Python, Perl, et même Ruby…), le MVC, et la prog objet. D’ici moins d’une dizaine d’années, le développement web sera à bas de solution JS, de prog fonctionnelle/asynchrone, de NOSql & co, de WebElements, etc. etc.
Ce n’est pas encore tout à fait prêt, mais ça ne va pas tarder. De la même manière que le HTML5 dès 2007 était sûr de remporter la bataille contre Flash, JavaScript va remporter la bataille contre les langages de scripts inspirés de la lignée BASIC / C.
Ce n’est jamais que la revanche des langages de type LISP sur les langages de type BASIC… 30 ans après. Pour rappel, le BASIC (source des C, Java, PHP, Python, Ruby, etc.) n’avait remporté la victoire contre LISP uniquement que pour des raisons de coût de la mémoire dans les années 80. Les ordinateurs permettant de faire tourner LISP étaient alors plus cher que ceux permettant de faire tourner BASIC. Ce sont les affreux GOTO et GOSUB et tous les problèmes qu’ils engendraient qui ont petit à petit amené à la programmation objet telle qu’on la connait. La programmation fonctionnelle, la récurrence, les fonctions anonymes, et autres avaient immédiatement les mêmes avantages que la programmation objet : et le paradigme objet n’a servi qu’à corriger un problème engendrer par la programmation impérative. Il en va de même avec les SGBDR: Une bonne récurrence sur une liste vaut tous les schémas de conception du monde.
Bref, il ne s’agit pas d’une arnaque type téléachat. Il s’agit de la correction d’un bug de conception des langages de programmation, un bug vieux de 30 ans. BASIC n’aurait jamais du l’emporter, la programmation impérative puis objet n’aurait jamais du l’emporter sur la programmation fonctionnelle. Dans le cadre du développement d’applications en ligne, réparties dans des clouds, avec des vues complexes dépendantes de l’utilisateur finale, et des millions d’utilisateurs finaux : les bugs de conception des langages impératifs sont simplement devenus insoutenables, trop complexes, trop peu fiables. La programmation fonctionnelle, ses langages, et ses outils, reprennent donc naturellement le lead. C’est un changement radicale, pas une “barre de fer”.
Relis ce que je dis. Je ne dis pas que ces technos ne sont pas utiles, je dis qu’elles sont vendues comme des solutions miracles sans défaut alors qu’elles en ont (en toute logique) des gros.
Et croire que la programmation fonctionnelle est la seule manière de faire qui va l’emporter c’est exactement ça : ignorer les nombreux défauts de la programmation fonctionnelle. Il n’existe aucune techno parfaite, c’est pour ça qu’il y en a de nombreuses.
Je suis complètement d’accord avec toi,
D’autant plus que par rapport à Autobahn et Crossbar, ça rend l’usage de la lib assez douleureuse de temps à autres, encore hier, je devais me retaper le code source interne d’Autobahn pour essayer d’interfacer Crossbar et Trial pour faire des tests d’intégration asynchrone…
Résultat, j’ai toujours pas une foutue idée de comment je vais faire :D. Bon, après je m’attends pas à ce que l’IRC réponde très vite.
Mais j’aimerais que Tavendo (donc Crossbar / Autobahn) avancent un chuia plus vite sur les choses importantes comme la documentation, et il y a énormément d’issues qui tardent d’être répondues, comme le fait que Crossbar ne marche plus sur le Rasberry Pi 1. Heureusement que pour le debugging, on a manhole :D.
@Louis
“Il en ira de même pour les solutions LAMP (PHP, Python, Perl, et même Ruby…), le MVC, et la prog objet. D’ici moins d’une dizaine d’années, le développement web sera à bas de solution JS, de prog fonctionnelle/asynchrone, de NOSql & co, de WebElements, etc. etc.”
Tu reves des genoux, derrière tout cela y de la méthodologie, de l’analyse, des process…
Ton Javascript, à part les startups, dans le vrai monde informatique, on le voit pas…le développement web représente une petite partie du développement. Essaye de vendre ton JS chez Arcelor ou Total, tu verras comment ils vont t’accueillir…derrière le code, il y a de la qualité, de l’évaluation de coût…c’est un peu fatiguant les commentaires des jeunes de 20 ans qui découvrent JS et qui pensent que ça va tout révolutionner…on sent surtout le manque de culture informatique et d’expérience. Nous aussi avec les server side include et l’asp on croyait qu’on allait devenir riches … ;) et je te racontes pas le jour où ils ont sorti les CSS ;)
Le nosql, c’est normal qu’il apporte de la perf, ce sont des couples clés/valeur…Essaye de dév une appli de gestion en nosql…tu vas finir par devoir faire des jointures dans ton code et c’est justement ce qu’on veut éviter. On voit déjà quelques projets nosql qui repartent pour de la normalisation car le modèle montre ses limites…Le nosql n’est valable que pour du dev genre boutique en ligne…Dans la vraie vie, sur de vrais projets, on utilise des procédures stockées et des triggers et pas un sale mélange de contrôleurs et de données. Tes moteurs nosql généralement ne gèrent pas les accès, la sécurité…tu crois qu’en entreprise on autorise ce genre de techno où il suffit d’ouvrir un port et que tout le monde tape dans la base ? Tu migres comment du relationnel vers un modèle plat ? Et bien tu ponds du code métier, des usines à gaz de conversion.
L’asynchrone c’est une horreur à debugger, la notion de future empêche toute anticipation avec ce qui va derrière comme la maîtrise du temps et des coûts. Le JS c’est pareil, va debugger 100 000 lignes de JS avec des callbacks partout…c’est cela la réalité…pas de la branlette de startup. A chaque intervention Louis, tu énonces des certitudes mais tu nous montres à chaque fois que tu es jeunes et sans trop d’expéreince, je suis désolé mais tu es à côté de la plaque…Tu fournis comment ton “UML” pour l’asynchrone JS a ton équipe de dev ? T’as une méthodo associée ?
“Il s’agit de la correction d’un bug de conception des langages de programmation, un bug vieux de 30 ans.”
Mais bien sûr…tu diras ça aux progs en cobol qui font tourner des appli depuis 30 ans…Tu penses qu’on reparlera de angular et de meteor dans 30 ans, je pense que non ;)…Attention Louis dit que ADA, C, C++, Cobol, Pascal sont des langages buggés…Tu es ridicule Louis.
“BASIC n’aurait jamais du l’emporter, la programmation impérative puis objet n’aurait jamais du l’emporter sur la programmation fonctionnelle.”
Tu connais vraiment rien…BASIc n’a rien emporté du tout, d’ailleurs à mon avis tu n’étais même pas né pour en parler…la prog fonctionnelle convient bien aux matheux mais pas à tous les problèmes de développement.
“Dans le cadre du développement d’applications en ligne, réparties dans des clouds, avec des vues complexes dépendantes de l’utilisateur finale, et des millions d’utilisateurs finaux : les bugs de conception des langages impératifs sont simplement devenus insoutenables,”
Pathétique, tu te ridiculises. Tu devrais écrire des articles pour numerama plutôt ;)
@Louis
“Il en va de même avec les SGBDR: Une bonne récurrence sur une liste vaut tous les schémas de conception du monde.”
Je crois que c’est la pire connerie que j’ai pu lire. On voit surtout que tu connais rien…T’as jamais du faire du MERISE de ta vie, ni touché une base Oracle, ni avoir entendu le terme ACID…j’ai un client en VPC, je vais lui sortir ta phrase, je sens qu’on va bien rire ;), Louis, t’es qu’un gros noob et pis c’est tout, faut l’assumer mais vient pas jouer le cake ici…même si on a un ton décontracté et une orhographe pourrie, t’inquiète la majorité des gus ici ont un très bon niveau de conception et de culture informatique…ne prends pas ce site pour un repère de noob genre le site pour les nuls…non seulement tu te tapes la honte mais en plus tu dis des conneries à d’autres débutants qui s’ils t’écoutaient prendraient un sacré mauvais départ !
@SAM
Je suis tout à fait d’accord sur la critique des bibliothèques prétendues miraculeuses, et l’exemple choisi est bon.
Mais cela n’a rien à voir avec l’évolution vers le fonctionnel, le JS, le NoSQL et tutti quanti.
@fuckinfernand
On est d’accord, ces technologies ne sont pas prêtes aujourd’hui, de la même manière que le HTML5 n’était pas prêt il y a 7 ans.
Les programmeurs FLASH, jadis, disaient des trucs du genre :
“Ton HTML5, à part les startups, dans le vrai monde informatique, on le voit pas…”
Pour info, le vrai monde informatique, c’est de plus en plus le monde des applications Web, et le cloud. Les admin réseaux ont de plus en plus de mal à trouver du boulot, car les entreprises externalisent de plus en plus leurs infrastructures vers du Cloud et des applis en SAS. NoSQL est déjà utilisé par toutes les plus grosses applications en ligne, type FaceBook, Twitter, Google & co. Donc la notion même de “vrai informatique” est franchement critiquable. D’autant plus que de plus en plus de chipset sont programmables en JavaScript.
Bref… J’étais né à l’époque du BASIC et du Logo, et je suis très content que mon cerveau ait été formé à la récurrence et aux langages fonctionnelles AVANT d’apprendre les langages impératifs. Ça devrait être la norme. Oui, les langages type ADA, C, C++, C#, Cobol, Pascal, Java, Php, Ruby, Python forment une seule et unique grande famille : la famille des langages impératifs. Ils sont tous tributaires d’un vice de conception : la logique GOTO et GOSUB, dont la POO n’est qu’un très lointain correctif.
Au passage, si vous voulez voir encore plus loin dans l’avenir, surtout du côté de la “grosse” informatique qui a besoin de test, de certification, de truc bien solide, allez voir du côté de la programmation certifiée. On ne “test” pas un programme certifié, on démontre au sens mathématique qu’il ne buguera jamais (Les français aujourd’hui sont leader dans le domaine ):
https://tel.archives-ouvertes.fr/tel-00150912
Bref, oui, il faut se méfier des librairies miracles façon téléachat.
Non, il ne faut pas croire que les paradigmes actuels sont éternels.
PS : je ne suis pas un dev javascript, tout au plus, j’utilise jQuery.
“Les admin réseaux ont de plus en plus de mal à trouver du boulot, car les entreprises externalisent de plus en plus leurs infrastructures vers du Cloud et des applis en SAS”
Et les admins SAS et Cloud ils viennent d’où ? ;)
Allez, j’arrête de me fatiguer, nous ne tomberons pas d’accord…
@Louis
“NoSQL est déjà utilisé par toutes les plus grosses applications en ligne, type FaceBook, Twitter, Google & co.”
Oui ils l’utilisent pour le front-end…tu crois qu’il y a quoi derrière ?
“logique GOTO et GOSUB, dont la POO n’est qu’un très lointain correctif”
Tu confonds indirection et conception…
Ne soyons pas agressifs non plus. Ces technos sont formidables, et l’évolution du Web passera par elles.
Mais les programmeurs web ont cette tendance à croire que parce que le Web est en effet la révolution de notre génération, c’est la seule forme de developpement qui compte. Ils en oublient la recherche scientifique, les finances, la logistique, la robotique, l’automatisation industrielle, l’embarqué, le réseau, l’admin sys, la prog système, les logiciels desktops, le scripting de logiciels desktops, le code glue, l’analyse du langage naturel, les bots, les virus, les logiciels de sécurisation et bien entendu les systèmes métiers…
Il y a encore des milliards de ligne de cobol, ada, assembleur, basic et fortran en production, mais également tout un tas de langages proprios dont personnes n’a entendu parlé (SAP, solidwork, maya…) , alors le temps que PHP, Java, C#, Perl et bash soient remplacés, on est pas sur une timeline de 5 ans. Pas du tout.
Aucun paradigme n’est éternel, et ces technos disparaîtrons. Mais pas par annihilation, par fusion avec les solutions innovantes qui seront des hybrides de ce qui existait avec ce qu’on apporte de nouveau.
Il ne faut pas pour autant avoir peur d’être rendu obsolète. Notre métier, c’est de s’adapter.
En attendant, le télé achat continue. Croire que le cloud élimine le sysadmin est extrêmement dangereux. Le métier de “devops” est actuellement une catastrophe, et on se retrouve avec des systèmes pleins de failles, non audités, et essentiellement composés de boites noires. L’exemple parfait est l’utilisation de docker comme forme de packaging. Docker est un outil fantastique, mais intégrer un blog binaire opaque de 100Mo dans sa stack, c’est le tapis rouge déballé à tous les attaqueurs.
L’agressivité n’est pas nécessaire, je n’ai pas été agressif, mais ça ne me dérange pas que fuckingfernand le soit. Après tout, c’est la culture des boards depuis des décennies, et si les gens ne s’engueulaient que pour des problèmes aussi abstraits que l’architecture logiciel, le monde serait meilleur ^^
C’est vrai qu’il n’y pas que les applis web. Mais globalement, les technos web sont appelées à remplacer la majorité des applis desktop. Même des applis comme PowerPoint utilisent désormais du balisage et du CSS, et les macros visualBasic gagneraient énormément à être remplacées par du JS.
Enfin, un ptit doc qui va dans ton sens Sam, plutôt que dans le mien :
http://cs.brown.edu/~sk/Publications/Papers/Published/sk-teach-pl-post-linnaean/paper.pdf
L’auteur y défend entre autres choses l’idée que les étudiants en programmation devraient apprendre à créer leur propre mini-langage de programmation de manière à comprendre véritablement les enjeux.
Quoi qu’il en soit, l’évolution vers le JS, NoSQL et le fonctionnel ne fait pas partie de la dérive téléachat, mais est une tendance de fond très forte dans le développement web.
Oui, ce ne sont pas ces technos qui provoquent le téléachat, ce que je dis c’est que le téléachat est très fait pour ces techos. Ceci est indépendant de leurs qualités réelles.
docker, la boite FR qui vaut 1 milliard grâce à la commande linux chroot.
C’est moi l’agressif… ;) j’aime bien et surtout je n’ai aucun compte à rendre ;)
“Après tout, c’est la culture des boards depuis des décennies”
Finalement je t’aime bien, t’es un pur…comme j’aime ! ;)
T’en fais pas je suis toujours agressif, même en vrai, c’est mon style ;), rien de personnel !, j’accepte la critique et le même ton à mon égard…
Moi j’en fout j’code en forth. La notion polonaise inversée il y a que ça de vrai ….
Et comme c’est Trolldi ici, juste une phrase : “Le meuilleur langage c’est celui que tu maitrises le plus”.
Et javascript est et restera une merde infame tant qu’il sera utilisé pour faire tout ce qu’il ne peut pas faire. C’est comme coder du web asynchrone en assembleur 68k : tu y arriveras, mais tu vas en chier.
@Louis : Quoi qu’il en soit, l’évolution vers le JS, NoSQL et le fonctionnel ne fait pas partie de la dérive téléachat, mais est une tendance de fond très forte dans le développement web. => Il vaut mieux avoir tord avec tout le monde qu’avoir raison seul. Google te dis que Js ca roxe parcequ’ils ont pondu un V8 … t’es pas obligé de les croire.
Sans vouloir nourrir le troll sur JS&co, cette vidéo est géniale
La démo dispo ici :
http://anvaka.github.io/pm/#/
Fuckingfernand gagnant par KO. Très beau combat. Les arguments de Louis étaient interessants aussi.
On devrait lancer des genre de battle de rap hardcore, mais ou on clash les technos utilisées par les autres devs.
Woah, Khertan ??? Le flash-back…
Le premier “Maemo Summit” à Berlin, en 2008, ça nous rajeunit pas :-)
Yo les p’tits loups,
Désolé de vous avoir laissé en plan, j’ai été fort occupé cette semaine, la vie est une question de priorité ;-)
Allez, sortez le popcorn, que le spectacle commence ! :-)
@doubledoigt: la documentation existe : http://pythonhosted.org/api_hour/
Si tu as spotté un trou, je suis preneur.
Tu sais, il ne suffit pas d’avoir raison, il faut surtout avoir raison longtemps.
Wait & see, mais sincèrement, je ne comprends pas l’intérêt de mettre autant d’émotionel pour des bêtes outils de travail.
Je crois que ça ferait du bien à pas mal de monde de changer de framework Web et de langage de temps en temps, histoire de prendre du recul et de désacraliser son propre framework fétiche. Pour ma part, je dois mon 5 ou 6ième langage de programmation que j’ai commencé, et n+1 framework Web, ça permet de relativiser son attachement à un outil, quelque soit la quantité d’argent qu’il peut te faire gagner.
Tant qu’aller au fond des choses, autant le faire bien: À l’origine, si j’ai été provoc’ à propos des benchmarks API-Hour, c’est que malgré ce que j’observais avec wrk et les valeurs de prod’, je n’y croyais pas moi-même, je pensais m’être merdé quelque part.
Or vu la demi tonne de benchmarks sur le net, je savais bien que personne prendrait la peine de faire l’effort d’essayer de trouver des erreurs dans mes benchmarks.
Quel est le meilleur moyen de motiver les gens ? Montrer explicitement que tu as la + grosse: Le côté très bénéfique, c’est que ça m’a permis de recevoir tout un tas de feedbacks pertinents et des corrections de configs: Ça n’a pas changé les valeurs du tout au tout, il y a eu néanmoins quelques itérations.
Ce que je n’avais pas prévu, c’est de recevoir ce torrent de haine, néanmoins, au combien intéressant sur la réelle nature humaine et les conflits d’intérêts de gourous qui se prétendent des experts dans leur entreprise ;-)
Quel était mon véritable but avec les benchs ? Arriver à me faire une idée claire de la lenteur réelle de Python par rapport à MES besoins et développer tout un tas de stratégies quand j’ai réellement un bottleneck en prod’. Pour ton info, mon coeur de métier c’est la telco, pas Python ni encore moins HTTP, ce qui facilite fort la prise de recul par rapport à ces benchmarks HTTP ;-)
Ce qui a de la valeur c’est la business logic, ce que Python permet d’écrire très rapidement.
Mes clients s’en foutent ce que j’utilise, ils veulent juste que ça marche bien.
De plus, perso, dans l’inconscient collectif, Python est flaggé comme lent, alors que c’est un des langages où il y a le + d’outillage pour by-passer ça.
Pour avoir eu une stack Django puis Flask en prod’ pour des WebServices, ça a au moins le mérite de lister tout ce qui était dans les pieds quand on devait faire un peu + que le site Web classique que font la plupart des Webeux.
Pourquoi j’en parle maintenant ? Depuis février, je crois que maintenant, la plupart des erreurs éventuelles ont été trouvées, de plus d’autres benchmarks non executés par moi ont montré par A+B que je n’étais pas un mythomane. Enfin, au vu de mon faible niveau technique, il est très peu probable que je “trouve” d’autres points intéressants, donc autant dévoiler les cartes maintenant: si ça permet au moins à quelqu’un de se poser des questions sur son propre comportement, tant mieux.
Ça fait un moment que je me suis rendu compte que le monde de l’IT et l’opensource en particulier ont les mêmes repères que le monde de la mode voire de la religion pour certains comportements.
Sans parler du nombre hallucinants d’imposteurs qui viennent imposer des solutions de manière religieuse sans avoir pris la peine de comprendre le besoin du client ni qu’en fait, ils sont en train de mettre des ronds dans des carrés.
Néanmoins, je ne peux pas leur en vouloir, j’ai aussi été comme cela ;-)
Pour conclure, si tu es heureux avec Flask, tant mieux pour toi ;-)
Mais alors, respecte le fait que je peux être différent de toi, avec des besoins différents de toi, et des problèmes de prod peut-être un poil + complexe que ce que tu fais avec ton Flask ? :-)
Si un jour tu viens à Bruxelles, viens faire un coucou, tu pourrais être surpris :-)
Tout ce que je vois, c’est que maintenant, avec API-Hour, dans notre équipe de dev, avec nos problématiques de realtime, de perfs et de devoir mixer plusieurs protocoles dans le même daemon, on va + vite. Et ce n’est pas moi qui dit ça, c’est la compta, le seul vrai patron dans une boîte, ce que certains dans l’open source ont trop tendance à oublier en préférant se masturber intellectuellement sur la dernière techno à la mode et faire de la R&D sur des projets de prod afin de se faire valoir ;-)
Si je semble avoir fait pareil avec AsyncIO, c’était clairement dans un objectif long terme d’obtenir un meilleur ROI sur le dev: Je n’ai pas besoin de ça pour pouvoir me la pêter, être Français est une condition suffisante pour cela ;-)
Pour recentrer sur le sujet, la monade maybe en haskell est bien utile car elle permet d’eviter les exceptions
null pointeret d’ecrire desifa la chaine.Meme si l’interet des monades sans la gestion des types et la syntaxe qui va avec est plutot relatif, cela reste un concept qui merite que l’on s’y interesse meme si on ne fait pas de prog fonctionnelle.
Une autre approche sur les monades Maybe et Error en Python.
Les monades et functors en images.