¿Por qué XSLT nunca ha visto la popularidad de muchos otros lenguajes que surgieron durante el boom de Internet?[cerrado]
https://stackoverflow.com/questions/77342
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
El uso de XSLT (XML Stylesheet Language Transform) nunca ha tenido la misma popularidad que muchos de los otros lenguajes que surgieron durante el boom de Internet.Mientras está en uso, y en algunos casos por grandes empresas exitosas (es decir,Blizzard Entertainment), nunca pareció llegar a la corriente principal.¿Por qué crees que es esto?
Solución
Un problema es que XSLT aspecto complicado.Cualquier desarrollador debería poder aprender las construcciones del lenguaje, ya que existen análogos en la mayoría de los demás lenguajes.El problema es que las construcciones y los datos se ven exactamente iguales, lo que dificulta la distinción entre los dos, lo que hace que XSLT sea más difícil de leer que otros lenguajes.
Un segundo problema es que sus usos son más limitados que los de otros idiomas.XSLT es excelente en lo que hace;realizar transformaciones complicadas o radicales en XML.Pero no se aplica a una gama tan amplia de problemas como otros lenguajes, por lo que no se usa tanto.
En tercer lugar, muchos lenguajes de programación tienen sus propias bibliotecas para transformar XML.La mayor parte del tiempo, cuando se trabaja con XML, sólo se necesitan pequeños cambios o búsquedas.Es probable que el XML también esté siendo generado o consumido por un programa que el desarrollador ya está escribiendo en otro idioma.Estos factores significan que usar las utilidades integradas de un lenguaje es simplemente más conveniente.
Otro problema al que contribuyen todas estas cuestiones es la inercia.Es decir, la gente no lo sabe, no ven que lo necesitan mucho, por lo que lo evitan como solución si hay otra opción.
Lo que obtienes al final es un lenguaje que es la última opción de muchos desarrolladores a la hora de crear soluciones.Es probable que incluso se evite XSLT cuando, como resultado, sería la mejor herramienta para el trabajo.
Otros consejos
XSLT utiliza programación funcional, algo a lo que la mayoría de los programadores no están acostumbrados (de ahí que algunas personas lo consideren no intuitivo, supongo).
En mi opinión, una de las cosas más molestas del XSLT estándar (estoy hablando de XSLT 1.0 porque es la única versión que he usado) es que carecía de soporte para transformaciones de cadenas y algunas manipulaciones básicas de funciones de fecha y hora.
Una cosa que nunca pude entender es por qué una función como traducir() fue diseñada e implementada en xpath mientras que otras funciones más útiles como reemplazar, reducir, a_superior, o, seamos locos, las expresiones regulares no lo eran.
Algunas de estas cuestiones se abordaron, supongo, con eXSLT (¿xslt extendido?) para analizadores distintos del MSXML de Microsoft.Digo supongo porque en realidad nunca lo usé porque fue declarado incompatible con MSXML.
No entiendo por qué XSLT 1.0 fue diseñado con este principio de que la manipulación del 'texto' no estaba dentro del alcance del lenguaje cuando es obvio que cada vez que conviertes archivos no puedes evitar esos problemas de conversión de cadenas (por ejemplo,:transformar una fecha irregularmente rellenada dada en formato francés al formato americano, 31/1/2008 a 2008-01-31) eh...
Estos problemas de manipulación de texto eran generalmente muy básicos y se solucionaban fácilmente en MSXML al permitir que XSL se extendiera con funciones JScript:se podía llamar a una función JScript para realizar algún procesamiento tal como se llamaría a cualquier plantilla XSL, pero siempre encontré esa solución poco elegante y terminé creando mis propias bibliotecas de plantillas XSL.Primero porque la forma JScript rompió su portabilidad XSL, y luego porque lo obligó a mezclar su lógica de programación:algunos bits en expresión XPath/XSLT pura y otros bits en notación DOM/objeto con JScript.
No tener variables actualizables es otra limitación que resulta muy confusa para los recién llegados, algunas personas simplemente no superan esto y siguen luchando con ello.En algunos casos simples, puede encontrar soluciones con una combinación de plantillas paremetrizadas y llamadas recursivas (por ejemplo, para implementar un contador creciente o decreciente), pero seamos realistas, la recursividad no es tan natural.
Creo que escuché que todas esas limitaciones se abordaron en la especificación XSLT 2.0, lamentablemente MS decidió no implementarla y promover XQuery en su lugar.Eso es triste, ¿por qué no implementar ambos?Creo que XSLT todavía tendría muchas posibilidades de volverse tan popular como lo fue CSS para HTML.Si lo piensas bien, la parte más difícil de aprender XSLT es XPath, el resto no es tan difícil como comprender el comportamiento en cascada en CSS, y CSS se ha vuelto tan popular...
Entonces, en mi opinión, es la falta de todas esas pequeñas cosas mencionadas aquí y el tiempo que tomó abordarlas en XSLT 2.0 (sin que MS lo admita de todos modos) lo que ha llevado a esta situación de impopularidad.Cómo desearía que MS decidiera implementarlo después de todo...
Porque la mayoría de las implementaciones XSLT ocupan una gran cantidad de memoria (supongo que se debe al diseño del lenguaje), porque la gente tendía a abusar de XSLT para todo tipo de cosas para las que no era particularmente adecuado y la naturaleza puramente declarativa de XSL. lo que dificulta bastante ciertos tipos de transformaciones.
Es excelente para xml, pero no para la codificación típica.Carece de conceptos básicos típicos (es decir, variables mutables) y hace que lo que debería ser simple sea bastante complejo (o imposible).La mayoría de sus problemas surgen del hecho de que xml es un gran lenguaje de representación de datos pero no un gran lenguaje de programación.Dicho esto, lo uso a diario y lo recomendaría cuando tenga sentido.Junto con espacios de nombres externos, puede resultar más útil (llamadas a Java, etc.).Al final, es otro idioma que aprender y muchos programadores preferirían seguir con algo a lo que están acostumbrados o que se parece a algo a lo que están acostumbrados.
Porque es más fácil escribir y mantener código que utilice Java, C#, JavaScript, etc.para deserializar un flujo XML, transformarlo y exportar el resultado deseado, y XSLT no ofrece ninguna ventaja sustancial de rendimiento.
XSLT hace que algunas cosas sean fáciles, pero hace que otras sean muy, muy difíciles.
Bien...Tal vez porque es complicado escribir xslts...Tuve que escribir algunos xslts hace unos meses y estaba soñando con corchetes puntiagudos...
<Really>
<No>
<fun/>
</No>
</Really>
(Lo sé, esto no es xslt)
Generalmente, los momentos en los que se le pedirá que transforme datos XML en una forma diferente de datos XML, pero no realice ningún otro procesamiento, serán muy limitados.Por lo general, XML se utiliza como intermediario entre dos sistemas separados, uno de los cuales suele estar hecho a medida para procesar la salida del otro.Como tal, es más sencillo escribir uno de los sistemas para procesar la salida XML del otro sin el paso adicional de tener que realizar algún tipo de transformación.
XSL es común y ampliamente adoptado.¿A qué otros idiomas te refieres?XSL no es un lenguaje de programación, solo un lenguaje de transformación, por lo que su alcance es bastante limitado.
Creo que todo se reduce a que la sintaxis XML es posiblemente buena para describir datos, pero no es una excelente sintaxis para lo que es esencialmente un lenguaje de programación (XSLT).
Como se indicó anteriormente, XSLT (como "las partes buenas" de JavaScript) es un lenguaje de programación funcional.La mayoría de los programadores tradicionales odian esta apatridia.Además, muchos programadores tradicionales odian los corchetes angulares.
Pero, lo más importante, el uso correcto de XSLT resuelve tanto la generación de GUI declarativa como el problema de enlace de datos para el servidor web de forma independiente de la plataforma.Los proveedores como Microsoft no están motivados para celebrar este poder “inconveniente”.
Sin embargo, sostendré que Microsoft tiene el mejor soporte XSLT para IDE (Visual Studio). en el mundo.
Creo que intentó cubrir demasiados casos de uso, convirtiéndose así en un lenguaje completo de Turing (o eso escuché).Si intentas hacer cualquier transformación no trivial, terminas escribiendo bucles complejos, condiciones...en un lenguaje feo y prolijo, que se hace mejor con una GPL.
En mi opinión, esta complejidad dificulta la escritura de una implementación correcta de XSLT y limita las opciones disponibles, por lo que su uso está generalizado entre los hackers vocales a quienes a menudo les gusta jugar con código pequeño y eficiente, no con código empresarial.
XSLT es muy poderoso, pero requiere una forma diferente de pensar sobre el problema.También se complicó la vida al no proporcionar funciones de datos útiles en las primeras versiones.Tomemos, por ejemplo, un método de estilo ToUpper(), normalmente lo implementas con algo como:
<xsl:variable name="lcletters">abcdefghijklmnopqrstuvwxyz</xsl:variable>
<xsl:variable name="ucletters">ABCDEFGHIJKLMNOPQRSTUVWXYZ</xsl:variable>
<xsl:value-of select="translate($toconvert,$lcletters,$ucletters)"/>
¡No es la forma más fácil de codificar!
xslt es excelente para xml a xml, cuando tiene datos que ya están escapados y una definición clara de entradas y salidas.usarlo para cosas como xml2html me parece un gran dolor de cabeza, y con casi cualquier lenguaje dinámico y CSS, la salida es mucho más fácil de implementar con estilo.
Lo encontré excelente para la 'arquitectura de servicios web compuesta'. A veces, varios servicios web trabajan juntos para obtener el resultado final. Cuando esos servicios web necesitan comunicarse entre ellos a través de XML, XSLT puede transformar el mensaje xml de una forma a otra.
