Por que o XSLT nunca viu a popularidade de muitas outras linguagens surgidas durante o boom da Internet?[fechado]

Question

O uso de XSLT (XML Stylesheet Language Transform) nunca teve a mesma popularidade de muitas outras linguagens que surgiram durante o boom da Internet.Embora esteja em uso, e em alguns casos, por grandes empresas de sucesso (ou seja,Blizzard Entertainment), nunca pareceu chegar ao mainstream.Por que você acha que isso acontece?

Answer 1

Um problema é que XSLT visual complicado.Qualquer desenvolvedor deve ser capaz de captar as construções da linguagem, pois existem análogos na maioria das outras linguagens.O problema é que todas as construções e dados parecem exatamente iguais, o que torna difícil distinguir entre os dois, o que torna o XSLT mais difícil de ler do que outros idiomas.

Uma segunda questão é que seus usos são mais limitados do que outros idiomas.XSLT é ótimo no que faz;fazendo transformações complicadas ou radicais em XML.Mas não se aplica a uma gama tão ampla de problemas como outras linguagens, por isso não é tão usado.

Terceiro, muitas linguagens de programação possuem suas próprias bibliotecas para transformar XML.Na maior parte do tempo, ao trabalhar com XML, são necessárias apenas pequenas alterações ou pesquisas.O XML provavelmente também está sendo gerado ou consumido por um programa que o desenvolvedor já está escrevendo em outra linguagem.Esses fatores significam que usar os utilitários integrados de uma linguagem é simplesmente mais conveniente.

Outro problema para o qual todas essas questões contribuem é a inércia.Ou seja, as pessoas não sabem disso, não veem que têm muita necessidade disso, então evitam como solução se houver outra opção.

O resultado é uma linguagem que é a última escolha de muitos desenvolvedores na hora de criar soluções.É provável que o XSLT seja evitado quando, como resultado, seria a melhor ferramenta para o trabalho.

Answer 2

XSLTs usa programação funcional - algo com o qual a maioria dos programadores não está acostumada (daí porque algumas pessoas consideram isso não intuitivo, eu acho).

Answer 3

Na minha opinião, uma das coisas mais irritantes no XSLT padrão (estou falando do XSLT 1.0 porque é a única versão que usei) é que faltava suporte para transformações de string e algumas manipulações básicas de funções de data e hora.

Uma coisa que nunca consegui entender é por que uma função como translate() foi projetada e implementada no XPath enquanto outras funções mais úteis, como substituir, abaixar, para_superior, ou - sejamos loucos - as expressões regulares não eram.

Algumas dessas questões foram abordadas, eu acho, com eXSLT (xslt estendido?) para analisadores diferentes do MSXML da Microsoft.Digo que sim porque na verdade nunca o usei, pois foi declarado incompatível com MSXML.

Não entendo por que o XSLT 1.0 foi projetado com esse princípio de que a manipulação de 'texto' não estava no escopo da linguagem, quando é óbvio que sempre que você estiver convertendo arquivos, não poderá evitar esses problemas de conversão de strings (por exemplo,:transformar uma data irregularmente preenchida fornecida no formato francês para o formato americano, 31/01/2008 a 31/01/2008) hein...

Esses problemas de manipulação de texto eram geralmente muito básicos e facilmente resolvidos no MSXML, permitindo que o XSL fosse estendido com funções JScript:você poderia chamar uma função JScript para realizar algum processamento da mesma forma que chamaria qualquer modelo XSL, mas sempre achei essa solução deselegante e acabei criando minhas próprias bibliotecas de modelos XSL.Primeiro porque o modo JScript quebrou sua portabilidade XSL e depois porque forçou você a misturar sua lógica de programação:alguns bits em expressão XPath/XSLT pura e outros bits em notação DOM/objeto com JScript.

Não ter variáveis ​​atualizáveis ​​é outra limitação que confunde muito os novatos, algumas pessoas simplesmente não superam isso e continuam lutando com isso.Em alguns casos simples você pode ter soluções alternativas com uma mistura de modelos paremetrizados e chamadas recursivas (por exemplo, para implementar um contador crescente ou decrescente), mas vamos encarar os fatos, a recursão não é tão natural.

Acho que ouvi que todas essas limitações foram abordadas na especificação XSLT 2.0. Infelizmente, a MS decidiu não implementá-la e, em vez disso, promover o XQuery.Isso é triste, por que não implementar os dois?Acho que o XSLT ainda teria uma boa chance de se tornar tão popular quanto o CSS se tornou para HTML.Pensando bem, a parte mais difícil de aprender XSLT é o XPath, o resto não é tão difícil quanto entender o comportamento em cascata do CSS, e o CSS se tornou tão popular...

