Perché XSLT non ha mai visto la popolarità di molte altre lingue emerse durante il boom di Internet?[Chiuso]

Question

L'uso di XSLT (XML Stylesheet Language Transform) non ha mai visto la stessa popolarità di molti altri linguaggi emersi durante il boom di Internet.Mentre è in uso, e in alcuni casi da grandi aziende di successo (ad es.Blizzard Entertainment), non è mai sembrato raggiungere il mainstream.Perché pensi che sia questo?

Answer 1

Un problema è che XSLT sembra complicato.Qualsiasi sviluppatore dovrebbe essere in grado di apprendere i costrutti del linguaggio poiché esistono analoghi nella maggior parte degli altri linguaggi.Il problema è che i costrutti e i dati sembrano tutti esattamente uguali, il che rende difficile distinguere tra i due, il che rende XSLT più difficile da leggere rispetto ad altri linguaggi.

Un secondo problema è che i suoi usi sono più limitati rispetto ad altri linguaggi.XSLT è eccezionale in quello che fa;effettuare trasformazioni complicate o radicali su XML.Ma non si applica a una gamma di problemi così ampia come altri linguaggi, quindi non è usato così tanto.

Terzo, molti linguaggi di programmazione hanno le proprie librerie per trasformare XML.Nella maggior parte dei casi, quando si lavora con XML, sono necessarie solo piccole modifiche o ricerche.Probabilmente l'XML viene anche generato o consumato da un programma che lo sviluppatore sta già scrivendo in un'altra lingua.Questi fattori significano che l'utilizzo delle utilità integrate di una lingua è semplicemente più conveniente.

Un altro problema a cui contribuiscono tutti questi problemi è l’inerzia.Cioè, le persone non lo sanno, non vedono di averne molto bisogno, quindi lo evitano come soluzione se c'è un'altra opzione.

Ciò che si ottiene è un linguaggio che rappresenta l'ultima scelta di molti sviluppatori durante la creazione di soluzioni.È probabile che XSLT venga addirittura evitato quando di conseguenza sarebbe lo strumento migliore per il lavoro.

Answer 2

XSLT utilizza la programmazione funzionale, qualcosa a cui la maggior parte dei programmatori non è abituata (ecco perché alcune persone lo considerano non intuitivo, immagino).

Answer 3

A mio parere, una delle cose più fastidiose nell'XSLT standard (sto parlando di XSLT 1.0 perché è l'unica versione che ho usato) è che mancava il supporto per le trasformazioni di stringhe e alcune manipolazioni di base delle funzioni data-ora.

Una cosa che non sono mai riuscito a capire è perché una funzione come Translate() è stata progettata e implementata in xpath mentre altre funzioni più utili come sostituire, ridurre, in_superiore, oppure - siamo pazzi - le espressioni regolari non lo erano.

Alcuni di questi problemi sono stati risolti, immagino eXSLT (xslt esteso?) per parser diversi da MSXML di Microsoft.Dico immagino perché in realtà non l'ho mai usato poiché è stato dichiarato incompatibile con MSXML.

Non capisco perché XSLT 1.0 sia stato progettato con questo principio secondo cui la manipolazione del "testo" non rientrava nell'ambito del linguaggio quando è ovvio che ogni volta che si convertono file non è possibile evitare problemi di conversione di stringhe (ad es.:trasformare una data irregolarmente riempita data dal formato francese al formato americano, dal 31/1/2008 al 2008-01-31) eh...

Questi problemi di manipolazione del testo erano generalmente molto semplici e facilmente risolvibili in MSXML consentendo l'estensione di XSL con funzioni JScript:potresti chiamare una funzione JScript per eseguire alcune elaborazioni proprio come chiameresti qualsiasi modello XSL, ma ho sempre trovato quella soluzione inelegante e ho finito per creare le mie librerie di modelli XSL.Innanzitutto perché il metodo JScript ha compromesso la tua portabilità XSL, e poi perché ti ha costretto a mescolare la tua logica di programmazione:alcuni bit nella pura espressione XPath/XSLT e altri bit nella notazione DOM/oggetto con JScript.

Non avere variabili aggiornabili è un'altra limitazione che crea molta confusione per i nuovi arrivati, alcune persone semplicemente non riescono a superare questo problema e continuano a lottare con quello.In alcuni casi semplici è possibile trovare soluzioni alternative con un mix di modelli paremetrizzati e chiamate ricorsive (ad esempio per implementare un contatore crescente o decrescente) ma ammettiamolo, la ricorsione non è così naturale.

Penso di aver sentito che tutte queste limitazioni erano state affrontate nelle specifiche XSLT 2.0, purtroppo MS ha deciso di non implementarle e promuovere invece XQuery.È triste, perché non implementarli entrambi?Penso che XSLT avrebbe ancora buone possibilità di diventare popolare quanto lo sono stati i CSS per HTML.Se ci pensi, la parte più difficile nell'apprendimento di XSLT è XPath, il resto non è così difficile come comprendere il comportamento a cascata nei CSS, e i CSS sono diventati così popolari...

Quindi, secondo me, è la mancanza di tutte quelle piccole cose menzionate qui e il tempo impiegato per risolverle in XSLT 2.0 (senza che nemmeno MS lo supporti comunque) che ha portato a questa situazione di impopolarità.Dopotutto, come vorrei che MS decidesse di implementarlo...

