I thought that this debate was over some time ago even if by each camp staying entrenched in their own beliefs. Ben Bryant does not think so and writes the following in his Transformation Example: Apples to Oranges:

It is truly impressive that some developers have mastered a challenging technology such as XSLT which makes any moderately complex task nearly impossible. But is it really worth it? It is funny to me when someone being helpful on Microsoft XSL newsgroup produces a big long stylesheet solution that appears absolutely cryptic.

So according to Ben the XSLT is ill suited for a task like the one described in his post. I suggest you first go and check it out - it's not a long read and boils down to this - if you want to solve a certain class of problems, CMarkup (Ben's product) is the way to go.

Naturally I had to try to prove him wrong ;) I can't blame Ben for advertising his own product, but this is a poor choice of a problem - the problem did not look as something XSLT interpreter/compiler would waste 20 seconds on (using his test case - 6 elements each with 6 child elements, resulting file size about 1.7MB). I first tried the XSLT he described as cryptic (and to a certain degree I agree that it is not very readable). It did not take longer than two seconds on a reasonably fast (or slow) Pentium-M (600MHz when idle that shortly spikes to 1.7GHz while transforming).

Then I went on to produce my own XSLT at fist thinking I might need XSLT 2.0, but it turned out there's nothing here that can't be solved with XSLT 1.0. You could argue that I cheated because I used EXSLT, but that's not really fair - for some reason basic set of math functions in XSLT does not include power; at the same time, EXSLT is an industry standard way of extending XSLT that is present on practically every platform and implementation. Besides, I only used EXSLT for the power function and nothing else. My console test runner was nxslt that itself uses .NET Framework 2.0 compiled XSLT transformer. But first, the stylesheet:

<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:math="http://exslt.org/math">
  <xsl:output method="text" omit-xml-declaration="yes" encoding="iso-8859-1"/>
  <xsl:template match="columns">
    <xsl:apply-templates select="column[1]"/>
  </xsl:template>
  <xsl:template match="column">
    <xsl:param name="running" select="''"/>
    <xsl:param name="index" select="1"/>
    <xsl:variable name="recurse" select="following-sibling::*"/>
    <xsl:variable name="increment" select="math:power(6, count($recurse))"/>
    <xsl:for-each select="col">
      <xsl:variable name="current_running" select="concat($running, ' ', .)"/>
      <xsl:variable name="current_index" select="$index + (position() - 1) * $increment"/>
      <xsl:if test="$recurse">
        <xsl:apply-templates select="$recurse[1]">
          <xsl:with-param name="running" select="$current_running"/>
          <xsl:with-param name="index" select="$current_index"/>
        </xsl:apply-templates>
      </xsl:if>
      <xsl:if test="not($recurse)">
        <xsl:value-of select="concat($current_index, $current_running, '&#13;&#10;')"/>
      </xsl:if>
    </xsl:for-each>
  </xsl:template>
</xsl:stylesheet>

[Edit: as Ben points out in his response, I hard-coded the number of elements to 6; this is easily fixed by changing 6 to count(*) but the fact remains - I assumed same number of child elements of column element] Of course, if you don't know XSLT this will still look cryptic to you.  But if you do understand basic XSLT it should make all the sense, is very short and runs sub-second including the compilation of the stylesheet. It generates 6⁶ rows (list of all combinations [no repeats] of nodes) - about 1.7MB of text, exactly in line with his own test.

Should I conclude that because of this XSLT is better (or at least equal to) than C++ based solution (CMarkup)? Definitely not. If the transformation involved more of the processing that was highly iterative and best suited for a language that allows changes to variables (like C#, C++ or Java) I am sure that using purely XSLT would yield a really ugly solution whereas CMarkup (C++) based one would still look nice and clean. In fact if I wanted I'd probably come up with a better use case for CMarkup where C++ would really shine ;)

Moral of the story is (again) use the right tool for the right job. If all you have is a hammer, don't look at every problem as if it is a nail :)