Transiting from Perl: Learn Python or Ruby?

[Goh, Yong Kwang]

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.

 

[Christopher Nehren]

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")

 

[brian d foy]

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.

 

[Michele Dondi]

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

 

[Sherm Pendley]

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--

 

[KKramsch]

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

 

[xhoster]

In <[email protected]> Sherm Pendley


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

 

[KKramsch]

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

 

[KKramsch]

select((select,$|=1)[0])

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

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

Karl

 

[Sherm Pendley]

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--

 

[KKramsch]

KKramsch wrote:

What's your point?

My point is that in my experience, and that of others I know, it
is much easier to run across impenetrable Perl code than impenetrable
Python or C code, say. Perl has a reputation for obscurity, and
this reputation doesn't come out of *nowhere*. The fact that it
is *possible* to write clear code in Perl doesn't negate that
there's an exceptionally large amount of unreadable Perl out there.
One can blame this fact on "bad/sloppy programmers" until the cows
come home, but this won't make it go away. Given that as a programmer
one will have to read the code for the libraries one uses (since
the documentation is often incomplete), it makes sense to stay
clear of a language that has a reputation for obscurity. I personally
like programming in Perl, but I definitely understand the view of
programmers, like my labmate, who can't stand reading other people's
Perl code.

Karl

 

[Tassilo v. Parseval]

Also sprach KKramsch:

My point is that in my experience, and that of others I know, it
is much easier to run across impenetrable Perl code than impenetrable
Python or C code, say. Perl has a reputation for obscurity, and
this reputation doesn't come out of *nowhere*.

It arose from a misunderstanding: People see the syntax of a language
and make judgements based solely on that. What they fail to see is that
syntax is on the surface. The big picture of a piece of software cannot
be grasped by looking locally.

So Python looks appealing to you? Well, learn it, try to understand some
largish projects implemented in Python and come back. Just as Perl (and
certainly any language), it has flaws. As it happens, the Pythonic flaws
can be a real spoiler when it comes to large projects in particular. It
has quite a few inconsistencies, too. This is something that comes as a
surprise to many people learning it because they mostly judged it based
on its cleaner-looking syntax. But that is treacherous and deceptive.

Ruby on the other hand is quite a different beast. With a Perl
background, it's fairly easy to pick up. In many ways it ressembles
Perl. The superficial programmer will see with delight that its syntax
is less intimidating than that of Perl. On the surface, it ressembles
Python, structurally however it's much closer to Perl. In that, it
avoids most of Python's serious shortcomings for
programming-in-the-large.

Stil, best is to have a look at both of them. I am fairly sure that
once you know Perl, Python and Ruby, only two of them will survive. It's
not going to be Python.

Tassilo

 

[KKramsch]

As it happens, the Pythonic flaws
can be a real spoiler when it comes to large projects in particular.
...
[Ruby] avoids most of Python's serious shortcomings for
programming-in-the-large.

What are those shortcomings, in your opinion?

Karl

 

[Ben Morrow]

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.

Fair (of course)

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.

Here, though, I must disagree. I believe it is commonly accepted that
for serious OO stuff perl5 is not really good enough. Hence the emphasis
on it in perl6.

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.

This is also true (of course), but that is not what the OP was saying.

Ben

 

[Big and Blue]

Here, though, I must disagree. I believe it is commonly accepted that
for serious OO stuff perl5 is not really good enough. Hence the emphasis
on it in perl6.

Defined "serious OO" stuff. The object should be to write good code in
a productive manner. Provided you have a decent API then how it is
implemented shouldn't matter. Unfortunately, many APIs don't allow for
future additions - indeed several OO proponents I've met say that it
shouldn't - apparently you're supposed to write a completeley new Object...

So, to me "serious OO" really can be serious - as in "serious mistake".

Note, this reply is nothing to do with Perl, Python, Ruby, (C, FORTRAN...).

 

[Sherm Pendley]

Here, though, I must disagree. I believe it is commonly accepted that
for serious OO stuff perl5 is not really good enough.

That might be commonly accepted among Java or Smalltalk enthusiasts, but
people write "serious OO" in Perl every day. I know I do.

For example, it's true that Perl doesn't *force* you to respect strict
encapsulation in your code. But the real question is, why should it?
Can't a good programmer respect encapsulation on his own, without being
forced to do so by language restrictions?

Having said that, there's no way I'd use Perl to *teach* OO concepts.
Beginners generally do need a stricter language that enforces good
practices, at least until they have enough experience to do so on their own.

sherm--

 

[ChrisO]

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.

Some have already commented that this is not a problem with Perl but a
problem related to style and initial development. It sounds a lot like
a refactoring issue to me, which I'll admit isn't always as easy to do
in Perl as I would like at times. But then again, from looks of 90% of
the Perl code I see, I'd say it's not usually Perl; it's the programmer
trying to use it (most of the present company excluded since most
posting here are pretty decent Perl coders, IMO.) In most languages,
any future refactoring effort is certainly affected by the design and
implementation of initial effort. But your issue sounds like a
refactoring issue since you're initial effort has grown to 7x its
original size.

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.

It's not "offensive" and I'll be the first to admit Perl's OO approach
is a bit "forced." But again, I've seen plenty of so called "Perl OO
code" that could have been written much better within the confines of
Perl itself, my own code included.

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.

A while back, I contemplated making a shift to Ruby and asked a question
concerning moving from Perl to Ruby over in comp.lang.ruby and got a
very insightful thread going:

http://groups.google.com/groups?hl=...24Qv5.529%40newssvr33.news.prodigy.com&rnum=4

I think you'll find that Ruby refactors much more nicely and quickly
than Perl and I consider it an excellent choice for Perl replacement.
My one lone stike against Ruby is still that I can code in Perl much
quicker, even in OO, than I can in Ruby (which is *entirely* OO -- you
don't have a choice), and I just can't afford to take the time to get as
up-to-speed in Ruby as I am in Perl. (Time is $$$.) But Ruby is an
incredible language, esp. for what you say you need to accomplish. I
can't say that it's better than Python because I know very little about
Python (I've probably written a total of 100 lines of Python ever). But
from the feedback I've gotten (esp. in the thread above), I'd give Ruby
the nod over Python; it's really super nice.

--ceo