Onanisme informatique et Esotérie de nerds

[Hayek's plosive]

Et c'est quoi le rapport avec l'expatriation estudiantine? Vous pouvez pas aller faire vos cochoncetés sur le fil des geeks a qui jeter des cailloux?

[Mathieu_D]

Et c'est quoi le rapport avec l'expatriation estudiantine? Vous pouvez pas aller faire vos cochoncetés sur le fil des geeks a qui jeter des cailloux?

Tes certifications de compta ça avance ?

[L'affreux]

Et c'est quoi le rapport avec l'expatriation estudiantine? Vous pouvez pas aller faire vos cochoncetés sur le fil des geeks a qui jeter des cailloux?

Déjà répondu.

[POE]

Sinon, RotundWeiss, il s'est expatrié où puisque c'est le sujet du fil.

[Rincevent]

En Cybérie, je crois.

[Poil à gratter]

React : Lis la page précédente de ce fil de discussion. Je n'aime pas du tout le concept de DOM virtuel. Mais Poil à gratter aime bien, un jour il nous dira pourquoi.

Oui, je n'avais pas oublié  

 

 

J'ai recherché encore mais je n'arrive décidément pas à mettre la main sur le blog qui détaille des points techniques à propos du vDom. En résumé, le vDom c'est un peu l'équivalent dans le monde JavaScript du code managé qu'on connaît déjà bien dans le monde Java . Ça rajoute une étape intermédiaire de transcription, et intuitivement ça paraît lourd et plus lent, mais en fait c'est tout le contraire: c'est plus rapide et ça ne pourra que devenir plus rapide dans le futur. C'est assez contre intuitif, et beaucoup de développeurs, même chevronnés, ont du mal à réaliser ceci. Par exemple ils vont considérer qu'utiliser Hibernate est plus lent que faire du SQL "à la main", alors que pour la majorité des projets (qui sont souvent des CRUDs) utiliser Hibernate offre de meilleurs performances malgré toutes les couches que ça ajoute.

 

C'est l'éternel débat "natif vs managé", et en tant que développeur Java je ne peux que penser que ce débat est plié depuis des années. On a une implémentation native du DOM - en C++ pour ce que j'en sais - dans les navigateurs, et une implémentation managée en JavaScript. Je fais le pari dès aujourd'hui que la version managée va exploser les versions natives d'ici peu. 

 

Le vDom a aussi ceci de particulier que c'est une implémentation légère du DOM: React n'émule pas tous les attributs qu'on peut trouver sur un élément, mais seulement ceux qui sont utilisés. Et ça fait déjà une différence énorme: la spécification du DOM est un monstre, avec une tétrachiée d'attributs que les moteurs des navigateurs doivent implémenter. Reac peut s'affranchir de cet héritage douteux.

 

TL;DR: IMO React à gagné et est en train d'enfoncer les autres frameworks à plates coutures, à tel point que ce sont désormais les autres frameworks qui intègrent le vDOM ou Flux. Flipboard, Hipchat, et d'autres que j'oublie sont passés sur React: j'attends toujours des vraies applications critiques écrites avec Angular... (qui est à mon avis le grand perdant dans l'histoire)

[Poil à gratter]

Coup de théâtre dans le développement front-end : l'équipe de TypeScript annonce que Angular 2 sera construit sur TypeScript. AtScript serait devenu TypeScript.

Très bonne nouvelle: l'équipe Angular avait annoncé qu'ils allaient coopérer avec l'équipe Typescript pour faire converger AtScript et TypeScript, et honnêtement je n'y croyais pas du tout. Je voyais mal Google et Microsoft coopérer. En plus AtScript ça me semblait un peu genre: on aimerait bien utiliser TypeScript, mais on ne peut pas parce qu'on est Google, alors on va faire un truc qui ressemble à TypeScript.

 

Au final on va récupérer un truc positif du couac Angular 2.0: TypeScript 1.5 aura des annotations.

[Rincevent]

Par exemple ils vont considérer qu'utiliser Hibernate est plus lent que faire du SQL "à la main", alors que pour la majorité des projets (qui sont souvent des CRUDs) utiliser Hibernate offre de meilleurs performances malgré toutes les couches que ça ajoute.

Bah, ça a peu à voir avec le CRUD au final : ça a souvent bien plus de rapports avec une base structurée avec les pieds, une indexation sous-médiocre, des "hints" absurdes donnés à l'optimiseur... Bref, le SQL c'est une affaire sérieuse, et les couches intermédiaires comme Hibernate permettent de limiter les conneries de ceux qui ne s'y connaissent pas (ou plutôt de ceux qui croient s'y connaître).

[Poil à gratter]

Bah, ça a peu à voir avec le CRUD au final : ça a souvent bien plus de rapports avec une base structurée avec les pieds, une indexation sous-médiocre, des "hints" absurdes donnés à l'optimiseur... Bref, le SQL c'est une affaire sérieuse, et les couches intermédiaires comme Hibernate permettent de limiter les conneries de ceux qui ne s'y connaissent pas (ou plutôt de ceux qui croient s'y connaître).

C'est vrai, pas grand chose à voir. En fait j'ai essayé de faire "court", et ce que j'ai écrit n'est pas très clair à la relecture. Mais c'est amusant que tu dises ça car j'ai eu la même discussion aujourd'hui à propos de la programmation multi-thread en Java. Mon avis étant que c'est un domaine d'expert à ne pas mettre entre toutes les mains, et que je préfère largement utiliser un framework plutôt que de faire semblant de maîtriser la chose (et me bananer lamentablement).

 

Je parle d'Hibernate parce que Emmanuel Bernard en avait parlé dans un Podcast "Les cast-codeurs" où ils évoquaient le sujet: il avait comparé la façon de fonctionner du vDOM avec celle d'Hibernate. En fait, tout comme le vDOM, Hibernate utilise un modèle temporaire qui enregistre toutes les modifications (en gros un vSQL) faites au graphe d'objets avant d'envoyer des requêtes SQL. Cela permet des optimisations comme par exemple de ne pas exécuter du tout de requêtes SQL si après plusieurs opérations le modèle est finalement identique. Il y a aussi évidemment les excellent caches d'entité et de niveau 2 qui aident un petit peu Alors par contre je ne vois pas en quoi Hibernate protège des conneries au niveau de la DB elle même, ou alors c'est juste que tu veux tenir les devs Java éloignés grâce à des couches 

 

Or ce ce genre d'optimisations sont impossibles à détecter localement, il faut un superviseur pour gérer les états. Et ce n'est évidemment pas réaliste d'écrire quelque chose d'aussi sophistiqué pour chaque projet. C'est là qu'entre en jeu un framework comme React et son vDOM. Bon évidemment je ne pense pas que React est parfait, et il a encore plein de défauts (par exemple JSX), mais c'est un grand pas en avant, il me semble.

[Johnnieboy]

Mon dieu, mon dieu.

[poney]

tc;dr

[Poil à gratter]

Ah, ces littéraires

[ShoTo]

Je suis un geek de la pire espèce et pourtant je trouve moi aussi cette discussion chiante comme la mort, c'est normal ?

[Cthulhu]

Bof, c'est de la BDD, faut nager dedans quoi. Je n'ai jamais bien compris cette croyance populaire que les gens qui s'y touchaient en info étaient quasiment interchangeables. Alors qu'entre un dev web, un admin sys et un hacker kernel, il y a quand même un monde d'écart.

[L'affreux]

Je suis un geek de la pire espèce et pourtant je trouve moi aussi cette discussion chiante comme la mort, c'est normal ?

Pour ma part je ne suis pas vraiment geek et la discussion m'intéresse. Comme quoi…

 

Bah, ça a peu à voir avec le CRUD au final : ça a souvent bien plus de rapports avec une base structurée avec les pieds, une indexation sous-médiocre, des "hints" absurdes donnés à l'optimiseur... Bref, le SQL c'est une affaire sérieuse, et les couches intermédiaires comme Hibernate permettent de limiter les conneries de ceux qui ne s'y connaissent pas (ou plutôt de ceux qui croient s'y connaître).

Non. Le SQL est une affaire sérieuse, et qui devrait donc est prise au sérieux par les développeurs. J'avais écrit un article finement intitulé : Les ORM c'est mal.

Même chose pour le Virtual DOM, sauf que je ne suis pas encore tombé sur un projet où il m'est imposé donc je n'ai pas encore écrit un texte à charge pour me décharger.

[Malky]

ou alors c'est juste que tu veux tenir les devs Java éloignés grâce à des couches

En fait il préférerait mettre des couches aux devs java qui s’approchent de sql. C’est juste pour éviter qu’ils n’en mettent partout.

[L'affreux]

Mais c'est amusant que tu dises ça car j'ai eu la même discussion aujourd'hui à propos de la programmation multi-thread en Java. Mon avis étant que c'est un domaine d'expert à ne pas mettre entre toutes les mains, et que je préfère largement utiliser un framework plutôt que de faire semblant de maîtriser la chose (et me bananer lamentablement).

C'est pas faux. J'aime beaucoup le modèle asynchrone de JavaScript. Des tâches simultanées sur un seul thread. Plus facile et moins de bugs indétectables.

 

C'est l'éternel débat "natif vs managé", et en tant que développeur Java je ne peux que penser que ce débat est plié depuis des années. On a une implémentation native du DOM - en C++ pour ce que j'en sais - dans les navigateurs, et une implémentation managée en JavaScript. Je fais le pari dès aujourd'hui que la version managée va exploser les versions natives d'ici peu.

Personnellement je trouve le DOM virtuel mal nommé. Le vrai DOM est déjà virtuel, c'est une arborescence standardisée d'objets manipulables en JavaScript.

Je ne suis pas convaincu qu'on puisse faire le parallèle avec du code managé comme le bytecode en Java versus le code machine. Les ORM et le virtual DOM, c'est d'un autre ordre. Ne serait-ce que sur l'élégance. Le bytecode pourrait (presque?) servir de jeu d'instructions à un processeur. Les ORM font carrément l'impasse sur la véritable nature du stockage relationnel, pour présenter une façade obéissant aux logiques de la POO. Idem pour le virtual DOM : il s'agit de plier le DOM à la gestion de la vue. JSX n'est pas une erreur (enfin si mais…), c'est une fonctionnalité cohérente avec l'approche du virtual DOM.

TL;DR: IMO React à gagné et est en train d'enfoncer les autres frameworks à plates coutures, à tel point que ce sont désormais les autres frameworks qui intègrent le vDOM ou Flux. Flipboard, Hipchat, et d'autres que j'oublie sont passés sur React: j'attends toujours des vraies applications critiques écrites avec Angular... (qui est à mon avis le grand perdant dans l'histoire)

AngularJS est mal foutu, maintenant que ça se voit, React en profite. Mais React aussi est mal foutu. Je ne crois pas du tout à sa généralisation. Il bénéficie d'une réaction à l'encontre de Angular.

Et puis, bon, Facebook hein. Sous Firefox/Linux, les pages Facebook pompent 25% du CPU. J'avais constaté ce changement justement au moment où Facebook publiait React.

[Rincevent]

Non. Le SQL est une affaire sérieuse, et qui devrait donc est prise au sérieux par les développeurs. J'avais écrit un article finement intitulé : Les ORM c'est mal.

Copaing !

[Rincevent]

En fait il préférerait mettre des couches aux devs java qui s’approchent de sql. C’est juste pour éviter qu’ils n’en mettent partout.

Faut dire qu'il y en a certains qui le mériteraient. Le Java est, dit-on souvent, le Cobol du 21ème siècle : les deux languages ont leurs qualités et leurs défauts, mais le pire c'est quand même ceux parmi les développeurs qui en font, et qui pensent ne pas avoir besoin de connaître d'autre langage.

[Poil à gratter]

Je suis un geek de la pire espèce et pourtant je trouve moi aussi cette discussion chiante comme la mort, c'est normal ?

On avait déjà évoqué la question dans le sujet des geeks informatique, et la conclusion était que geek != développeur. 

 

Non. Le SQL est une affaire sérieuse, et qui devrait donc est prise au sérieux par les développeurs. J'avais écrit un article finement intitulé : Les ORM c'est mal.

Bon, en même temps un ORM en PHP... Comment est-ce possible d'avoir un layer de cache dans un ORM PHP? Mais de toutes façons je n'ai jamais vu une application qui faisait tous ses accès BDD en utilisant uniquement l'ORM: il y a toujours une part de requêtes écrites à la main pour d'évidentes raisons de performance. Enfin si, j'en ai vu qui faisait tout avec l'ORM, mais ça s'est mal terminé 

 

Ensuite ça fait quand même longtemps que les ORMs sont un peu plus malins et ne chargent pas la totalité d'un graphe d'objets ou même les membres de l'objet avec des stratégies de lazy loading/fetching:

https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/performance.html

 

Je n'ai jamais vraiment trop adhéré cette idée d'impedance mismatch: oui il y a des différences, mais rien d'insurmontable. Les problèmes que j'ai vu venaient plutôt d'un mapping très naïf et d'un manque de couches dans l'application. Il est aussi possible de solutionner beaucoup de problèmes en ayant plusieurs modèles objets dédiés à des usages différents (typiquement écriture vs lecture). Ça se fait depuis des années, et c'est désormais formalisé sous le nom de CQRS.

Bref, ce n'est pas tout noir ou tout blanc. En revanche ce que je sais c'est qu'implémenter de l'optimistic locking ou un cache L2, à la main, sans ORM, ce n'est juste pas possible. Et c'est là qu'un ORM apporte beaucoup et permet de faire monter en charge des applications.

C'est pas faux. J'aime beaucoup le modèle asynchrone de JavaScript. Des tâches simultanées sur un seul thread. Plus facile et moins de bugs indétectables.

 

Personnellement je trouve le DOM virtuel mal nommé. Le vrai DOM est déjà virtuel, c'est une arborescence standardisée d'objets manipulables en JavaScript.

Certes, ce n'est pas très bien nommé. Mais DOM temporaire ça ne serait pas beaucoup mieux.

 

Je ne suis pas convaincu qu'on puisse faire le parallèle avec du code managé comme le bytecode en Java versus le code machine. Les ORM et le virtual DOM, c'est d'un autre ordre. Ne serait-ce que sur l'élégance. Le bytecode pourrait (presque?) servir de jeu d'instructions à un processeur. Les ORM font carrément l'impasse sur la véritable nature du stockage relationnel, pour présenter une façade obéissant aux logiques de la POO. Idem pour le virtual DOM : il s'agit de plier le DOM à la gestion de la vue. JSX n'est pas une erreur (enfin si mais…), c'est une fonctionnalité cohérente avec l'approche du virtual DOM.

Ils avaient fait des processeurs Java qui pouvaient exécuter du bytecode directement. donc oui ça peut servir de jeux d'instructions.

 

Je n'aime pas non plus JSX mais pas parce qu'il plie le DOM à la gestion de la vue, juste parce que c'est un langage de template et que de ce fait il est limité. C'est IMO LA grande incohérence dans React: tout peut être fait en JavaScript si on le veut (manipulation DOM, et même CSS), et on bénéficie donc de toute la puissance d'un langage de programmation complet. Seulement c'est un peu lourd à écrire. Alors ils ont cédé à la facilité et créé un énième langage de template avec toutes les limitations qui viennent avec. Entre autre c'est adverse au refactoring (bon, ce n'est pas non plus le point fort de JavaScript...) et ça force à construire des outils ad-hoc dans les IDE pour aider les développeurs.

 

AngularJS est mal foutu, maintenant que ça se voit, React en profite. Mais React aussi est mal foutu. Je ne crois pas du tout à sa généralisation. Il bénéficie d'une réaction à l'encontre de Angular.

Et puis, bon, Facebook hein. Sous Firefox/Linux, les pages Facebook pompent 25% du CPU. J'avais constaté ce changement justement au moment où Facebook publiait React.

Il est mal foutu, mais au moins ça fonctionne déjà sur des sites à fort trafic. Et Facebook utilisait déjà React longtemps avant sa publication, donc avec ou sans React c'est un clairement un site très gourmand en ressources. Il y a aussi une part de réaction (ahah) à l'encontre d'Angular, mais il y a un phénomène intéressant qui est que React pollinise d'autres frameworks avec les idées de vDOM, styling en JavaScript, Flux, etc.  J'ai déjà repéré 3-4 frameworks qui se basent sur vDOM et se disent meilleurs que React. Ember.js commence à incorporer des idées aussi. Donc ça me paraît parti pour durer.

[Poil à gratter]

En fait il préférerait mettre des couches aux devs java qui s’approchent de sql. C’est juste pour éviter qu’ils n’en mettent partout.

Ah, je comprends mieux!

 

Faut dire qu'il y en a certains qui le mériteraient. Le Java est, dit-on souvent, le Cobol du 21ème siècle : les deux languages ont leurs qualités et leurs défauts, mais le pire c'est quand même ceux parmi les développeurs qui en font, et qui pensent ne pas avoir besoin de connaître d'autre langage.

Tout le monde ne fait pas le métier par passion, mais juste à but alimentaire (et c'est parfaitement normal), du coup certains développeurs ne sont effectivement pas très curieux de savoir comment ça marche le machin qui leur envoie le data. Néanmoins, on est bien obligés de se spécialiser, et maîtriser SQL ce n'est juste pas possible pour un développeur généraliste. En plus on oublie très vite quand on ne pratique pas.... J'avais su, mais là si on me demande la différence entre un LEFT OUTER JOIN, un LEFT JOIN et un RIGHT JOIN, je serais bien incapable d'expliquer quoi que ce soit

[Mathieu_D]

Ah, je comprends mieux!

 

Tout le monde ne fait pas le métier par passion, mais juste à but alimentaire (et c'est parfaitement normal), du coup certains développeurs ne sont effectivement pas très curieux de savoir comment ça marche le machin qui leur envoie le data. Néanmoins, on est bien obligés de se spécialiser, et maîtriser SQL ce n'est juste pas possible pour un développeur généraliste. En plus on oublie très vite quand on ne pratique pas.... J'avais su, mais là si on me demande la différence entre un LEFT OUTER JOIN, un LEFT JOIN et un RIGHT JOIN, je serais bien incapable d'expliquer quoi que ce soit

Ben enfin faut pas déconner, n'importe qui apprend le sql standard très vite, faut pas être dba pour faire une requête.

 

(Ne me faites pas dire ce que je n'ai pas dit, il faut bien sûr de l'expertise pour faire des choses sioux et élégantes qui optimisent à fond.)

[Poil à gratter]

Ben enfin faut pas déconner, n'importe qui apprend le sql standard très vite, faut pas être dba pour faire une requête.

Justement, ce genre de requêtes simples plus grand monde n'a besoin de les écrire puisque c'est géré par un ORM ou une couche DAO pour une application un peu plus conséquente. Celles qu'on a besoin d'écrire à la main ce sont justement les requêtes un peu velues.

[L'affreux]

Eh bien on s'est trouvé un gros point de divergence : l'empilage des couches.

Bref, ce n'est pas tout noir ou tout blanc. En revanche ce que je sais c'est qu'implémenter de l'optimistic locking ou un cache L2, à la main, sans ORM, ce n'est juste pas possible. Et c'est là qu'un ORM apporte beaucoup et permet de faire monter en charge des applications.

On peut charger certaines données, notamment celles en lecture seule, dans des tables de hashages, à l'ancienne, ça marche encore.

Mais le SGBD n'est pas forcément mauvais pour les optimisations. Si on ne le sollicite pas de manière stupide, il détermine plutôt bien ce qu'il faut lever en RAM. Le SGBD, en lui-même, est déjà une couche d'accès au données.

J'avais su, mais là si on me demande la différence entre un LEFT OUTER JOIN, un LEFT JOIN et un RIGHT JOIN, je serais bien incapable d'expliquer quoi que ce soit

"OUTER" est un mot-clé optionnel.

J'ai quelque chose qui génère l'essentiel des requêtes en écriture, mais les SELECT, ça m'a toujours paru normal de les écrire à la main.

[Tremendo]

Je nage en pleine imcompréhension

[Sloonz]

On peut charger certaines données, notamment celles en lecture seule, dans des tables de hashages, à l'ancienne, ça marche encore

Non ça ne marche pas.

L’intérêt c’est de cacher les objets entre plusieurs requêtes (typiquement: une fois ton utilisateur authentifié, tu auras toujours à charger ta même ligne dans la table users) et plusieurs sessions (typiquement: tu auras toujours à charger les 3 mêmes ligens de la table headlines). Ça nécessite un serveur d’application, chose que n’a pas simplement et nativement PHP.

J'ai quelque chose qui génère l'essentiel des requêtes en écriture, mais les SELECT, ça m'a toujours paru normal de les écrire à la main.

Tu devrais regarder du côté de idiorm+paris.

[L'affreux]

geek != développeur

… pour la version ORM.

En SQL ça donne : geek <> développeur.

Et en unicode : geek ≠ développeur.

Marche aussi.

[Tremendo]

[L'affreux]

Il est mal foutu, mais au moins ça fonctionne déjà sur des sites à fort trafic. Et Facebook utilisait déjà React longtemps avant sa publication, donc avec ou sans React c'est un clairement un site très gourmand en ressources.

Un programme front-end en JavaScript est en dehors des problématiques de montée en charge. Facebook utilise 25% du CPU pour faire quoi ? Ils sont nuls en performance front-end, il n'y a pas à chercher plus loin.

Non ça ne marche pas.

L’intérêt c’est de cacher les objets entre plusieurs requêtes (typiquement: une fois ton utilisateur authentifié, tu auras toujours à charger ta même ligne dans la table users) et plusieurs sessions (typiquement: tu auras toujours à charger les 3 mêmes ligens de la table headlines). Ça nécessite un serveur d’application, chose que n’a pas simplement et nativement PHP.

"ligens" ??

Quel que soit le langage, on peut lever un RAM les bons éléments. Ça demande en revanche d'y réfléchir au début du projet, alors qu'une couche ORM en plus permet de ne pas s'occuper de la performance et de corriger le tir à la fin. Mais la couche additionnelle apporte aussi des inconvénients, à commencer par la lourdeur au codage comme à l'exécution.

PHP ne reste pas en RAM d'une requête sur l'autre. Ça n'a pas empêché des développeurs PHP de développer Doctrine. J'imagine qu'ils justifient leur travail par d'autres mauvaises raisons que le cache du serveur d'application.

 

Tu devrais regarder du côté de idiorm+paris.

Je ne connaissais pas celui-là mais je ne vois pas l'intérêt d'un mapping objet sur les mot-clés de SQL. Le standard SQL 92 est bien respecté depuis des années, si on fait attention, on peut relativement aisément passer d'un SGBD à l'autre. Cette couche n'apporte rien.

Pour des raisons fonctionnelles, la plupart des INSERT, UPDATE et DELETE sont faits unitairement. C'est pourquoi on peut les générer avec un petit Helper. Il n'y a pas besoin d'aller plus loin.

[Sloonz]

Je ne connaissais pas celui-là mais je ne vois pas l'intérêt d'un mapping objet sur les mot-clés de SQL. Le standard SQL 92 est bien respecté depuis des années, si on fait attention, on peut relativement aisément passer d'un SGBD à l'autre. Cette couche n'apporte rien.

Tu n’as regardé que idiorm et pas paris ; paris illustre bien l’intérêt du modèle idiorm.

L’intérêt c’est de pouvoir construire des requêtes de manière plus subtile (et plus factorisable !) que des bêtes concaténation de string. Ça semble très bête dit comme ça, mais à l’usage c’est extrêmement pratique. Petit exemple de construction bien plus agréables en idiorm qu’en SQL brut :

 

function active_users() {
return ORM::for_table("users")->where_equal("active", 1);
}

$nUsers = active_users()->count(); // SELECT COUNT(*) FROM users WHERE active = 1
$myUser = active_users()->find_one(42); // SELECT * FROM users WHERE id = 42 AND active = 1

Cet exemple est en fonctionnel, mais Paris montre que tu peux de la même manière faire des contructions objet assez intelligentes (et utiles !) sans pour autant trop t’éloigner du SQL.

(bon, et il y a l’avantage que c’est bien plus facile d’être tête en l’air et de faire "WHERE id = $id" au lieu de "WHERE id = ?" et de passer $id en paramètre avec le SQL brut, en idiorm la construction naturelle est aussi la construction la plus secure).