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.
Thanks,
--
Simon St.Laurent
http://simonstl.com/