Então, na minha opinião, é a falta de todas essas pequenas coisas mencionadas aqui e o tempo que levou para abordá-las no XSLT 2.0 (mesmo sem o suporte da MS) que levou a esta situação de impopularidade.Como eu gostaria que a MS decidisse implementá-lo afinal...

Answer 4

Porque a maioria das implementações XSLT tem um alto consumo de memória (suponho que isso seja causado pelo design da linguagem), porque as pessoas tendem a abusar do XSLT para todos os tipos de coisas para as quais ele não era particularmente adequado e a natureza puramente declarativa do XSL o que torna certos tipos de transformações bastante difíceis.

Answer 5

É ótimo para xml, mas não para codificação típica.Faltam conceitos básicos típicos (isto é, variáveis ​​mutáveis) e torna o que deveria ser simples bastante complexo (ou impossível).A maioria de seus problemas decorre do fato de que xml é uma ótima linguagem de representação de dados, mas não uma ótima linguagem de programação.Dito isto, eu uso diariamente e recomendo onde faz sentido.Em conjunto com namespaces externos, pode se tornar mais útil (chamadas para java, etc.).No final das contas, é outra linguagem para aprender, e muitos programadores preferem ficar com algo com o qual estão acostumados ou que se assemelhe a algo com o qual estão acostumados.

Answer 6

Porque é mais fácil escrever e manter código que usa Java, C#, JavaScript, etc.para desserializar um fluxo XML, transformá-lo e exportar a saída desejada, e o XSLT não oferece nenhuma vantagem substancial de desempenho.

XSLT facilita algumas coisas, mas torna outras coisas muito, muito difíceis.

Answer 7

Bem...Talvez porque seja difícil escrever xslts ...Tive que escrever alguns xslts há alguns meses e estava sonhando com colchetes pontiagudos...

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

(Eu sei que isso não é xslt)

Answer 8

Geralmente, os momentos em que você será solicitado a transformar dados XML em uma forma diferente de dados XML, mas não fará nenhum outro processamento, serão muito limitados.Normalmente o XML é usado como intermediário entre dois sistemas separados, um dos quais geralmente é feito sob medida para processar a saída do outro.Como tal, é mais simples apenas escrever um dos sistemas para processar a saída XML do outro sem a etapa extra de realizar algum tipo de transformação.

Answer 9

XSL é popular e amplamente adotado.A que outras línguas você está se referindo?XSL não é uma linguagem de programação, apenas uma linguagem de transformação, portanto seu escopo é bastante limitado.

Answer 10

Acho que tudo se resume ao fato de que a sintaxe XML é indiscutivelmente boa para descrever dados, mas não é uma ótima sintaxe para o que é essencialmente uma linguagem de programação (XSLT).

Answer 11

Como afirmado anteriormente, XSLT (como “as partes boas” do JavaScript) é uma linguagem de programação funcional.A maioria dos programadores tradicionais odeia esta apatridia.Além disso, muitos programadores tradicionais odeiam colchetes angulares.

Mas, o mais importante, o uso correto de XSLT resolve tanto o problema de geração de GUI declarativa quanto o problema de ligação de dados para o servidor Web de uma forma independente de plataforma.Fornecedores como a Microsoft não estão motivados a celebrar este poder “inconveniente”.

No entanto, argumentarei que a Microsoft tem o melhor suporte XSLT para IDE (Visual Studio). no mundo.

Answer 12

Acho que tentou cobrir muitos casos de uso, tornando-se assim uma linguagem completa de Turing (ou pelo menos foi o que ouvi).Se você tentar fazer qualquer transformação não trivial, acabará escrevendo loops complexos, condições...em uma linguagem feia e detalhada, o que é melhor feito com uma GPL.

Na minha opinião, essa complexidade torna difícil escrever uma implementação correta de XSLT e limita as opções disponíveis, portanto, seu uso é generalizado entre os hackers vocais que muitas vezes gostam de mexer em código pequeno e eficiente, e não em código empresarial.

Answer 13

XSLT é muito poderoso, mas requer uma maneira diferente de pensar sobre o problema.Ele também dificultou sua vida ao não fornecer funcionalidades de dados úteis nas versões anteriores.Tomemos por exemplo um método de estilo ToUpper(), normalmente você o implementa com algo como:

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

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

Não é a maneira mais fácil de codificar!

Answer 14

xslt é ótimo para xml para xml, quando você tem dados que já escaparam e uma definição clara de entradas e saídas.usá-lo para coisas como xml2html para mim parece uma grande dor de cabeça, e com quase qualquer linguagem dinâmica e css a saída é muito mais fácil de implementar com estilo.

Answer 15

Achei ótimo para 'arquitetura de serviço da web composta'. Às vezes, vários serviços da web trabalham juntos para obter o resultado final. Quando esses serviços da web precisam se comunicar entre eles via XML, o XSLT pode transformar a mensagem xml de um formulário para outro.