performance comparison

[Lothar Scholz]

Hello Mikael,

MB> Conjuring into existance two different worlds and putting your opponent
MB> in the unworthy one is a very clever trick. Actually, the phrase ``real
MB> world'' has nearly become an argument in itself. You can use it to
MB> disqualify anything. How convenient!

Excuse me but there are two worlds. Denying this means to ignore
facts.

This is because TeX is from the other world. Written out of pure
interest by one person to satisfy his needs. Without any pressure of
time or money. And after it could do what Knuth wanted it was frozen
and never modified again (only bug fixes). And it is a pure
algorithm driven program [Input] --> [Output] (aka Compiler), very easy
to write and much different from what i see in any real large programs.

And it is not a large program.

LaTeX has thousands of other tools that were created to work around the
problems and bad design errors (useability) in TeX. So if you talk
about TeX in real word you must say LaTeX and then you enter a different
world.

I think this are some facts you missed.

And by the way, Knuth has written the bible because he was simply the
first one. Not more and not less. The fourth part of the bible is not
really amazing and there is nothing really new in it.

 

[Robert Klemme]

People are still using TeX, more than 20 years after it was written. I
find that pretty amazing for a user-program. If it doesn't qualify as a
real world project then I don't know what does.

Right so. And it can be easily verified in every bookstore that has but the
barest minimum of science litertature - especially Math and CS. You'll find
a lot books made with TeX there.

Maybe we should be very grateful that Knuth isn't writing what you
call "real world programs".

btw: Kristof, are you located in Leuven, Belgium? That's a really nice
town! Lovely bars, strong beer and the marvellous "Couvert Couvert".
Mmmmh...

Kind regards

robert

 

[Lothar Scholz]

Hello Robert,



RK> Right so. And it can be easily verified in every bookstore that has but the
RK> barest minimum of science litertature - especially Math and CS. You'll find
RK> a lot books made with TeX there.

Once again, i don't know anybody working with TeX. And i don't know
any book in the last years that where published about TeX.

All goes into LaTex, TeTex etc. and the reasons are that TeX is really
only an outdated type setting kernel. LaTex is developed very
differently.

But nobody in this thread seems to be interested in precise wording
and so the basic math rule applies: "false" implies "true".

 

[Kristof Bastiaensen]

btw: Kristof, are you located in Leuven, Belgium? That's a really nice
town! Lovely bars, strong beer and the marvellous "Couvert Couvert".
Mmmmh...

It is, isn't it? But no, I am from Antwerp, which is a very
nice town too (beer, restaurants, ...)

Kind regards

robert

Regards,
KB

 

[David A. Black]

Hi --

Hello Robert,




RK> Right so. And it can be easily verified in every bookstore that has but the
RK> barest minimum of science litertature - especially Math and CS. You'll find
RK> a lot books made with TeX there.

Once again, i don't know anybody working with TeX. And i don't know
any book in the last years that where published about TeX.

All goes into LaTex, TeTex etc. and the reasons are that TeX is really
only an outdated type setting kernel. LaTex is developed very
differently.

Sorry to dwell on the OT stuff, but I'd like to clarify this a little.

teTeX is a TeX distribution. LaTeX is a package of macros written in
TeX. I don't think teTeX is relevant here; you can't blame people who
want to use software for packaging and distributing it

As for LaTeX: much of the point and power of TeX is that you can write
macros in it. Knuth has done some; other people have done some,
including Leslie Lamport, the creator of LaTeX. Macros are what TeX
is for; they're not something people have come up with as a workaround
for the low-levelness of TeX. LaTeX is a large and popular set of
macros. It's not a fork of TeX. A better way to view it is that it's
a TeX application.

When you use LaTeX, you are using TeX. There is nothing more "real"
about using TeX without macros -- in fact, I don't think it's possible
to get much done that way. (I suppose you could inline everything,
but that was never the goal of TeX.)

