It is clear that developers do not want to be reading their
source code from a dvi viewer, two steps removed from the problem on
which they are focused.
Huh? I am sure, you have not used ALLPROSE. Your code is only one click
away.
I dont do that myself. I write my code as most other programmers do.
Because you are trained in programming. But what you do is writing the
program for yourself. Not for other people.
Well, that is fine. I think I also do that to a great deal. But if I
write mathematical code, it is quite useful that I can see the formulas
in .dvi and have the code very close to it. I am not good at writing
ascii art and always putting something like ++ in front of a line is
painful.
Anyway, write your code as you like, nobody is forcing. The only thing
is that one should not forget that LP is not about documenting a
program. It is about documenting an idea where the documentation is
equipped with real code. Human understandable, of course. If that is the
final product that you give to the public nobody cares how it was
produced. I have not yet heard of someone who has good guidelines of how
to produce a nice literate document.
Additionally, one should also distinguish at least 3 cases.
1) An idea was already published together with pseudo code.
2) The idea is developed and at the same time coded (i.e. it is
relatively clear how to put it into a programming language.)
3) The idea might be clear but the design in the actual programming
language is not. It might be that the programming language does
not allow certain constructs that one has in mind. So there is some
time to experiment with the programming language first until one can
put a report on the different attempts into a nice pamphlet.
For 1) it should be better to start immediately with the text and just
turn the pseudo code into actual code. There might be some restructuring
necessary, but it is certainly the easiest task of the three.
I think 2) should be the future way of writing papers that describe
algorithms. Instead of pseudo code there should be a high-level language
that can be used instead of pseudo code. And LP helps here quite a lot.
Case 3) is something that appeared several times to me. We currently
face that in Aldor-Combinat. The theory is clear, it is written in a
book, but how this is translated into Aldor is totally unclear. There
are some ideas, but it seems for the ideal version, the Aldor language
is simply too weak. But to find that out I have to do some experiments
with the language. Sure, I do them without the pamphlet burden, but in
my case (ie with ALLPROSE) that only means that my code chunks are huge
and unstructured (similar to current Axiom). In the end I might throw
away a lot of code, but at least I should have an account of what has
been tried out and what turned out to be bad and why. For future
developers that might be important (even the bad and stupid code) so
they safe time in not trying again the wrong route. Or they see that I
falsely classified something as the wrong route. I'm not perfect.
Ralf
_______________________________________________
Axiom-developer mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/axiom-developer
