«

Hi.

I've got this problem which may of us could have faced before. I must
first emphasize that I'm not trying to provoke any kind of unnecessary
debates over which language is better.

Let me explain my situation and why I'm trying to move away from Perl
for a particular application I'm developing. I've got an application
that I've built to automate the updating and generation for my
personal web site (text replacement and templating task) and I've
added in features such as incremental build (not re-generating files
that are not modified), automatic organization of files and
contemplating FTP upload feature. Hence it has grown from a 100 lines
script to 700+ lines file. In a way, it has outgrown Perl, which seems
to be getting less suitable for it. Making it object-oriented seems to
be the solution to the overly long and complex program.

But Perl's approach to OO is making the program messy and hard to read
as well, using a lot of arcane manipulation of @ISA and shift and
unshift for methods' parameters, clever but hard-to-read references
for class variables. It's support for OO looks more of clever hack and
a temporary ugly workaround rather than a consistent, clean and
elegant syntax for OO. I know this sounds offensive to Perl fans out
there but just my personal opinion, I may be wrong. Perhaps Perl 6
will address all these but I've yet to go check it up yet.

Not saying that Perl is bad and Python or Ruby is better. Nope that's
not my point. Perl is good for a quick, and short script that you want
to hack up in an hour to do something useful; hence flexibility in its
syntax is its strength. But for larger program which demands code to
be easily comprehensible and clean, Perl's flexibility becomes its
liability.

Therefore, I'm contemplating learning a new language, either Python or
Ruby, which promise cleaner and consistent syntax. So just seeking
opinion from experienced Perl programmers and developers here on which
would be a better choice for an existing Perl programmer and program
and why.

Thanks.

On 2004-11-27, Goh, Yong Kwang scribbled these
curious markings:
> Hi.
>
> I've got this problem which may of us could have faced before. I must
> first emphasize that I'm not trying to provoke any kind of unnecessary
> debates over which language is better.
>
> Let me explain my situation and why I'm trying to move away from Perl
> for a particular application I'm developing. I've got an application
> that I've built to automate the updating and generation for my
> personal web site (text replacement and templating task) and I've
> added in features such as incremental build (not re-generating files
> that are not modified), automatic organization of files and
> contemplating FTP upload feature. Hence it has grown from a 100 lines

man make

(or info make, if you're "blessed" with GNU Make's Texinfo
"documentation")

--
I abhor a system designed for the "user", if that word is a coded
pejorative meaning "stupid and unsophisticated". -- Ken Thompson
Linux: "How rebellious ... in a conformist sort of way."
Unix is user friendly. However, it isn't idiot friendly.

In article < >, Goh, Yong
Kwang <> wrote:

> But Perl's approach to OO is making the program messy and hard to read
> as well, using a lot of arcane manipulation of @ISA and shift and
> unshift for methods' parameters, clever but hard-to-read references
> for class variables.

I don't know what you are doing, but that sounds like a
programmer's problem of style and design.

As for which language to learn next, why not both? You'll find,
however, that each has their own problems, just like Perl has
its problems.

--
brian d foy,
Subscribe to The Perl Review: http://www.theperlreview.com

On 27 Nov 2004 08:13:15 -0800, (Goh, Yong
Kwang) wrote:

>I've got this problem which may of us could have faced before. I must
>first emphasize that I'm not trying to provoke any kind of unnecessary
>debates over which language is better.
[snip]
>But Perl's approach to OO is making the program messy and hard to read
>as well, using a lot of arcane manipulation of @ISA and shift and
>unshift for methods' parameters, clever but hard-to-read references
>for class variables. It's support for OO looks more of clever hack and
>a temporary ugly workaround rather than a consistent, clean and
>elegant syntax for OO. I know this sounds offensive to Perl fans out
>there but just my personal opinion, I may be wrong. Perhaps Perl 6
>will address all these but I've yet to go check it up yet.
[snip]
>not my point. Perl is good for a quick, and short script that you want
>to hack up in an hour to do something useful; hence flexibility in its
>syntax is its strength. But for larger program which demands code to
>be easily comprehensible and clean, Perl's flexibility becomes its
>liability.

