Will Robertson wrote:
> Hi Jonathan,
>
> I'm only focussing my comments on two slides: the comparison between
> LaTeX and Python documentation, and the slide on the LaTeX3 project.

Good choice.  Thank you.  Here's an executive summary.  You can add a slide, and I've made these changes:
==
 \begin{itemize}
 \item Started in 1993 or so (predates XML, Google, \ldots)
 \item No-one is using \LaTeX3 for typesetting
-\item Last year, \LaTeX3 source placed on SVN server, but \ldots
+\item In 2005, \LaTeX3 source placed on SVN server, but \ldots
 \item They say it's \textbf{explicitly forbidden} to publish \LaTeX3 code
-\item Uses proprietary license (Debian accepted, not OSI-approved)
+\item Uses unusual license (Debian accepted, not OSI-approved)
 \item Current activity focused new macro programming interface
 \end{itemize}
===

> I think it's fair to say that tug.org is the place to look for LaTeX
> documentation:
>   <http://www.tug.org/interest.html#doc>
> I'm thinking that latex-project would do better simply linking there; in
> terms of maintenance, it's much better to have a single point of reference.
>
> So rather than spending half the slides explaining what latex-project
> does inadequately, I think you would do better to explain what/how
> docs.python does and how this would be beneficial for the LaTeX
> community. And possibly whether there are tools that the LaTeX community
> could use for this task.

I took the point of view of a newbie looking for documentation or help on a particular topic, and visited the pages
    http://www.latex-project.org/guides
    http://docs.python.org/
and recorded what I saw.  I think I did a reasonable job (although I did have 'web2.0' expectations).

Perhaps we could ask some real newbies to take a look (usability study).

> The problem, of course, is that Python must have several orders of
> magnitude more active developers than LaTeX, and man-power for such
> thankless tasks is extraordinarily thin on the ground for us.

I think the main problem is that the LaTeX programming and documentation system is print/PDF centric, and does not generate good XML that can be reused and consolidated.


> Now onto the LaTeX3 slide. Where should I start? :)
>
>> ▶ Started in 1993 or so (predates XML, Google, . . . )
>> ▶ No-one is using LATEX3 for typesetting
>
> LaTeX3 isn't a system to be used for typesetting. At least, not yet. A
> less contentious way to word this bullet point might be something like
>
> "LaTeX3 is a project to continue LaTeX2e past its current status of
> maintained but not developed."
>
> (We've discussed backwards compatibility many times before.)
>
> "Current work of the LaTeX3 project is focussing on the transition
> package authors face in moving from LaTeX2e to the ideas of LaTeX3."
>
> (I think that gets the gist across instead of implying that LaTeX3
> exists but no-one is using it.)

I think I say that when I write
>> Current activity focused new macro programming interface

The goal of the LaTeX3 project is to produce an improved system for typesetting.  No-one, at present, is using LaTeX3 for typesetting.  Therefore, this goal has not been met.  The simplest way to say this is:

>> ▶ No-one is using LATEX3 for typesetting

>> ▶ Last year, LATEX3 source placed on SVN server, but . . .
>
> Actually, it was 2005: <http://www.latex-project.org/site-news.html>

Thank you for the correction.  I changed the slides.

>> ▶ They say it’s explicitly forbidden to publish LATEX3 code
>
> I think you mean "re-distribute the source of the" rather than
> "publish". You make it sound like we're not allowing people to use the
> code (which is available on CTAN and through TeX Live/MiKTeX).

On page
    http://www.latex-project.org/code.html
it says
    it is explicitly forbidden to place this material on
    CD-ROM distributions or public servers.

>> ▶ Uses proprietary license (Debian accepted, not OSI-approved)
>
> What do you mean by "proprietary" here? The GPL is a proprietary license
> of the FSF. The Apache Licence is a proprietary license of the Apache
> Foundation. Neither of those licences are distributed under the terms of
> themselves.

I've changed that to 'unusual'

> The LPPL solves a real problem in the community: what do we do when
> authors retire and their packages become no longer maintained but
> another author wishes to step in? Do you think that Karl, Robin, Jim,
> Rainer would simply allow me to update someone else's package on CTAN?

This is /not/ how open-source works.  If I wish to create a new hyperref.sty why shouldn't I.  As you point out, if I did this then CTAN would surely put it in a place where TeX distributions would not pick it up.

My view is that there is a real problem, and the license is not the way to solve it.  That's not how open-source works.   Nuclear weapons are a real problem.  Some people write software and say: My license forbids it to be used for making nuclear weapons.  Fine, but such software is not open-source.

>> ▶ Current activity focused new macro programming interface
>>
>> Here’s an example of the old and new interface:
>>
>>     \def\mymacro #1{\setbox #1\hbox\bgroup} % Old
>>     \cs_new_nopar:Npn \hbox_set_inline_begin:N #1 { % New
>>       \tex_setbox:D #1 \tex_hbox:D \c_group_begin_token }
>
>
> expl3 isn't just about renaming TeX primitives for the sake of it:
>  - toolbox of often-used and otherwise useful functions with consistent
> (and readable!) names
>  - abstract many expansion control problems with better datatypes

[examples snipped]

If you write a single slide on this, I'll put it in my talk.  (And Robin can ask Kate Jeary to make sure I give it reasonable time.)

If you don't, and /if/ I have time, I'll have a go myself from what you've supplied.

It seems to me that the main thing in what I've snipped is a factory for  defining macros.

> This is the thing about expl3: we're not really raising the bar on what
> *can* be written in TeX macros. Rather, we're making it much easier to
> do so; if you can code a simple algorithm simply, it really doesn't
> matter if you're using TeX or Lua or Python. In the past, however, it
> hasn't been as possible to code a simple algorithm simply in TeX macros.

I used to think in that sort of way, but I don't now.  Rather, I think that TeX macros are not suitable for this sort of purpose and a different language should be used.  A mainstream language.

>> It doesn’t even get named parameters (instead of #1).
>
> There's a lot more that qualifies for "doesn't even get" than named
> parameters. I think it's safe to say that not one macro package has ever
> failed to be completed because the author had to write ####1 instead of
> #foobar.

No, but it is a tremendous convenience, and about 6 months ago I posted a solution to this to comp.text.tex.

> As we've previously discussed, I believe that interfaces for keyvals are
> much more important than whether internal function parameters are named
> or numbered (since from the *user's* point of view, it doesn't make a
> shred of difference).

Yes, and that's another topic - which I cover in my slide
    Python documents: latex2html and Sphinx

--
Jonathan


The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).