Posté par lasher .
En réponse au sondage XML est.
Évalué à 2.
Bon, je ne réponds qu'à la fin de ton post, ce qui précède n'étant pas argumenté correctement (analogie pas pertinentes, entre autres).
« Le pifomètre ne s'est pas trompé cette fois-ci, mais malheureusement les tables de hachage, les listes et Lisp ont existé bien avant XML. »
Le rapport avec XML ? Ce sont des structures de données dont tu parles, moi je parle d'un format de stockage, semi-structuré - et donc par définition hiérarchique, auquel la structuration en arbre pour symboliser ladite hiérarchie [des types entre autres] convient bien.
« [...] on a besoin d'au moins 5 languages pour faire des simples pages web (sql, java/python/php/langage métier, html/xml, css, javascript), »
Voyons un peu. HTML/XML sont là pour le contenu, CSS/XSL pour le rendu (et n'oublions pas que XSLT et XQuery vont quand même plus loin que ça, et permettent de générer tout un tas d'autres sorties), JavaScript pour le côté dynamique côté client, et SQL pour les bases de données.
Je ne dis pas que c'est génial, mais j'aimerais que tu m'expliques comment tu comptes simplifier le tout. Le langage généraliste qui fait tout est à exclure, car alors ce serait une usine à gaz monstrueuse (il n'y a qu'à voir les JSP au début - et même maintenant c'est pas joli à voir, malgré les simplifications et le rajout des tags). Il se trouve qu'une base de donnée n'est pas uniquement utilisée par des applications orientées Web, il leur faut donc un langage standardisé pour pouvoir être utilisées (tiens, ce serait assez drôle d'ailleurs de faire remarquer que chaque SGBD/R n'implémente pas tout des normes SQL...).
D'ailleurs, des solutions comme Hibernate pour Java sont plutôt intéressantes, car justement on peut éviter un maximum le côté SQL des SGBD et passer par la correspondance Relationnel/Modèle Objet.
Donc pour faire bref :
1/ À moins de faire une base de données spécialisée Web, les langages de type SQL/XQuery vont rester un bout de temps (et même en ayant une on duplique inutilement les efforts, du coup)
2/ Le langage spécialisé est obligatoire pour faire l'interfaçage front-end/back-end (ou alors tu réussis je ne sais comment à tout faire passer en XML/HTML/XSLT, beurk)
3/ Il te faut bien un moyen de décrire le contenu et le mettre en forme (HTML,XML/CSS,XSL)
4/ Le seul truc éventuellement serait de réussir à fusionner HTML et JS, car effectivement, au final, tout se fait côté client (d'un autre côté, on peut utiliser Javascript à part, et mélanger la description des données avec leur traitement dynamique, bof...)
L'incapacité à faire rapide/peu gourmand/etc vient du fait que le développement spécifique à une plate-forme coûte cher en temps et en expertise, d'autant plus qu'on parle d'outils de haut niveau, extrêmement complexes. Le problème c'est qu'une bonne conception nécessite de bien séparer les modules, et du coup on perd au moins le temps de communiquer entre ceux-ci.
Je te rejoins sur le côté debogage : on est encore à la préhistoire de ce qui pourrait s'envisager, quelle que soit la plate-forme envisagée (et pas seulement pour du Web, même si c'est là que ça pêche le plus).
[^] # Re: une immondice infame
Posté par lasher . En réponse au sondage XML est. Évalué à 2.
« Le pifomètre ne s'est pas trompé cette fois-ci, mais malheureusement les tables de hachage, les listes et Lisp ont existé bien avant XML. »
Le rapport avec XML ? Ce sont des structures de données dont tu parles, moi je parle d'un format de stockage, semi-structuré - et donc par définition hiérarchique, auquel la structuration en arbre pour symboliser ladite hiérarchie [des types entre autres] convient bien.
« [...] on a besoin d'au moins 5 languages pour faire des simples pages web (sql, java/python/php/langage métier, html/xml, css, javascript), »
Voyons un peu. HTML/XML sont là pour le contenu, CSS/XSL pour le rendu (et n'oublions pas que XSLT et XQuery vont quand même plus loin que ça, et permettent de générer tout un tas d'autres sorties), JavaScript pour le côté dynamique côté client, et SQL pour les bases de données.
Je ne dis pas que c'est génial, mais j'aimerais que tu m'expliques comment tu comptes simplifier le tout. Le langage généraliste qui fait tout est à exclure, car alors ce serait une usine à gaz monstrueuse (il n'y a qu'à voir les JSP au début - et même maintenant c'est pas joli à voir, malgré les simplifications et le rajout des tags). Il se trouve qu'une base de donnée n'est pas uniquement utilisée par des applications orientées Web, il leur faut donc un langage standardisé pour pouvoir être utilisées (tiens, ce serait assez drôle d'ailleurs de faire remarquer que chaque SGBD/R n'implémente pas tout des normes SQL...).
D'ailleurs, des solutions comme Hibernate pour Java sont plutôt intéressantes, car justement on peut éviter un maximum le côté SQL des SGBD et passer par la correspondance Relationnel/Modèle Objet.
Donc pour faire bref :
1/ À moins de faire une base de données spécialisée Web, les langages de type SQL/XQuery vont rester un bout de temps (et même en ayant une on duplique inutilement les efforts, du coup)
2/ Le langage spécialisé est obligatoire pour faire l'interfaçage front-end/back-end (ou alors tu réussis je ne sais comment à tout faire passer en XML/HTML/XSLT, beurk)
3/ Il te faut bien un moyen de décrire le contenu et le mettre en forme (HTML,XML/CSS,XSL)
4/ Le seul truc éventuellement serait de réussir à fusionner HTML et JS, car effectivement, au final, tout se fait côté client (d'un autre côté, on peut utiliser Javascript à part, et mélanger la description des données avec leur traitement dynamique, bof...)
L'incapacité à faire rapide/peu gourmand/etc vient du fait que le développement spécifique à une plate-forme coûte cher en temps et en expertise, d'autant plus qu'on parle d'outils de haut niveau, extrêmement complexes. Le problème c'est qu'une bonne conception nécessite de bien séparer les modules, et du coup on perd au moins le temps de communiquer entre ceux-ci.
Je te rejoins sur le côté debogage : on est encore à la préhistoire de ce qui pourrait s'envisager, quelle que soit la plate-forme envisagée (et pas seulement pour du Web, même si c'est là que ça pêche le plus).