[XML-SIG] Re: XML DTD for Python source?

[Paul Prescod]

gvwilson@nevex.com wrote:
> 
> ...
>
> Structured comments sound to me like an after-the-fact rationalization of
> an out-of-date infatuation with flat ASCII... :-)

Python is no more "flat" than XML. XML's tree happens to be very
well-hyped.

I will go this far: Python could use better ways of attaching structured
content to methods, classes and other declared objects. It seems that
structured docstrings will be the mechanism. As long as there is a
single structured docstring syntax (or at least meta-syntax) I think
that that solution is reasonable but you are right that in a perfect
world Python would have anticipated structured annotations in the
beginning (does any language??).

> > Third party browsers and processors can handle a Python AST if you
> > give them a plug-in.
> 
> I thought the whole point of having a standard (like XML) was to free you
> from plug-ins...

Like I said, a stylesheet is a plugin. XML frees you from having your
plugin do text parsing because you can depend on the XML parser for
that. But for behavior or display you still need the plugin. Of course
avoiding the parsing is a big deal...that's why XML is popular.

> > Anyhow, if you are really interested in third-party browsers, the best
> > thing would be to convert into colorized *HTML*.
> 
> What is your metric for claiming that this is "best"?

Ubiquity of the browsers.

> > Dozens of people have tried and given up on programming in XML.
> 
> If you mean "using XML syntax directly as a programming language", then
> yes, it's a bad idea.  If you mean "using XML under the hood to store
> programs", then I'd be grateful for references.

Well nobody ever proposes the idea without claiming that the ugliness
will be hidden behind an editor interface...it was also based on this
argument that we allowed XML to get so verbose. I argued then and now
that the text mode always comes to be the mode that people use for
editing because the effort of customizing XML editors is just too high.
It's like creating an Emacs mode. But your success criterion (8 year old
nephew loves it) is a lot higher.

> > That's pretty trick to read. So what we really need is for the editor
> > to compress it to something more readable -- like the original
> > notation...
> 
> ...or curly braces, or Scheme-style parentheses, or maybe pretty little
> icons decorating the control structure for my 8-year-old nephew, or...

Okay, I like the last idea, but not the first two. I think that icons
are great as annotative extensions to the textual syntax. I also think
that Emacs could be taught to do them.

I don't like the ideas that *replace* syntax with other syntax becuase
what happens when your nephew tries to join comp.lang.python. What about
when he's discussing Python programming on a white-board with his
buddies. What about scribbling on paper? Shared notations are useful.

Using someone else's emacs environment is hard enough. :)

> > Seriously, I get paid to customize XMetaL and its ilk for document
> > types. It's hard enough making them usable for the document-world they
> > were designed for. Making them good programming environments would be
> > more work than adding multimedia hooks to Emacs pymode (IMHO).
> 
> Which is easier to teach to 8-year-olds?

Emacs and XMetaL are both editing environment frameworks. I think that
either one can be taught to be friendly. Neither is inherently so. The
effort required to make them friendly is proportional to the distance
between the default behavior and the required behavior. Emacs at least
has a "pymode".

Maybe five years from now XMetaL will be so much more customizable that
I would be more optimistic about using it for programming. But XMetaL's
has been under development for 10 years now so I am starting to lose
hope of any massive usability breakthroughs.

Here's another point: in my opinion, from a user interface point of
view, every major XML editor has made a big mistake. When I make a
syntax error in Microsoft's software development environment, it flags
it but gives me the freedom to do what I want. That's right. XML editors
tend to require you to go into a "don't tell me about my mistakes" mode
to do anything weird. That's wrong. The little squiggly line under
misspelled words or programming language typos is, in my opinion,
brilliant.

After all, the path from syntactically incorrect to correct could be
arbitrarily weird. It isn't just about "incomplete programs". Sometimes
I make radically incorrect programs on purpose. e.g. I might type the
end-quotes of a triple quoted string before the start quotes because I
just happen to be in that part of the program.

Another aside:

Note that I am not an Emacs user because I hate so many of the default
bindings (they make my hands hurt) and the "binding portability problem"
stops me from just defining my own...

hmmmm....what if Emacs had a feature to fetch configuration files from a
URL (simply, through a menu item...without lots of pre-startup hacking).
That would go a fair way to making it more useful to me.

Another aside:

You may well agree with me on this but my opinion is that the number one
thing you can do to make programming languages fun for 9 year old boys
is hook them up with cool libraries like 3d turtles and programmable
dungeon environments. Ideally, they would learn how to do something in a
GUI, and then evolve to a command line in order to "store" actions and
then to a programming language to store lists of actions with control
flow.

If you design the perfect, customizable Python programming environment,
it will not matter whether the underlying syntax is XML or Python text
or even pickled ASTs.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"We still do not know why mathematics is true and whether it is
certain. But we know what we do not know in an immeasurably richer way
than we did. And learning this has been a remarkable achievement,
among the greatest and least known of the modern era." 
        - from "Advent of the Algorithm" David Berlinski
	http://www.opengroup.com/mabooks/015/0151003386.shtml