Just wanted to post a recent email exchange I had with an Italian professor over my XML Literate Programming system, because I think I had some good diary material in there:) --
First of all, let me make sure you understand the idea behind my project,
and literate programming in general.
Literate programming (as you may know) is about programming in such a way
that instead of writing a program to a machine, you are instead writing a
book or paper to a human about writing a program to a machine. This makes
software development easier in the long run for the following reasons:
- The formal documentation _is_ the program and therefore does not need to
be separately maintained
- The code is organized in a fashion to be understood by a human, allowing
easier transition of new maintainers to the project
- The code is more correct, as each section is described in human form to
others, and it is easier for others to see where the description and the
code do not agree
- These factors should lead to better programs, and easier transitions
between code maintainers, and less overall cost for the long-term.
Now, about my project -
Donald Knuth in his book "Literate Programming" described a system he
wrote for doing literate programming called CWEB. Although it was a nice
system, I saw shortcomings:
- It required that you learn TeX, which is all but unused today and is
_very_ tricky to get right
- The system was geared toward a specific programming language and a
specific set of TeX macros.
XML Tangle solves these problems by using a standard tag language (XML),
and also being both programming language and DTD-agnostic.
Early versions of XML Tangle required a specific tagset. The current
version, available at http://literatexml.sourceforge.net/ uses Processing
Instructions, so you can use any tag set you want, including DocBook,
HTML, TEI, etc. In fact, I've heard that future versions of Microsoft
Word may be XML-based, so it may be possible to even use their format
(although, if they do not allow you to directly modify the processing
instructions, you probably will not be able to use the Microsoft Word
_application_ even if you can use the Microsoft Word _format_/DTD).
Also note that this program takes an extra patch that I haven't committed
yet to run under Python 2. Python 1.5 (or whatever ships with Red Hat
7.3) works fine with it.
Now to your specific questions:
I' m interested in thinking to that subject.. So I ask you if you have
extended your ideas and particularly if you think that TDT has to
conserved or abandoned ..
My main wondering is whether or not this whole thing can be accomplished
using the SGML Architectural Engine instead of my specialized program. As
I've already made it DTD-agnostic, I don't need to conserve or abandon it
:) Although I do think my selection of processing instructions is
adequate at least for now.
My main gripe about the system is that there are no easy-to-use tools for
programming with it. As I've started using it for a book I'm writing,
I've found typing all of the processing instructions tedious, and a good
XML GUI or emacs mode for doing this would be great, if I ever find the
time to write one.
I also think that I should add language-specific hooks, especially for
formatting and indexing, but I don't have any concrete ideas about these
One thing that is definitely deficient in this system is the ability to
move from a non-literate program to a literate one. One of the greatest
things about the Perl programming language is that you can start writing a
program as a quick hack, and then gradually morph it into a beautifully
structured object-oriented program. Perl helps you move through the
stages of program development. Most programs you do not know the
structure when you sit down to write it, so you crank out something mostly
procedural. Then, as you develop it, the objects, systems, and subsystems
begin to be clear. Perl makes it easy to refactor your procedural code
into objects and classes, and therefore helps you move your program from
the mess it started out as to a beautiful structure. My literate system
has no similar ability to help people go from an "illiterate" program to a
"literate" program. It is only really useful for programs which start out
in a literate state. If you have any suggestions on how I can fix that,
they would be greatly appreciated!
I think I've answered that one. Let me know if I left anything out.
Now with your next question:
Moreover I ask you if "the fact that EXCEL and ACCES accept quite well
XML documents " could give rise to a different approach to programming:
The case of EXCEL is quite eloquent: using macros could transform a non
programmer in a programmer..for limited pourposes (the majorit.. in
This question deserves quite an extended answer, as there are several
questions hidden in there.
First of all, accepting XML documents is not the issue. In fact, using
XML to program with isn't the issue either. XML is currently becoming
overly used. XML is useful for the following reasons -
For the XML author -
- It's easy to write - the syntax is simple with few, regularized
exceptions. In addition, everyone already knows HTML
- Tags are (sometimes) flexible, depending on the application
- Trees match how people normally think
For the programmer -
- Don't have to re-invent the wheel when developing a file format
- Already have half a parser written
- Tree structures are easy to manipulate (although they are not as
flexible as relational structures)
- File format problems are easier to debug because of the plain-text
XML is essentially the new syntax for S-expressions.
Now on to your question -
The ability to accept an XML document does not really mean much. I am not
aware of the specifics of those two programs, but it really isn't that
helpful if it only allows it with a rigid, complicated DTD. It's just a
different file format, which really doesn't benefit the end-user that much
- it just simplified Microsoft's process of writing a parser.
In addition, it does not solve the problems solved by Literate
Programming - namely the ability to communicate programs clearly to other
human beings. Excel macros are especially difficult in this regard,
because each formula has to be inspected individually - and some fields
may not even be apparent that a formula exists. Documentation within a
spreadsheet is especially difficult.
Is Excel a good tool? Sure, it's excellent for simple things. It's
especially excellent for non-programmers who want to test out new ideas
and formulas without hiring a programmer. However, it does not lend
itself to scale very well. I would consider it a prototyping tool which
is useful for learning what you want, and useful for production for fewer
than 5 users. Past that it requires a disciplined programmer to manage
and administer so that it is usable in multiple environments, interacts
well with other programs, is properly tested and robust, and is
well-documented. No large operation should base itself on undocumented
Many of the same problems are applicable to Access as well. Personally, I
do not like Access because for the things that most novices can use it
for, they can do it easier on a spreadsheet. Then, for tasks of medium or
larger complexity, it is really the wrong tool. A true relational
database should be used, with its architecture tied to the data sources
available within the rest of the organization. One of the biggest
problems I've found within the industry are individuals who create Access
databases thinking that they have created a "real" database and program,
and believe that it should only take their IT personnel a few minutes to
post as an application for all users. The IT person then finds that their
fields are nothing but varchars, there are no constraints, and it is full
of bugs, and is a real mess. Add to that the scalability limits of
Access, and you can see how Access can be problematic.
In every case I've seen, if Excel is not enough for that user's
application, they need a true programmer to develop it.
Although I believe that special-purpose tools which allow non-programmers
the benefits of a small programming environment are excellent, I also
think that a larger problem today is the dumbing down of the current
generation of programmers. I have met far two many people
- who call themselves database programmers without knowing any relational
- who call themselves computer programmers but do not understand anything
about how computer languages, the operating system, and the hardware
interact. They can only program in Visual Basic, and get totally lost and
confounded for weeks if they hit any irregular issue.
- who call themselves system administrators but only really know how to
download and install patches
The list goes on and on. Current programmers also have no skills in
speaking, listening, writing, or documentation, which means that whenever
new programmers come in, they either have a huge learning curve before
they are useful, or they just have to rewrite large pieces from scratch.
The inability to communicate is affecting program quality to a large
degree, becuase programmers cannot adequately understand, listen, and talk
about the needs and desires of their users in order to make an application
that works well for them.
Finally, programmers today are losing their background in technical areas,
too, and the quality of their tools are suffering. For example,
programmers do not know relational database theory, so database vendors
are producing tools that are further and further from the relational
model, rather than closer to it. Vendors are producing programming
languages like C++ and Visual Basic which are more hindrances to
programming than helps - leaving out fundamental language features like
closures that have been known about for decades.
Anyway, sorry for my rant, but it happens :)
Let me know if you have any other questions. If you need help learning my
Literate Programming toolchain I'd be happy to help. Also, if you are
interested, I'm writing a book on programming called "Programming from the
Ground Up". The current draft is available from
I'm also writing a second book which is about programming languages (it's
essentially a Scheme interpretter written in assembly language in a
literate style - I chose assembly language so that the reader could see
how the low-level constructs combine to create high-level constructs).
The current draft of that is available from my hard drive :)
Let me know if you have any questions!