(I believe the Pickaxe was prepared in LaTeX, so maybe it's not 100%
off-topic


David

 

[Lothar Scholz]

Hello David,


DAB> teTeX is a TeX distribution. LaTeX is a package of macros written in
DAB> TeX. I don't think teTeX is relevant here; you can't blame people who
DAB> want to use software for packaging and distributing it

Sorry you missunderstand something. I don't blame anyone. I'm just
building and defending a chain or arguments to prove my opinion
against a so called general purpose programming process theory
- literate programming.

DAB> When you use LaTeX, you are using TeX. There is nothing more "real"
DAB> about using TeX without macros -- in fact, I don't think it's possible
DAB> to get much done that way. (I suppose you could inline everything,
DAB> but that was never the goal of TeX.)

I know this. But the question was is TeX still under development.
Maybe i'm wrong but i doubt this. The many many macro packages out
there are under heavy development. Sure. But are whey written not only
Tex but also CWeb applications ?

We were talking in this thread (a long time ago) about the argument if
TeX is a valid example that the literate programming process works, or
better is able to be maintained in programs that change.
I doubt that, others told me that TeX is an "real world" example.

From the version numbering (how close is the version number now
compared to the euler number ?) i simply don't think that TeX is
developed anymore. Are still feature added ? Again to the core, not to
the 3rd party programs or macro packages.

And so my argument is that this is not valid example that the literate
programming modell works.

But i think everybody simply lost interest in the original question.

 

[David A. Black]

Hi --

Hello David,


DAB> teTeX is a TeX distribution. LaTeX is a package of macros written in
DAB> TeX. I don't think teTeX is relevant here; you can't blame people who
DAB> want to use software for packaging and distributing it

Sorry you missunderstand something. I don't blame anyone. I'm just
building and defending a chain or arguments to prove my opinion
against a so called general purpose programming process theory
- literate programming.

DAB> When you use LaTeX, you are using TeX. There is nothing more "real"
DAB> about using TeX without macros -- in fact, I don't think it's possible
DAB> to get much done that way. (I suppose you could inline everything,
DAB> but that was never the goal of TeX.)

I know this. But the question was is TeX still under development.
Maybe i'm wrong but i doubt this. The many many macro packages out
there are under heavy development. Sure. But are whey written not only
Tex but also CWeb applications ?

We were talking in this thread (a long time ago) about the argument if
TeX is a valid example that the literate programming process works, or
better is able to be maintained in programs that change.
I doubt that, others told me that TeX is an "real world" example.

From the version numbering (how close is the version number now
compared to the euler number ?) i simply don't think that TeX is
developed anymore. Are still feature added ? Again to the core, not to
the 3rd party programs or macro packages.

TeX isn't developed any more; that's official. It's interesting that
you view that as a sign of failure I think it just means that
the program does what Knuth wants it to do -- not a concept we
encounter much, but it's certainly plausible. It doesn't mean that
TeX is perfect, or that it will please everyone. But of course no
program, even those with completely open-ended development, every
pleases everyone.

And so my argument is that this is not valid example that the literate
programming modell works.

Using TeX certainly does not mean you're using the literate
programming model (in case it sounded like I meant that, given the
context). But the success of TeX certainly means that a program
written using that model (i.e., TeX itself) can be successful.
Literate programming itself doesn't seem to have caught on very much,
at least in the circles I move in. I've never studied it deeply
enough to analyze it further.


David

 

[Robert Nesius]

Once again, i don't know anybody working with TeX. And i don't know
any book in the last years that where published about TeX.

Every book published with LaTeX is published with TeX. It is not
hard to push the limits of LaTeX. Everyone I know who has done
serious work in LaTeX has had to resort to using some other macro
packages, and quite often, raw-TeX, to get parts of the job done. For
straight-forward things, LaTeX rocks. But if you don't like
the decisions it makes, it can be really hard to get it to change.
Probably because the whole paradigm is that you are not supposed
to care how it looks. Rather, you should trust the computer, er,
LaTeX. LaTeX is your friend.

As for your future comments about literate programming, no development,
etc... with respect I have to say I'm not sure I get the point.
TeX, as another reader pointed out, really does do what it is supposed
to do. All of the core typesetting functionality is there. TeX
is like Xlib in the X11 libraries. LaTeX is like the X Intrisics.
I'd rather use the intrisics, but when necessary I can go
to the raw Xlib.

X11 is still under development, but it's final display output and
hardware is constantly changing, whereas 8x11" sheets of paper
have been consistent for quite awhile.

-Rob

 

[Mark Probert]

Hi, Lothar.

And so my argument is that this is not valid example that the literate
programming modell works.

Backing up a little, and leaving the words "literate programming" aside.

As a coder, I assume that you use comments in your real-world code. As
an experienced real-world coder, who has done some maintenance work, you
would also have come to appreciate the value of other peoples' comments.
Often the more the better, particularly in those "optimised" sections.

I also assume that you have discovered that if you use RDoc or Doxygen or
similar, you can have comments in your code formatted nicely. You
produce your detailed implementation documentation as you go. It save
you a lot of time in the long run, avoids having to go back and work out
what you did when it was time to document your code at code review time.
The reviewers are happy. Your fellow coders are happy. Managment is
happy because they realise that your production code will be supportable
from India. You get the idea.

So, where do you think this "code + documentation = Good", comes from?
Does it help to reduce maintenance costs? My experience says yes.
Empirical evidence seems to support that conclusion as well. Is it
taught in universities etc.? No. Does it make "real world" sense? Yep.
Is it used within my organisation? No. Should it be? Yes. How come?
'Cause coders, code, they don't write documentation. 'Cause, on the
whole, those writing the code don't have to maintain it.

"A rose by any other name ..."

Regards,

 

[Charles Mills]

Hi, Lothar.


Backing up a little, and leaving the words "literate programming"
aside.

As a coder, I assume that you use comments in your real-world code. As
an experienced real-world coder, who has done some maintenance work,
you
would also have come to appreciate the value of other peoples'
comments.
Often the more the better, particularly in those "optimised" sections.

I also assume that you have discovered that if you use RDoc or Doxygen
or
similar, you can have comments in your code formatted nicely. You
produce your detailed implementation documentation as you go. It save
you a lot of time in the long run, avoids having to go back and work
out
what you did when it was time to document your code at code review
time.
The reviewers are happy. Your fellow coders are happy. Managment is
happy because they realise that your production code will be
supportable
from India. You get the idea.

So, where do you think this "code + documentation = Good", comes from?
Does it help to reduce maintenance costs? My experience says yes.
Empirical evidence seems to support that conclusion as well. Is it
taught in universities etc.? No. Does it make "real world" sense?
Yep.
Is it used within my organisation? No. Should it be? Yes. How come?
'Cause coders, code, they don't write documentation. 'Cause, on the
whole, those writing the code don't have to maintain it.

Seems like Lothar is doing most of his coding in Eiffel which uses
Design by Contract. IMHO contracts generally provide good
documentation and as a bonus the coder writes the contract. Also
contracts are check at runtime - so they stay current, which means the
docs stay current (if they are generated from the contracts/code).
-Charlie

 

[Lothar Scholz]

Hello Charles,

In my university i got a lot of courses where
this was taught with many different modells, most of them UML and Z (a
specification language).

I agree. But i think very often they also have to maintain it.

CM> Seems like Lothar is doing most of his coding in Eiffel which uses
CM> Design by Contract. IMHO contracts generally provide good
CM> documentation and as a bonus the coder writes the contract. Also
CM> contracts are check at runtime - so they stay current, which means the
CM> docs stay current (if they are generated from the contracts/code).
CM> -Charlie

Write the only technique that guarantees to stay in sync with the
code.

And one word to the API /Doxygen documentation: Yes this is used
intensively in some companies but it still becomes very hard to
maintain if people use it not for the static but the dynamic modell.
I mean message flow, algorithms etc. This changes much more then most
API functions. I found that it is almost impossible to keep the
documentation for this up to date. I'm also only writting UML class
diagrams and never Sequence/Collaboration Diagrams etc.

So instead of writing embedded documentation people should write
better code: using long identifier names, avoid 10 times nested
loops, use small methods and no tricks to save a few keystrokes.

 

[Mark Probert]

Hi, Lothar.

So instead of writing embedded documentation people should write
better code: using long identifier names, avoid 10 times nested
loops, use small methods and no tricks to save a few keystrokes.

Another option is to use generators.

For more, check out Jack Herrington's excellent "Code Generation in
Action", published by Manning. The examples are in Ruby and Java (so we
real-world and back on topic

 

[Tom Copeland]

Hi, Lothar.


Another option is to use generators.

For more, check out Jack Herrington's excellent "Code Generation in
Action", published by Manning. The examples are in Ruby and Java (so we
real-world and back on topic

Yup, and he's got his code generation framework on RubyForge:

http://rubyforge.org/projects/rna/

Good times...

Tom

 

[Alexey Verkhovsky]

Mauricio, good day!

There was a new release of Test::Unit::Reporter. It is available from
http://rubyforge.org/projects/test-report/

Best regards,
Alex

 

[Alexey Verkhovsky]

Mauricio, good day!

Oops, wrong "Reply To". Sorry, list.

 

[vruz]

Mauricio, good day!

Oops, wrong "Reply To". Sorry, list.

too funny,
I had it installed from RPA before your post showed up in the ML

 

[Mauricio Fernández]

Mauricio, good day!

There was a new release of Test::Unit::Reporter. It is available from
http://rubyforge.org/projects/test-report/

Thank you for reporting the new release.
Funnily enough, I uploaded test-report 0.3.0-1 just before reading your
message, along with copland 0.8.0-1, copland-lib 0.1.0-1, copland-remote 0.1.0-1,
copland-webrick 0.1.0-1, hobix 0.3.0-3 (kudos to Paul van Tilburg for
fixing several issues that are yet to be solved upstream) and some
others I can't remember atm.

You can install them with the recently released rpa-base 0.2.2-1
available at http://rpa-base.rubyforge.org