Well, that's your *very* humble opinion. As far as you're concerned
just choose the language you'll find most suitable for your needs and
we will continue to be friends as before.

However in the experience of most of us I think that your claims will
sound plainly and definitely false. In other words I'm sure what that
you think to be shortcomings of [Pp]erl for most of us plainly do not
exist, period. So I doubt that we share a common starting basis upon
which we can build any answer that you will find acceptable.

So, in a certain sense, indeed you can avoid an unneccessary and
futile debate about which language is the best, but you can't avoid a
comment about the fact that Perl is perfectly suited for tasks well
beyond quick hacks and short scripts.


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Goh, Yong Kwang wrote:

> contemplating FTP upload feature. Hence it has grown from a 100 lines
> script to 700+ lines file. In a way, it has outgrown Perl, which seems
> to be getting less suitable for it. Making it object-oriented seems to
> be the solution to the overly long and complex program.

OO is a good solution, yes. But, in what way does that preclude the use
of Perl?

> But Perl's approach to OO is making the program messy and hard to read
> as well

Some developers choose to make their code messy and hard to read. Others
choose to make it clear and easy to read. Perl leaves that choice up to you.

> using a lot of arcane manipulation of @ISA

Arcane? "our @ISA=qw(SuperClass);" is "arcane"? News to me...

> and shift and unshift for methods' parameters

Unshift for parameters? That's a new one. If you don't like shift(),
don't use it.

my ($self, $foo, $bar) = @_;

> clever but hard-to-read references for class variables.

Why would you need references to use class variables? They're just
ordinary variables scoped to the package with "our".

Or are you speaking of instance variables? If so, I don't agree - how is
"$self->{foo}" difficult to read? Is it the braces? If so, write an
accessor method and use that instead - "$self->foo". Accessors are a
good idea anyway.

If you don't like writing accessor methods by hand, have a look through
CPAN - there are modules to automate the process.

> It's support for OO looks more of clever hack and
> a temporary ugly workaround rather than a consistent, clean and
> elegant syntax for OO. I know this sounds offensive to Perl fans out
> there but just my personal opinion, I may be wrong.

I don't find it offensive, although I do think you're wrong. You're free
to write consistent, clean, and elegant OO in Perl if you want. If
there's something stopping you from doing so, it's not the language.

> syntax is its strength. But for larger program which demands code to
> be easily comprehensible and clean, Perl's flexibility becomes its
> liability.

I disagree. Perl is perfectly capable of parsing clean, comprehensible
code - the question is whether you are capable of writing such code.

> Therefore, I'm contemplating learning a new language, either Python or
> Ruby, which promise cleaner and consistent syntax. So just seeking
> opinion from experienced Perl programmers and developers here on which
> would be a better choice for an existing Perl programmer and program
> and why.

All of 'em. Seriously, why limit yourself? Learn as many langauges as
you can - the more you know, the better equipped you'll be to choose the
right one for any given task.

If you look at learning new languages as an unpleasant chore, perhaps
you should seriously consider whether you've chosen the right
profession. Keeping your skills up to date and learning new languages is
part of the territory. Programming is a *perfect* example of the "Red
Queen Dilemma" - you have to run as hard as you can, just to stay in the
same place.

One last thing - have a look at Bricolage, at <http://bricolage.cc> for
your content management. It's huge - 'wc -l' on .pm files reports over
164000 lines of Perl, and that's not even counting the dozens of CPAN
modules it uses. You're entitled to your opinion that Perl is unsuitable
for large applications, but it's a fact that people are quite
successfully using it for exactly that.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

In <BLqdnb58Fq2ijjTcRVn-> Sherm Pendley <> writes:

