On 12/9/13 11:25 PM, Ihe Onwuka wrote:

    No, you can't do any of those things.  However, there is an enormous
    class of tasks for which those issues simply do not matter.

What about the enormous class of tasks for which the built in default
rules of  XSLT combined with inheritance (sorry I meant xsl:import -
tomayto tomarto) are ideally suited but the language is not used.

People frequently don't use XML tools because we've (myself included) done an incredibly poor job over the years of presenting and explaining them.  They integrate them with their own systems, find that they aren't a neat fit with what they expected, and use them minimally or drop them.

Then they're rewarded - if they ever look at this list, which is fortunately more and more likely - with remarks about "don’t have the inclination, patience or capability to fully understand your language of choice."

    I get that people on an XML list freak out when people don't follow
    all the rules we think we've established.  We need to find a better
    way to handle our freaking out than sputtering about "either stupid
    or poorly trained" people who "don’t have the inclination, patience
    or capability to fully understand your language of choice."

    It makes us look bad, not them.  It hurts our cause(s), and doesn't
    help theirs.

Ok, I deliberately avoided pointing out that you were the one who
introduced the word stupid into the discussion. I can see that was an
error because you have repeated and layered the word condescension on
top  of it. Voila that is now  the barometer for judging the alternative
argument.

It's terrible when people summarize a post that punches down by calling it critical of the people it was punching down at.

I get that it's hard to see the damage inflicted by such punching down when you think you're on the up side of the argument.

Look programming is hard.

Yeah, I get that.  I've been teaching programming for the past how many many years?  In person, via books, via other people's books.  If it was easy I would probably have found something harder to explain.

Part of the challenge, though, and a strange feature that's done well for me over the years, is that few programming communities are good at explaining what they do.

Many even pride themselves on welcoming outsiders but then drown them in expectations of vocabulary and best practices.  Then they puzzle over what's wrong with the people who were trying to come in.

Pretending that anybody can do it has never
and will never help.

"Anybody can do it" completely depends on the context.  We are not breaking new ground like Donald Knuth any more.  A few core people need potent skills to write, for example, transformation engines, but most of it is more tractable for a much wider group of people.

XML was supposed to make all of these problems more tractable, for people who were not super-programmers.  Hence the DPH, hence the effort to reach a broad world.

That effort failed, and now we sit here talking about how the common tools are the wrong tools and people who "don’t have the inclination, patience or capability to fully understand your language of choice" - their language of choice - of course can't be trusted to deal with XML.

The stupidity and condescension arguments are complete red herrings -
clearly the people who build these XML parsers aren't stupid and the
many people  who use them aren't either. It's a real shame you
introduced such perjorative terminology to advance your argument (wonder
why) because it has had sidetracked and had a deleterious effect on the
quality of discussion.

The original post was perjorative - I deleted the word "obnoxious" from my earlier posts repeatedly.  It will make a nice exhibit A for future conversations about how the stories the XML community tells to dismiss concerns about its viability.

    That attitude is exactly why I've largely given up speaking about
    XML to broader audiences and retreated to "markup".  It doesn't
    carry the elitist baggage or visions of infinite complexity.


Ok well you have a different level of concern. The Fowler link I posted
about Ruby being better than XSLT for parsing  didn't make reference to
elitist baggage or infinite complexity. The thing that popped into my
head when reading it was the same thing that pops into when I read
similar complaints and expressions of frustrations of people far less
accomplished.

I liked your earlier comment on Fowler about choosing solutions when you hire a consultant.  That part is completely true.

However - and I last talked with Fowler in 2005? - it seemed pretty clear that his antipathy to XML came from its promising to be a simple silver bullet and then perpetually adding layers.  It's been a while, so the details are fuzzy, but even at the time I was nodding my head and apologizing for our screw-ups.

Do you know the built in default processing rules Martin? Alas he never
mentions if he does. It is completely understandable that XSLT will seem
a pointless anachronism to anybody - no matter how smart - if they don't
know these rules.

These rules are the magic of XSLT.  Invisible but omnipresent and powerful.  Magic has pluses and minuses - they make things easier if you either know what you're doing completely or are willing to follow recipes precisely.  Magic slashes you to bits if you don't understand it completely or stray from the recipes. 

(I didn't understand that problem well until I spent too much time with Ruby on Rails.  Magic that keeps changing and introduces security issues makes the difficulties more visible, of course.)

So the next question is how hard is it for people to know these rules.
There are how many - 7? - ok on or just above  the upper limit of what
we can expect people to remember  - but the Gods were merciful and
alleviated our pain somewhat. They made the defaults do the thing we
were most likely to want to do and them conceptually similar to the
dispatch mechanism of OOP and everybody understands that - right.

Unless, of course, default namespaces were involved, and then things derailed every time a new person joined the conversation.  This appears to have been the Gods' punishment to the XSLT community, counterbalancing the generosity.

I would posit that this has nothing to do with stupidity, elitism,
condescension, training or infinite complexity.

The rules themselves have nothing to do with those, except perhaps the last.  However, our responses to the rules, the human responses upon which things get done or do not get done, include all of those.

Programmers like to think programming is a neat test of logic and ability to follow the rules set forth by humans and the language-creation priesthood. (The acolytes create frameworks, I guess.)

The rest of the world understands that programming is about interactions among humans, with computer interactions only one small part of the conversation.

Rather it comes down to whether or not one knows the built-in default
rules. In turn that invites the question whether they are onerous to
learn and whether it is reasonable for a DSL to have such idiosyncrasies
(isn't that what makes it a DSL). Then it's  whether or not going off to
build or use a parser from a general purpose language is a reasonable
response to not being willing to learn the built in rules. If you knew
'em fair enough - but I'd like to think that to know them is to love them.

This last sentence has been XML's recipe for initial success and then repeated failure.  "Just a few rules," we say, "and you'll like them. To know them is to love them."

We say that because we like them - because we've internalized the benefits and forgotten the costs.  Well-formedness isn't hard - "just stay away from creating XML with text-processing tools and you'll be fine."  Namespaces aren't hard - just don't touch the stove in those places when it's on.  XML Schemas are hard because the world is hard and they need to be powerful.  XSLT only has a few issues...

XML had a strong start, with lots of people liking the capabilities and many even the rules.  The XML community has not found such success since the early days, however.

The other interesting element is the declarativeness of the language as
the the roll call of declarative languages that achieved widespread
acceptance has a length of (going out on a limb here) 1.

SQL.

2.

You forgot the one that squashed XSLT's initial hopes: CSS.  Utterly declarative, though so far thankfully not aiming for Turing-complete. Occasionally hated for its declarative nature by programmers, cursed with a limited (but now finally changing) layout box model, but used constantly by people from skill levels from beginner to superstar.

(Proving to be a solid foundation for people who want to create more powerful languages on top, too.)

We need to stop wondering why people don't want to use 'our' tools and start figuring out how to reach them.  

Or, if we prefer, we can spend our time on endless iterations of this thread, stewing in our own greatness and wondering why it is that people from cut-and-paste coders to well-respected consultants don't grasp the power and beauty that is the XML family of specifications.

That last is unfortunately a permathread here.  I should stop poking at it - the battle seems pretty much lost to me in any case, at least as far as the XML moniker goes.  I just don't love the toxins it periodically produces, as here.