axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Re: Literate Clojure - a good lead ...


From: Tim Daly
Subject: [Axiom-developer] Re: Literate Clojure - a good lead ...
Date: Wed, 21 Jul 2010 22:37:28 -0400
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)



Antony Blakey wrote:
On 22/07/2010, at 3:08 AM, Tim Daly wrote:

"Language integration" is a false goal. It is technically possible to
call functions in any language from latex but unnecessary in general.
It is technically possible to generate latex from any language.

Have you read the paper? Being able to automatically embed the output of 
examples is a big win IMO.
Yes, I read the paper. You can call external routines to generate output into latex
in many systems and languages. There are many such examples:

Here you can create live 3D rendering in a pdf using latex:
http://meshlabstuff.blogspot.com/2009/03/creating-interactive-3d-objects-inside.html

Here you can render images into latex
http://www.mayer.dial.pipex.com/tex.htm

Here you can create latex from javascript:
http://code.google.com/p/jstexrender/

PDF with animations from latex:
http://www.uoregon.edu/~noeckel/PDFmovie.html

Automatic latex generation from Maple:
http://www.math.tamu.edu/~boas/courses/math696/converting-Maple-code-into-LaTeX.html

And, of course, the Haskell-in-Latex:
http://yav.purely-functional.net/haskell_latex.html

I have dozens more, since I tend to collect them. Axiom can even
generate latex (or fortran or mathml or html) automatically.
The technology isn't the point, though.

The point is that you're writing a document that happens to include code.

If you were going to write a PROGRAM you wouldn't start with latex as the
primary tool even though it is turing complete and can implement scheme.
Since the GOAL of literate programming is to write a DOCUMENT,
the primary tool is one that is designed to express documents.

I would love to see Clojure embrace literate programming. I believe that
a book that explained all of the details of why Clojure chose agents, refs,
immutable data structures, the Java integration strategy and the constraints
it imposes, the choice of lazy functions, the REPL, the AOT techniques,
the use of time and state and many other choices would make most of the
questions/comments/debates on this list pointless. People could just read
a chapter on fast-arithmetic and see the choices made. And, oh-by-the-way,
the code to implement those choices is in the book.

It would also make it easier to see when and why changes need to be made
to keep up with technology. The 32 element tree structure is almost certainly
a function of todays cache-line sizes. What happens when the technology
moves to light-busses and the cache-line is now 4k? Will it be meaningful
to have a 4k-per-level tree structure? What are the tradeoffs and why were
they made? Rich knows.

Instead we will continue to have a stream of people who are learning Clojure
being taught "in an oral tradition" by helpful people on the mailing list. And we will have limited opportunity to contribute to the core code because there is a
very steep learning curve to swallow all of that code when you have to guess
what the design decisions were. It is a modern day version of the pre-printing
press, medieval guild-worker technology.

Clojure is moving away from the "old lisp way" of doing things but it is
continuing the tradition of "tiny-little-files-in-a-file-system hierarchy" from
the PDP-11/40 4k-max-file-size C programming days with make-ant-lein,
stuff-on-the-path, 60s unix techniques and mindset.

Literate programming would put it all into a book and let the machine
handle the details without the programmer knowing or caring. The book
is completely unconstrained in size since you would never print it. The
namespace issue disappears since you can simply use (hidden) section
names automatically. Tutorials become test cases as well as an
opportunity to show detailed examples. References to published papers
to support the design choices would be "expected", as in any professional
piece of technical writing.

The real benefit is in the long term. Clojure could be read and taught
without pain to a whole new generation without the original authors.
It is like Clojure discovered the printing press.

Tim Daly




reply via email to

[Prev in Thread] Current Thread [Next in Thread]