Need arguments for "Python vs. Perl as an OOPL"

[Roy Smith]

I'm working on a prototype of a new application in Python. At some
point, if this ever turns into a product, the powers that be will almost
certainly demand that it be done in Perl. My job will be to convince
them otherwise.

The basic design of the application is object oriented. I've never used
Perl's OO features, so I'm not in a good position to make a comparison
of the two languages from an OO point of view. Can somebody who's done
OOP in both Python and Perl help me out?

I certainly know why Perl sucks in general, but for this purpose, I need
to specifically compare the OO features of the two. I'm looking for
something more fundamental than "->{} is ugly".

[Raymond Hettinger]

"Roy Smith" <ro*@panix.com> wrote in message
news:ro***********************@reader2.panix.com.. .

I'm working on a prototype of a new application in Python. At some
point, if this ever turns into a product, the powers that be will almost
certainly demand that it be done in Perl. My job will be to convince
them otherwise.

The basic design of the application is object oriented. I've never used
Perl's OO features, so I'm not in a good position to make a comparison
of the two languages from an OO point of view. Can somebody who's done
OOP in both Python and Perl help me out?

I certainly know why Perl sucks in general, but for this purpose, I need
to specifically compare the OO features of the two. I'm looking for
something more fundamental than "->{} is ugly".

If you're to find a major difference in OO implementations, it will likely
be with Python's new style classes. So, the advantages are:

* easy implementation of metaclasses through __metaclass__
* super() for cooperative superclasses
* a method resolution order that supports cooperative superclasses
and complex inheritance hierarchies
* __slots__ for lightweight instances
* o.__getattribute__ for easy intercepts of method calls and attribute lookup
* descriptors which make easy work of otherwise hard tasks
* the fruits of descriptors: class methods, static methods, and properties
(which make it possible to avoid coding many getters and setters).

Other than the new-style gizmos, it's mostly the same candy in a different
wrapper.
Raymond Hettinger

[Chris Stromberger]

On Mon, 22 Sep 2003 23:24:21 -0400, Roy Smith <ro*@panix.com> wrote:

I'm working on a prototype of a new application in Python. At some
point, if this ever turns into a product, the powers that be will almost
certainly demand that it be done in Perl. My job will be to convince
them otherwise.

The basic design of the application is object oriented. I've never used
Perl's OO features, so I'm not in a good position to make a comparison
of the two languages from an OO point of view. Can somebody who's done
OOP in both Python and Perl help me out?

I certainly know why Perl sucks in general, but for this purpose, I need
to specifically compare the OO features of the two. I'm looking for
something more fundamental than "->{} is ugly".

Perl classes: unintuitive, hard to learn, IS ugly! Good luck. I work
in a Perl shop. Only a few of us are on to Python. Cannot seem to
break through to the Perl Zombies.

http://www.strombergers.com/python/p...erl_class.html
http://www.strombergers.com/python/p...heritance.html

[Peter Hansen]

Roy Smith wrote:

I'm working on a prototype of a new application in Python. At some
point, if this ever turns into a product, the powers that be will almost
certainly demand that it be done in Perl. My job will be to convince
them otherwise.

Do you need to convince them now, to allow you to continue working on it
in Python, or are you just preparing for the time when they will come and
ask for it to be done in Perl?

I ask because I suspect the best way of convincing them will be to do
nothing, and stand back watching as your Python prototype continues to
work without problems, while those attempting to rewrite it in Perl
waste a lot of time and never get it quite working... and even if they
do, just print out a couple of pages from both and show them to the
"powers that be" and that ought to do the trick.

