XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Interview of Michael Kay on YouTube

Do bear in mind that this was an unscripted conversation, not a written paper. Looking through it, I don't think there's anything I would want to retract, but there are plenty of throwaway remarks that could do with further elaboration, explanation, and qualification.

Michael Kay
Saxonica

> On 31 Jan 2022, at 11:32, Marcus Reichardt <u123724@gmail.com> wrote:
> 
>> 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.
> 
> I generally agree with the sentiment that syntax doesn't or shouldn't
> matter relative to the programming model. However, I take issue with
> this paragraph (if that's a true transcript of what Michael said). I'd
> say XSLT is a good choice when you're using lots of inline XML
> literals, possibly with variables; but if your transforms are
> generating output XML dynamically using lots of <xsl:element> etc
> constructs, there are other logic-based or functional languages that
> have richer integration into a target environment, better testing
> infrastructure, much better support for eg database access or service
> invocation, much better library support, and are less verbose. So the
> syntax argument goes both ways: just that your input data is XML
> doesn't mean your transform language must be.
> 
> Also, I have yet to see a project where XSLT being XML and thus open
> for being generated using an XML toolchain would be much of a benefit
> (and I've worked plenty on XSLT projects, including large ones).
> That's also a variation of the syntax fixation argument: just because
> XSLT is XML doesn't mean you can do meaningful static analysis etc on
> it. The syntax part is the easy thing here; XSLT's Turing-completeness
> is the limiting factor.
> 
> That said, the places where XSLT felt right was with CMS-like
> applications where XSLT was chosen as a customization language of
> sorts (which doesn't seem like a thing anymore), and also for
> country-specific formatting of addresses in proprietary
> retail/logistics systems I've worked on years ago.
> 
> Best,
> Marcus Reichardt
> sgml.io
> 
> On 1/29/22, Dimitre Novatchev <dnovatchev@gmail.com> wrote:
>> Thank you, Egor!
>> 
>> On Sat, Jan 29, 2022 at 11:50 AM Yegor Bugayenko <yegor256@gmail.com>
>> wrote:
>> 
>>> Definitely! Here is the details transcript of our discussion:
>>> https://www.yegor256.com/shift-m/2022/51.html
>>> 
>>> Best,
>>> Yegor
>>> 
>>> 
>>> On Sat, Jan 29, 2022 at 7:40 PM Dimitre Novatchev <dnovatchev@gmail.com>
>>> wrote:
>>> 
>>>> I asked the organizer, Egor Bugaenko (yegor256@gmail.com). 2 weeks ago
>>>> about publishing a transcript of this interview to ensure wider
>>>> availability and much better searchability and referrability, and his
>>>> reply
>>>> on the XML.com Slack was:
>>>> 
>>>> "Yes, indeed, we will add subtitles and a full transcript. Hopefully,
>>>> this week. I will let you know when it’s done."
>>>> 
>>>> Hopefully Egor will keep up to his promise.
>>>> 
>>>> Cheers,
>>>> Dimitre
>>>> 
>>>> On Sat, Jan 29, 2022 at 8:06 AM Roger L Costello <costello@mitre.org>
>>>> wrote:
>>>> 
>>>>> 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.
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Cheers,
>>>> Dimitre Novatchev
>>>> ---------------------------------------
>>>> Truly great madness cannot be achieved without significant intelligence.
>>>> ---------------------------------------
>>>> To invent, you need a good imagination and a pile of junk
>>>> -------------------------------------
>>>> Never fight an inanimate object
>>>> -------------------------------------
>>>> To avoid situations in which you might make mistakes may be the
>>>> biggest mistake of all
>>>> ------------------------------------
>>>> Quality means doing it right when no one is looking.
>>>> -------------------------------------
>>>> You've achieved success in your field when you don't know whether what
>>>> you're doing is work or play
>>>> -------------------------------------
>>>> To achieve the impossible dream, try going to sleep.
>>>> -------------------------------------
>>>> Facts do not cease to exist because they are ignored.
>>>> -------------------------------------
>>>> Typing monkeys will write all Shakespeare's works in 200yrs.Will they
>>>> write all patents, too? :)
>>>> -------------------------------------
>>>> Sanity is madness put to good use.
>>>> -------------------------------------
>>>> I finally figured out the only reason to be alive is to enjoy it.
>>>> 
>>>> 
>>> 
>> 
>> --
>> Cheers,
>> Dimitre Novatchev
>> ---------------------------------------
>> Truly great madness cannot be achieved without significant intelligence.
>> ---------------------------------------
>> To invent, you need a good imagination and a pile of junk
>> -------------------------------------
>> Never fight an inanimate object
>> -------------------------------------
>> To avoid situations in which you might make mistakes may be the
>> biggest mistake of all
>> ------------------------------------
>> Quality means doing it right when no one is looking.
>> -------------------------------------
>> You've achieved success in your field when you don't know whether what
>> you're doing is work or play
>> -------------------------------------
>> To achieve the impossible dream, try going to sleep.
>> -------------------------------------
>> Facts do not cease to exist because they are ignored.
>> -------------------------------------
>> Typing monkeys will write all Shakespeare's works in 200yrs.Will they write
>> all patents, too? :)
>> -------------------------------------
>> Sanity is madness put to good use.
>> -------------------------------------
>> I finally figured out the only reason to be alive is to enjoy it.
>> 
> 
> _______________________________________________________________________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS