h2ph does what it does, & that's about the only definition you can count
on <frown> -- generally does a reasonable translation of #if[def],
#define of literal constants, & #define of simple macros. Nearly
everything else (structs, typedefs, declarations, non-trivial macros, is
...) ignored, or mis-translated into Perl that would blow up if it
were invoked. Provided you don't expect much from it, it's very useful
for getting at the simple stuff. It would be easy to whip up something
comparable for Python, but one of the secret pitfalls of using a
stronger language is that you're not inclined to settle for doing as
limited a job <0.7 grin>.
> ... *Tim* : As a beginner in both languages, I can assert that the
> PYTHON version is MUCH more readable - you are obviously blinded by
> your experience with Perl!
Sorry, Steve, I did a poor job of writing there. I fully agree that
Python is both much easier to learn & much easier to read than (typical)
Perl (just "typical" because you don't *have* to use Perl's bottomless
bag of hidden tricks -- think it's quite possible to write Perl that's
as readable as C, it's just that nobody does ...).
I claimed that my program was as hard to *"understand"* as the Perl
version, and understanding covers much more than readability. I think
two things conspire to make the Python version hard to understand:
1) Felix was disingenuous in calling the problem "very simple" -- it's
quite involved when you get into the details, and is prone to subtle
bugs (e.g., the Perl version had several bugs; if you give Guido's
version more than one directory, it may not sort them correctly at
the *topmost* level; & I'm not admitting to the bugs in my version
<grin>). So much of the "hard to understand" comes from the problem
itself. And it may not be apparent from looking at a solution, but
Python has a strong advantage here in that it supports the kinds
of data types that more-or-less naturally spring to mind; but that's
an advantage for the progammer more than it is for the reader. Which
leads to ...
2) In my experience, it takes a lot of time for sometime to get
comfortable with reading code that uses recursive data types in a
language without declarations & in programs that don't document what
the data types are. The Perl version was hideously obscure because
you just can't tell what "*kid" is being used for without
understanding the logic completely first; the Python versions were
similarly obscure (Guido's version was certainly better than mine in
this respect) in using data types that weren't *obvious* from the
text. You really have to dig into the logic to figure out the
precise inner structure of the various incestuous lists, tuples &
dictionaries. I figure the best solution to that is good comments,
but you can't do that in this example without making it *look* much
bigger than the (uncommented) Perl version <0.9 grin>.
> ... [skipping over pack/unpack] ...
> The other thing I believe Perl has, is more elaborate output
> formatting & report generation capabilities. But I haven't
> actually ever got that far in my Perl programming, so I'm
> taking that rumour at face value.
Perl started life as a report-generating language, & has a very nice
"format" feature (+ lots of associated hair) to support that function
(in essence, you draw a picture of what you want the report to look
like, & Perl takes care of justification & centering & rounding etc the
data to match the picture).
Perl has many features "like that": unusual hacks that most people never
use but some people use very heavily. Transparent binding of dbm files
to associative arrays is another of that ilk; for that matter, so are
pack/unpack; the dataflow mechanisms for tracking "unsafe" data derived
from the environment is another; ... Perl simply can't be beat for short
programs that rely on one of those built-in pieces of magic.
seeing-python's-strengths-as-being-overwhelming-but-in-different-areas-ly
y'rs - tim
Tim Peters Kendall Square Research Corp
tim@ksr.com, ksr!tim@uunet.uu.net