|
Excellent interview. Filled with tips, wisdom, humbleness, and humor.
https://www.youtube.com/watch?v=2Zt9oJtFKGw&t=6s A few excerpts from the interview: 1. The BBC’s coverage of the 2012 London Olympics used the free version of Saxon.
2. What makes a good product? Users must be able to understand the error messages. People will tell you, one thing I like about Saxon is the error messages. To me, a bad error message is something
that really needs to be fixed. Error messages are what users are dealing with every day. They are reading my error messages. If those glare out as being unhelpful, as being badly spelt, then that’s their experience with the product, so it’s important to get
it right. I put a lot of effort into those sorts of little details. Getting good error messages it really quite an art. Do you phrase the error message in terms of the proper terminology of the spec, or do you use the terminology that the users are using (which
might be quite wrong)? For example, what many users call a “tag” isn’t what the spec calls a tag. They’ll use “tag” to mean “element.” So which word am I going to use in an error message? It’s quite hard to get that sort of thing right. Getting a balance between
a message that is technically correct and a message that users understand, sometimes requires a fair bit of thought. And then you’ve got to phrase the error message in terms of what the user was trying to do, not what was going on internally. That again gives
you a significant challenge. So you have to think about those sorts of things. 3. My project over the last year has been translating the Java code of Saxon into a C# version of Saxon. To do that, I had to write a translator for Java to C#. How do you write such a translator?
Java has a syntactic structure, you parse it so you’ve got a tree structured information structure and you’re converting that into another tree structured information structure from which you generate C#. How do you transform one tree to another?
4. The benefit of XSLT is not that it’s XML, the benefit is its paradigm: you’re doing a recursive descent, rule-based transformation. That’s what XSLT is, it’s a rule-based language.
5. If you read a textbook on writing compilers, it talks about compiling as a pipeline of tree-to-tree transformations. That is exactly the typical architecture of an XSLT transformation.
6. The resistance to XSLT is because for most people (particularly programmers), XSLT is so different from anything they’ve ever seen before. Using XSLT requires some rewiring of the brain. The
enthusiasts of XSLT get over this initial learning curve and discover why this weirdness is actually a good thing.
7. I sometimes find new technologies quite hard to get familiar with and adopt. That’s because when I look at a new technology I want to have a deep conceptual understanding of it before using
it. I know other people who are much better at picking up something new. They have a different learning style. They learn by example. They see something that works, they bend it and adapt it and make it fit without ever having a deep understanding. You can
over-intellectualize things. I’m on that end of the spectrum. 8. A lot of people have tried to create a different syntax for XSLT. It’s not that difficult to do. I think what’s happened is that when people have done it, they’ve realized that they thought syntax was the problem, but it wasn’t. The
problem is not the syntax. The problem is the concepts: What is a template rule? What does apply-templates actually mean? You
think syntax is the difficulty, but it’s not. The difficulty is actually the semantics of the language. Improving the syntax doesn’t help. The other thing is that once you’ve gotten past the stage of the syntax looking weird, you actually realize that
there are some benefits to having an XML-based syntax. The benefits of any big XSLT-based application that I’ve seen ends up exploiting the fact that XSLT is XML. You’re using the same conceptual tool set to manipulate your data and your source code. That’s
something that comes from Lisp. XML and XSLT are a continuation of the Lisp concept of not separating data from programs. |