Perl did win, for a period of time .. expecting an interpreted language to dominate for multiple decades is unrealistic, especially with hardware advances that occur over time.
while I don't do anything with it today, I do know Perl/6 would be in contention for my 'deserted island' language of choice.
I have to agree; if Perl didn't "win", then who did?
Python? Very popular. Solid language. Probably at some point more adopted than Perl, but not so much so that I can say it "won", partially because of how this list goes on.
Ruby? Same.
PHP? Maybe in the web space but not in general.
Javascript? Even in light of Node, this is still a marginal language out of the browser, especially considered over the past 15 years.
Lua? No.
Perl may not have "won" but it has hardly "lost", and now IMHO the sun is just beginning to set on this entire catagory of 1990s-style dynamic scripting language and there probably will be no further "winner" in this space.
yes, its a typical scenario ... XSLT is one of those languages where people either love it or hate it ... I think its to do with the fact that it takes a bit longer to become productive or useful in XSLT, most developers are expected to just immediately start writing code that 'does stuff' these days.
Anyhow, I see most of developers pain with XSLT is because they never learned the basics of the language and thrash about ... perhaps thats the biggest fault of the language, in that its difficult to tell its story with an analogy to where people start from. Anyhow, learning any fp language tends to improve a developer as a programmer
XSLT v1.0 is severely limited and many of the idiosyncratic behaviour ppl associate with XSLT in general is because they hit some very hard to parse/understand/grok things in XSLT v1.0
I remember in 2001-2002 sending the following link, when anyone said 'I am having a problem with XSLT transform'
I can say with high confidence that I've probably written more XSLT then any of the commentators here ... respect completely their right to hate/love/ignore any tech, but many of the comments here are based on very little fact.
* first bugbear - XSLT is not an implementation of lisp (or insert lang here), we shouldn't care if it implements said language well or not
* XSLT is extremely well (saxon) implemented in some processors and poorly in others ... unsure what that has to do with the language itself.
* XSLT has more implementations then a lot of other popular languages (Ruby, Perl, python come to mind), that doesn't make it better (or worst) then those languages ... its just a fact.
* there are no security vulnerabilities in the design of XSLT that I am aware about (well, there are, and most certainly are in implementations, but at that level I can call out issues with every language and its processor(s)) ... stating it is insecure by design is rubbish
* anyone using XSLT v1.0 should know that there has been, for years, an XSLT v2.0 production ready version in the form of saxon-ce (w/ appropriate open source license) ... I can't explain why folks insist on using XLST v1.0, some are doing so cause they can't migrate to XSLT v2.0, many of them are unaware of new options.
I can understand why folks find XSLT hard, or hurts their brain or makes them want to cringe at the mention of an angle bracket ... teaching basic programming idioms is hard for most people, learning fp principles is even more of a bender (esp if you come from OO world) ... XSLT template matching is a powerful mechanism which allows one to perform transformations with a succinct set of matching rules ... but yes it is verbose and like many languages, XSLT has its ugly points to the language.
If you are allergic to angle brackets, then any language that uses them is going to be anathema to them, but every person I've known who have learned XSLT became a better programmer for it. Thats my own personally biased single data point observed 'fact'.
Learning XSLT definitely helped me write much better views in any MVC/MVVM project I have, because the whole approach to template matching is useful as a general design principle. When I'd first started in web development, my views were all very top-down and rife with control logic. After spending considerable time rendering my pages by building XML and applying XSLT, I found a lot of the skills transfer.
Lately I've been working a lot in React, and I've found that just understanding the new syntax can be learned in a weekend -- instead of transforming an XML doc, I load JSON into my state, and instead of writing <xsl:template>s I write React classes. The sort of skills that one refines over years, namely how to think of your rendered page as being composed of various smaller templates, benefit me everywhere. XSLT was a really intensive way to force myself to learn to think that way. Even my mixed PHP/HTML that I occasionally still have to write is considerably better.
to your point about XSLT v1, I can speak to why it's so rarely used at least by PHP devs: v1 has been included as a default extension in PHP builds for many years, but v2 has always required a separate installation of saxon. I just checked on my reasonably up-to-date ubuntu default install, and it's XSLT 1.1.28. That's still far better than Go, where the only approach I've seen is to just install command-line xsltproc and execute that. v2.0 isn't going to catch on while v1.0 is what's considered the de-facto standard, and v1 being the de-facto standard is a big part of why so many have a poor opinion of xslt.
I don't think learning XSLT made me a better programmer, but it is an amazingly useful tool for dealing with large amounts of XML (which is what it was designed for). That said, the way XPATH works is -- to put it mildly -- counter-intuitive.
My biggest gripe with XSLT is debugging. It's just not very much fun. Insofar as it forces you to reason very carefully about your code, that's probably good practice if you haven't already had plenty of practice -- e.g. developing websites before we had decent browser consoles, or writing INITs and TSRs in the 80s.
We were probably using it for very different things (I used it to render my HTML for a PHP site), but I actually found the debugging part to be a huge advantage of xslt. The errors I had relating to basic config and encoding issues were all big headaches, sure, but debugging issues caused by my own incorrect assumptions about how my data was structured was great -- I never felt lost and every message gave me a clear idea what I needed to look at.
related to me by a drunk baker some evening many moons ago -
'sliced bread has more surface area, so goes stale faster; companies loved it because their bean counters found out that people ended up buying more bread for the perceived convenience. By the time they started crazy additives for longer life, people were convinced that sliced bread is better. Throughout, people were eating less and less bread ... as a slice with your meal so its usage has changed quite a bit as well.' As the evening wore on, he probably had a point, but I missed it.
Now I do not know the veracity of the above ... what is clear to me is that (like many things in the western world) bread is no longer bread (that strange sliced white loaf is probably full of sugar, etc) ... having lived in countries for 20 years where I slice my bread I've not noticed the incredibly time consuming act of slicing bread.
while I don't do anything with it today, I do know Perl/6 would be in contention for my 'deserted island' language of choice.
yet another dph