>I disagree. Perl is perfectly capable of parsing clean, comprehensible
>code - the question is whether you are capable of writing such code.

Oh, there's more to it than that. As a Perl programmer I often
have to read other people's Perl code, and I have no control over
how others choose to code. Whoever claims that one can be an
effective Perl program without often having to read other people's
Perl code is just lying. Just yesterday I spent many thankless
hours reading the source of SOAP::Lite, to make up for big holes
in the documentation. Not a fun time. My labmate switched from
Perl to Python because he got tired of reading other people's Perl
code; it had nothing to do with his ability to write clean Perl.

Irrespective of whether it is *possible* to write clean readable
Perl (of course it is), the fact is that Perl is exceptional in
the huge number of ways in which it can be obfuscated. There's
more than one side to TMTOWTDI. On top of that, despite all the
lip service for clear coding, the Perl culture just as often promotes
the opposite, by being very appreciative of cleverly impenetrable
hacks. I learned my first obscure Perl hacks, such as
select((select,$|=1)[0]), from the Camel book and the widely popular
Obfuscated Perl contests. I've seen very little of this sort of
thing in the Python world (I don't know anything about the Ruby
culture).

Karl

--
Sent from a spam-bucket account; I check it once in a blue moon. If
you still want to e-mail me, cut out the extension from my address,
and make the obvious substitutions on what's left.

KKramsch <> wrote:
> In <BLqdnb58Fq2ijjTcRVn-> Sherm Pendley
> <> writes:
>
> >I disagree. Perl is perfectly capable of parsing clean, comprehensible
> >code - the question is whether you are capable of writing such code.
>
> Oh, there's more to it than that. As a Perl programmer I often
> have to read other people's Perl code, and I have no control over
> how others choose to code. Whoever claims that one can be an
> effective Perl program without often having to read other people's
> Perl code is just lying. Just yesterday I spent many thankless
> hours reading the source of SOAP::Lite, to make up for big holes
> in the documentation. Not a fun time. My labmate switched from
> Perl to Python because he got tired of reading other people's Perl
> code;

Does reading other people's Perl code somehow get easier once you start
coding in Python?

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

In <20041127210555.994$> writes:

>KKramsch <> wrote:
>> In <BLqdnb58Fq2ijjTcRVn-> Sherm Pendley
>> <> writes:
>>
>> >I disagree. Perl is perfectly capable of parsing clean, comprehensible
>> >code - the question is whether you are capable of writing such code.
>>
>> Oh, there's more to it than that. As a Perl programmer I often
>> have to read other people's Perl code, and I have no control over
>> how others choose to code. Whoever claims that one can be an
>> effective Perl program without often having to read other people's
>> Perl code is just lying. Just yesterday I spent many thankless
>> hours reading the source of SOAP::Lite, to make up for big holes
>> in the documentation. Not a fun time. My labmate switched from
>> Perl to Python because he got tired of reading other people's Perl
>> code;

>Does reading other people's Perl code somehow get easier once you start
>coding in Python?

No, it's just easier to avoid it.

Karl

--
Sent from a spam-bucket account; I check it once in a blue moon. If
you still want to e-mail me, cut out the extension from my address,
and make the obvious substitutions on what's left.

In <cobb4p$ffj$> KKramsch <> writes:
>select((select,$|=1)[0])

select((select(FH),$|=1)[0]), that is.

Or select+(select(FH),$|=1)[0] if it's Perl golf.

Karl
--
Sent from a spam-bucket account; I check it once in a blue moon. If
you still want to e-mail me, cut out the extension from my address,
and make the obvious substitutions on what's left.

KKramsch wrote:

> Oh, there's more to it than that. As a Perl programmer I often
> have to read other people's Perl code, and I have no control over
> how others choose to code.

What's your point? That's true of any language. The blame lies with the
sloppy coder, not the language he happens to be using.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org