Unless they are wholly uninterested in readability and maintainability. :-(

-Peter

[Roy Smith]

Peter Hansen <pe***@engcorp.com> wrote:

Roy Smith wrote:

I'm working on a prototype of a new application in Python. At some
point, if this ever turns into a product, the powers that be will almost
certainly demand that it be done in Perl. My job will be to convince
them otherwise.

Do you need to convince them now, to allow you to continue working on it
in Python, or are you just preparing for the time when they will come and
ask for it to be done in Perl?

The latter. It's currently a bit of a skunk works project. At some
point, when the time comes to actually allocate resources to this, some
PHB will undoubtedly declare that it has to be done in Perl. At that
point, I'll need to be able to argue coherently why that's a bad idea.

[Bob Gailer]

At 09:24 PM 9/22/2003, Roy Smith wrote:

I'm working on a prototype of a new application in Python. At some
point, if this ever turns into a product, the powers that be will almost
certainly demand that it be done in Perl. My job will be to convince
them otherwise.

So you may need to understand the factors that the powers use to make such
a decision.
If they are not themselves programmers, they may have a harder time
understanding language differences.
Are they concerned that there will be other Python programmers available?
Consider asking them on what bases they make these decisions (what needs of
their's are they meeting by sticking with Perl). Then see if there is a way
that choosing Python will help meet these needs also or better.
Also be on the alert whether they are acting from a rational place or an
emotional one. Realize that management usually has to make decisions based
on incomplete data (for that matter so do we), so there's worry, fear, etc
operating.
When management gets that you understand their needs, then you are in a
better position to have your needs and desires heard.

For more on this approach visit www.cnvc.org (Center for Non-Violent
Communication)
[snip]

Bob Gailer
bg*****@alum.rpi.edu
303 442 2625
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.506 / Virus Database: 303 - Release Date: 8/1/2003

[Matthew Wilson]

I suggest that you write that python prototype and don't worry about the
python-vs-perl debate. Python vs. perl is a false dilemma and a waste of
energy. In my experience, converting a well-written, well-documented
python program to perl is fairly straightforward, especially if you've got
people that are familiar with both languages. The hard part (for me) is
figuring out the functions/classes/algorithms that will solve the puzzle.
Once that's done, you should be able to convert your app to perl, C, java,
etc, given enough time.

In general, I tend to think of python and perl (and any language really)
as different systems of shorthand/markup for my pseudocode. I like python
because I got tired of writing stuff like this:

foreach my $x (@{$hashref->{'arr'}} ) { ... } #too many non-word characters!

Furthermore, dealing with subroutine parameters in perl isn't nearly as
pretty as python, IMHO. But in general, my brain works on puzzles in the
same way (very slowly), regardless of which language I'm using.

Anyway, a completely different strategy to take, if you feel like being
snarky, is to mention how parrot will interpret perl and python, so in a
way, your python is already written in perl 6.

Roy Smith wrote:

I'm working on a prototype of a new application in Python. At some
point, if this ever turns into a product, the powers that be will almost
certainly demand that it be done in Perl. My job will be to convince
them otherwise.

Do you need to convince them now, to allow you to continue working on it
in Python, or are you just preparing for the time when they will come and
ask for it to be done in Perl?

I ask because I suspect the best way of convincing them will be to do
nothing, and stand back watching as your Python prototype continues to
work without problems, while those attempting to rewrite it in Perl
waste a lot of time and never get it quite working... and even if they
do, just print out a couple of pages from both and show them to the
"powers that be" and that ought to do the trick.

Unless they are wholly uninterested in readability and maintainability.
:-(

-Peter
--
http://mail.python.org/mailman/listinfo/python-list

[Tom Anderson]

On Tue, 23 Sep 2003, Roy Smith wrote:

Peter Hansen <pe***@engcorp.com> wrote:

Roy Smith wrote:

I'm working on a prototype of a new application in Python. At some
point, if this ever turns into a product, the powers that be will almost
certainly demand that it be done in Perl. My job will be to convince
them otherwise.

Do you need to convince them now, to allow you to continue working on it
in Python, or are you just preparing for the time when they will come and
ask for it to be done in Perl?

The latter. It's currently a bit of a skunk works project. At some
point, when the time comes to actually allocate resources to this, some
PHB will undoubtedly declare that it has to be done in Perl. At that
point, I'll need to be able to argue coherently why that's a bad idea.

why will they want it rewritten? usually, management want to maximise
productive output and minimise cost. rewriting it would have a definite
positive cost, so either they think the perl version will be superior in
some way, or they think it will save costs later on. if you (or we) know
what their motives are, you (or we) can get closer to getting them to do
what we want.

tom

--
skills to pay the bills!

[Cameron Laird]

In article <ro***********************@reader2.panix.com>,
Roy Smith <ro*@panix.com> wrote:

I'm working on a prototype of a new application in Python. At some
point, if this ever turns into a product, the powers that be will almost
certainly demand that it be done in Perl. My job will be to convince
them otherwise.

The basic design of the application is object oriented. I've never used
Perl's OO features, so I'm not in a good position to make a comparison
of the two languages from an OO point of view. Can somebody who's done
OOP in both Python and Perl help me out?

I certainly know why Perl sucks in general, but for this purpose, I need
to specifically compare the OO features of the two. I'm looking for
something more fundamental than "->{} is ugly".

Roy, while the usual crowd has given you good general counsel,
I think you deserve to know that, yes, there *is* a story
specifically about Perl's OO.

Briefly, Perl wasn't designed as OO, and it was added on as a
(too-clever) hack. Python was OO from the beginning.

That argument smacks of *ad hominem*. <URL: http://
wiki.slowass.net/?HowDoesPerlStackUp > has details.

Counter-argument: Damian's *Object-Oriented Perl* is superb.
--

Cameron Laird <Ca*****@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html

[Asun Friere]

Peter Hansen <pe***@engcorp.com> wrote in message news:<3F***************@engcorp.com>...

I ask because I suspect the best way of convincing them will be to do
nothing, and stand back watching as your Python prototype continues to
work without problems, while those attempting to rewrite it in Perl
waste a lot of time and never get it quite working... and even if they
do, just print out a couple of pages from both and show them to the
"powers that be" and that ought to do the trick.

I'm in a similar position to the parent poster, with my boss
"flagging" the fact that my app will have be translated back into Perl
at some stage. The difference is that some parts of my project are
already being used in 'production.' I agree with your strategy,
although the indication is that it will be me who will be doing the
re-writting. :/

It's amazing how inertia can work to your advantage, especially in a
short-staffed shop. While the boss, understandibly, doesn't want
every programmer going off and writing in their pet language, the
ultimate test remains, "does it get the job done?"