On Mon, 1 Sep 2003, Sameer D. Sahasrabuddhe wrote:
Would it be necessary to get into TeX? Perl is
too powerful to not be
able to generate PDF or postscript directly ... at least PHP is known
The PDF modules available for perl are decent, but require some work.
Colours and stuff aren't easily handled.
I also feel more comfortable with that intermediate stage of TeX,
because it allows me to debug Perl code which generates the report, by
just looking at the generated TeX.
If I use a Perl module which generates direct PDF, I'd feel helpless if
the PDF doesn't display right; PDF is all bits-and-bytes. If the module
generates PostScript (and if I know PostScript), then I can always look
at the generated Postscript _source_ if it doesn't display right in the
viewer. Same's the case with TeX. Therefore, from the debugging point
of view, I'd feel much more comfortable if something generates TeX/
HTML/ Postscript instead of PDF.
(An aside: how many times have we had to ask "cc" to generate assembly,
and then look through the assembly code, to debug illogical behaviour
in our code? I have, more than once. This thing about TeX versus PDF
is from that can't-trust-the-compiler mindset.)
One more reason to prefer text-based formatted output file types is
because I can write my code to use text-files containing templates. When
I generate HTML screens from my Perl/CGI programs, for instance, I keep
the entire HTML page layout in text files, with placeholders, like this:
<TITLE>__FULLNAME__ is not getting any younger</TITLE>
<H1>Age of __FULLNAME__</H1>
<P>The current age of __FULLNAME__ as per our records
is __AGEYEARS__ years. Have a nice day!</P>
When I need to show the page, I read the template file, replace the tags
(between the "__" strings) with actual values and then send the page
to the user. We have an ancient, simple Perl function which takes a
hashmap of attribute-value pairs and patches a template. This is possible
with TeX and HTML, and if I use ultra-simple Postscript (e.g. the kind
generated using XFig and transfig) is possible with Postscript too. But
I don't know how to do this using any binary format like PDF. Taking
this template-based approach allows me to make small changes to the
screen appearance using just a _text_editor_ without editing code, thus
making the code more robust. (I believe this template-patching under
programmatic control can be done on Windows with MS Word documents,
if I work with VBA. Can anyone confirm or deny this?)
In our company, share certificates are generated by printing Postscript
files generated by a Perl program. :) This Perl program takes a table
with one line per share certificate, and patches a Postscript template
which was created using XFig. All certificates issued till date have
been done this way. More recently, every Form 16 or Form 16A issued
by our Accounts Dept is done through a Perl program which patches an
XFig-generated Postscript template.
And talking about enterprise class applications being doable or not
doable in Perl, I feel Perl's quite okay even for scaling up. J2EE gives
facilities (particularly the application management facilities in the
high-end commercial application servers) which I don't think any Perl
execution environment provides. That apart, there are lots of cases of
really large Perl applications which form the core bread-and-butter of an
entire company's business. When it comes to performance for Web apps, I
feel that an array of web application servers running Apache and mod_perl,
all talking to a common (set of?) database server(s) at the back-end,
can scale up as much as practically any other technology.
One place where J2EE wins is if you need long-running classes,
e.g. daemons holding object instances with frequently-changing state,
running for a long time (e.g. hours), servicing requests from other
components. This sort of thing is done very naturally in J2EE but seems
difficult in mod_perl. Any pointers to Perl-based long-running "object
servers"? I'd like to know... If I had to do this in mod_perl with
my current knowledge, I guess I'd just write the data for each object
instance to a database table every time, incurring a performance hit.
I know of one company which is in the business of gathering, analysing
and publishing data reports, which uses Unix/Linux, Perl, and TeX to
automatically generate thousands of pages of formatted text every month.
This setup has been working for years, and has taken the continuous
modifications and extensions that are a part of life with critical
Without commenting on J2EE, I just wanted to say that I believe Perl
delivers on large enterprise-class applications excellently. Even if
I keep aside the seven-year track record of mission-critical work in
Perl done by Starcom (where I work), just this company's case would be
testimonial enough for me. Incidentally, this company evaluated Java
carefully over a period of time for some GUI apps they have developed on
MS Windows, and decided that MS VC++ and MFC was much better than Java.
I don't know the details.