Answer 4

Perché la maggior parte delle implementazioni XSLT hanno un elevato ingombro di memoria (suppongo che sia causato dalla progettazione del linguaggio), perché le persone tendevano ad abusare di XSLT per tutti i tipi di cose per cui non era particolarmente adatto e la natura puramente dichiarativa di XSL il che rende alcuni tipi di trasformazioni piuttosto difficili.

Answer 5

È ottimo per XML, ma non eccezionale per la codifica tipica.Manca di concetti di base tipici (cioè variabili mutabili) e rende ciò che dovrebbe essere semplice piuttosto complesso (o impossibile).La maggior parte dei suoi problemi derivano dal fatto che xml è un ottimo linguaggio di rappresentazione dei dati ma non un ottimo linguaggio di programmazione.Detto questo, lo uso quotidianamente e lo consiglierei dove ha senso.Insieme agli spazi dei nomi esterni, può essere reso più utile (chiamate a Java, ecc.).Alla fine, è un'altra lingua da imparare e molti programmatori preferirebbero restare con qualcosa a cui sono abituati o che assomiglia a qualcosa a cui sono abituati.

Answer 6

Perché è più semplice scrivere e gestire codice che utilizza Java, C#, JavaScript, ecc.per deserializzare un flusso XML, trasformarlo ed esportare l'output desiderato e XSLT non offre alcun vantaggio sostanziale in termini di prestazioni.

XSLT rende alcune cose facili, ma rende altre cose molto, molto difficili.

Answer 7

BENE...Forse perché è una seccatura scrivere xslts...Ho dovuto scrivere qualche xslt qualche mese fa e sognavo le parentesi appuntite...

<Really> 
    <No>
        <fun/>
    </No>
</Really>         

(Lo so, questo non è xslt)

Answer 8

In generale, i tempi in cui ti verrà richiesto di trasformare i dati XML in una forma diversa di dati XML, ma non di eseguire altre elaborazioni saranno molto limitati.Di solito XML viene utilizzato come intermediario tra due sistemi separati, uno dei quali è solitamente personalizzato per elaborare l'output dell'altro.Pertanto è più semplice scrivere semplicemente che uno dei sistemi elabori l'output XML dell'altro senza il passaggio aggiuntivo di dover eseguire qualche tipo di trasformazione.

Answer 9

XSL è mainstream e ampiamente adottato.A quali altre lingue ti riferisci?XSL non è un linguaggio di programmazione, solo un linguaggio di trasformazione, quindi ha una portata piuttosto limitata.

Answer 10

Penso che si riduca alla sintassi XML che è probabilmente buona per descrivere i dati, ma non è un'ottima sintassi per quello che è essenzialmente un linguaggio di programmazione (XSLT).

Answer 11

Come affermato in precedenza, XSLT (come “le parti migliori” di JavaScript) è un linguaggio di programmazione funzionale.La maggior parte dei programmatori tradizionali odia questa apolidia.Inoltre, troppi programmatori tradizionali odiano le parentesi angolari.

Ma, cosa più importante, l'uso corretto di XSLT risolve sia il problema della generazione dichiarativa della GUI che quello dell'associazione dei dati per il server Web in modo indipendente dalla piattaforma.Fornitori come Microsoft non sono motivati ​​a celebrare questo potere “scomodo”.

Tuttavia, sosterrò che Microsoft offre il miglior supporto XSLT per l'IDE (Visual Studio) nel mondo.

Answer 12

Penso che abbia cercato di coprire troppi casi d'uso diventando così un linguaggio completo di Turing (o almeno così ho sentito).Se provi a eseguire una trasformazione non banale, finisci per scrivere cicli, condizioni complessi...in un linguaggio brutto e prolisso, cosa che è meglio fare con una GPL.

A mio avviso, questa complessità rende difficile scrivere una corretta implementazione di XSLT e limita le scelte disponibili, quindi un uso diffuso tra gli hacker vocali a cui spesso piace armeggiare con codice piccolo ed efficiente, non con codice aziendale.

Answer 13

XSLT è molto potente, ma richiede un modo diverso di pensare al problema.Inoltre si rendeva la vita difficile non fornendo funzionalità di dati utili nelle prime versioni.Prendi ad esempio un metodo in stile ToUpper(), in genere lo implementi con qualcosa del tipo:

<xsl:variable name="lcletters">abcdefghijklmnopqrstuvwxyz</xsl:variable>
<xsl:variable name="ucletters">ABCDEFGHIJKLMNOPQRSTUVWXYZ</xsl:variable>  

<xsl:value-of select="translate($toconvert,$lcletters,$ucletters)"/>

Non è il modo più semplice di codificare!

Answer 14

xslt è ottimo per xml to xml, quando si hanno dati già sottoposti a escape e una chiara definizione di input e output.usarlo per cose come xml2html mi sembra proprio un vero mal di testa, e con quasi tutti i linguaggi dinamici e CSS l'output è molto più facile da implementare con stile.

Answer 15

L'ho trovato ottimo per l'"architettura di servizi Web compositi". A volte diversi servizi Web lavorano insieme per ottenere l'output finale. Quando tali servizi Web devono comunicare tra loro tramite XML, XSLT può trasformare il messaggio XML da un modulo all'altro.