[lltx] bidi package extended for LuaLaTeX

[Manuel Pégourié-Gonnard]

[quotations re-ordered]

Khaled Hosny a écrit :
> On Fri, Apr 02, 2010 at 11:37:45AM +1100, Vafa Khalighi wrote:
>> 1- Tex macro programming is not a disadvantage, it actually is an art to do
>> macro programming.
> 
> Any one who wrote or maintained a reasonably complex tex macro code
> knows it is pain to write, pain to understand and pain to maintain, the
> main idea behind luatex is to give tex a sane programming language which
> we all know tex mcros isn't.
> 
I tend to disagree with this restrictive vision of LuaTeX. To me, the biggest
advantage of LuaTeX over all other engines is to open up some internals of TeX.
I would have called the project OpenTeX :-) Having a saner programming language
is only the second-biggest advantage to me. (And of course, native support for
Unicode, including math, is also a enormous advantage over pdfTeX.)

By the way, I agree with you that in general Lua is a "better" programming
language than TeX (which wasn't precisely designed as a programming language
btw), but:
- Great things have been done and successfully maintained with TeX. It's a
tricky language, but a lot of tricks are now pretty standard, if you take the
time to read and study code of experienced TeX programmers before starting
writing your own (which is a good idea in any language btw).
- Most experienced programmers agree that the quality of a code depends much
more on the skills of its author than the language it is written in.

Therefore, I quite strongly disagree with your habit of saying "it's written in
TeX, it can't be good, it should be rewritten in Lua". (Ok, I'm quite quick at
calling it an habit, it's only the second occurrence, the first being microtype.)

By the way, concerning the advantages/disavantages of LuaTeX, it's worth noting
that LuaTeX's overall complexity is bigger that other engines, since you need to
understand /both/ TeX and Lua languages in order to be a good LuaTeX programmer.
(Though maybe you don't need to be as good with TeX as previously, you just
can't ignore TeX rules for lexical analysis (catcodes etc) and development.)

>> 2- bidi is not overloaded by TeX macros.
> 
> It is, more than 7000 lines of tex macro to implement such basic thing
> as reversing document layout is a bit overload to me, and one still
> needs to mark rtl or ltr runs explicitly.
> 
Here you're basically telling Vafa that what he did is very basic but that he
nevertheless used a lot of code to do it. Maybe you're thinking that it's TeX's
fault, not Vafa's, but maybe you're implying that Vafa is a bad programmer (I
hope the first option is correct).

>> 3- bidi does not copy codes from other packages verbatim.
> 
> It does, or what all those *-bidi.def files, with thousands of lines
> redefining internal macros of other packages then?
> 
It's not copied verbatim (unless we have different definitions of verbatim), the
whole point is to modify the macros, in order to insert bidi instructions where
they are needed. It implies copying some of the code, and writing in TeX, yes,
but what else do you want to do?

It may displease you, but that's the way things go in the LaTeX world. Most
packages don't anticipate future developments and don't provide hooks for other
packages, so that big fundamental packages such as bidi, tex4ht, hyperref and
others need to redefine other package's internals in order to get the job done.
(Ideally a lot of this should be in the kernel, but it is not and you have to
make things work anyway.) At first glance, the way bidi does this is the most
correct way to do it.

I see it as a big advantage of bidi, from a user's point of view (and users are
more important than programmers), since it means things "just work". Taking care
of this require time and usually quite a lot of user feedback, which is of great
value. Again, this value would probably be lost by rewriting form scratch. This
is why it is almost always a bad idea to rewrite things from scratch, from a
software engineering point of view. (And, mind you, saying "I don't understand
why things are done this way, it looks too complicated to me, and it's not
written in my favourite language, so I'll just rewrite it" is a common mistake
of young software developers.) (You may argue that some engineering paradigms
such as extreme programming suggest frequent rewrite from scratch, but they
require to do it in a way that accumulated experience doesn't get lost in the
process.)

> I were not aware that criticizing the shortcomings of tex macros (that
> everyone knows and admit) and old engines is not showing respect for
> others work. If bidi, xetex and programming in tex was so good, I would
> have saved my self the trouble and just used xetex.
> 
See, you're again implying that bidi is no so good...


Well, to sum up: from a technical point of view, I'm against rewriting from
scratch without a good reason. In general, I think it's best, when something for
XeTeX already exists, to write a "compatibility layer" (such as luaotfload), and
then reuse existing macros (such as fontspec). Don't forget that user interface
and interaction with other packages always take much more lines of code than one
would think (and, unfortunately for you, most of it has to be done in TeX).

Now, from a personnal point of view:

> On Fri, Apr 02, 2010 at 11:37:45AM +1100, Vafa Khalighi wrote:
>> Thanks. Just to answer your insulting email:

I wouldn't call it insulting, but I nevertheless find it offending, and I think
you (Khaled) should try to be more diplomatic in the way you write things,
especially when it comes to the value of other's work. (From a technical point
of view, I think you're underestimating it as I explained, but even if Vafa's
work actually wasn't valuable, a little bit of diplomacy never hurts.)

Manuel.



-- 
To unsubscribe, reply using "remove me" as the subject.