473,320 Members | 2,088 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Python versus Perl ?


I've read some posts on Perl versus Python and studied a bit of my
Python book.

I'm a software engineer, familiar with C++ objected oriented
development, but have been using Perl because it is great for pattern
matching, text processing, and automated testing. Our company is really
fixated on risk managnemt and the only way I can do enough testing
without working overtime (which some people have ended up doing) is by
automating my testing. That's what got me started on Perl.

I've read that many people prefer Python and that it is better than
Perl. However, I want to ask a few other questions.
1. Perl seems to have alot of packaged utilities available through
CPAN, the comprehensive perl network. These can aid in building
parsers, web development, perl DBI is heavily used. This seems to be a
very important benifit. I'm not sure that Python is as extenive at all
in that regard ? Perl also has excellent pattern matching compared to
sed, not sure about how Python measures up,
but this seems to make perl ideally suited to text processing.

2. Python is apparantly better at object oriented. Perl has some kind
of name spacing, I have used that in a limited way. Does Perl use a
cheap and less than optimal Object oriented approach ?
That was what someone at work said, he advocates Python.
Is it likely that Perl will improve it's object oriented features
in the next few years ?

3. Perl is installed on our system and alot of other systems.
You don't have to make sys admins go out of there way to make it
available. It's usualy allready there. I also did a search of job
postings on a popular website. 108 jobs where listed that require
knowledge of Perl, only 17 listed required Python. Becomeing more
familiar with Perl might then be usefull for ones resume ?

If Python is better than Perl, I'm curious how really significant
those advantages are ?

Jul 18 '05 #1
31 4697
su********@yahoo.com wrote:
I've read some posts on Perl versus Python and studied a bit of my
Python book.

I'm a software engineer, familiar with C++ objected oriented
development, but have been using Perl because it is great for pattern
matching, text processing, and automated testing. Our company is really
fixated on risk managnemt and the only way I can do enough testing
without working overtime (which some people have ended up doing) is by
automating my testing. That's what got me started on Perl.

I've read that many people prefer Python and that it is better than
Perl. However, I want to ask a few other questions.
"Better than Perl" is a very general statement. In my personal opinion,
this is true for every project being larger than one file of ~200 LOC.
1. Perl seems to have alot of packaged utilities available through
CPAN, the comprehensive perl network. These can aid in building
parsers, web development, perl DBI is heavily used. This seems to be a
very important benifit. I'm not sure that Python is as extenive at all
in that regard ?
There are the Python Package Index (PyPI), the Vaults of Parnassus, and
when you don't find a needed package there, just come and ask here;
almost always a decent solution is found.

A thing similar to CPAN is being worked on by various people, though I
don't know when it will become mature.
Perl also has excellent pattern matching compared to
sed, not sure about how Python measures up,
but this seems to make perl ideally suited to text processing.
Python has regular expressions much like Perl. The only difference is
that Perl carries syntactic support for them, while in Python regular
expressions are ordinary objects with methods etc.
2. Python is apparantly better at object oriented. Perl has some kind
of name spacing, I have used that in a limited way. Does Perl use a
cheap and less than optimal Object oriented approach ?
That was what someone at work said, he advocates Python.
Is it likely that Perl will improve it's object oriented features
in the next few years ?
There is the Perl 6 movement, but when you read some of the docs at
http://dev.perl.org, you will come to the conclusion that

- Perl 6 lies at least 3-5 years in the future and
- it will be a huge mess. Someone here once said "Perl 6 is the ultimate
failure of Perl's philosophy". There may be split views about this...
3. Perl is installed on our system and alot of other systems.
You don't have to make sys admins go out of there way to make it
available. It's usualy allready there.
Same goes with Python; it is installed per default on most modern
Unices. Windows is a completely different chapter, however, Perl isn't
more widespread there.
I also did a search of job
postings on a popular website. 108 jobs where listed that require
knowledge of Perl, only 17 listed required Python. Becomeing more
familiar with Perl might then be usefull for ones resume ?
It doesn't harm, of course. Recent statistics about programmers'
salaries indicate, however, that Python ranks top (I somehow lost the URL).
If Python is better than Perl, I'm curious how really significant
those advantages are ?


Try to decide yourself. The Python tutorial and website are your friends.

Reinhold
Jul 18 '05 #2
su********@yahoo.com said the following on 2/6/2005 8:19 AM:
I've read some posts on Perl versus Python and studied a bit of my
Python book.

I'm a software engineer, familiar with C++ objected oriented
development, but have been using Perl because it is great for pattern
matching, text processing, and automated testing. Our company is really
fixated on risk managnemt and the only way I can do enough testing
without working overtime (which some people have ended up doing) is by
automating my testing. That's what got me started on Perl.
Python is great for pattern matching using the re module. If you are
talking about the ~= operator, that is not available in Python but you
can your favorite Regexp matches/searches/replacements using the re
module. And actually I like Python re sub better as it has a clean
syntax. One can provide a replacement function to the sub method where
one can manipulate the matched groups. Please see
http://www.amk.ca/python/howto/regex/ for more info.

Automated testing - One of the best languages to create automated test
cases and still remember after a few months what your test cases... that
is how clean Python syntax is. And you have not specified exactly what
kind of automation you do. I code test cases for Win32 as well as
testing data exchange over FTP and Telnet.

I know a lot of toy and serious parsers written in Python. Heck, there
is even a Python implementation in Python. Text Processing is simply
superb, combined the the re module. I am not too qualified to talk about
text processing but lets say life is a breeze! You can read about Python
Text Processing at http://gnosis.cx/TPiP/ - this is a whole book
dedicated to text processing in Python. Also see
http://www.python.org/moin/LanguageParsing

1. Perl seems to have alot of packaged utilities available through
CPAN, the comprehensive perl network. These can aid in building
parsers, web development, perl DBI is heavily used. This seems to be a
very important benifit. I'm not sure that Python is as extenive at all
in that regard ? Perl also has excellent pattern matching compared to
sed, not sure about how Python measures up,
but this seems to make perl ideally suited to text processing.
While, AFAIK, there is no CPANish library, Python comes with "batteries"
included, i.e., almost everything you would need to churn out the
programs you need. For everything else, there are independent projects.
But take a look at the Vault of Parnassus for a BIG collection of Python
modules/projects/applications.

Python has a DBI compliant API which means all compliant modules support
the same syntax. And Python has modules supports all major databases.
See http://www.python.org/topics/database/
2. Python is apparantly better at object oriented. Perl has some kind
of name spacing, I have used that in a limited way. Does Perl use a
cheap and less than optimal Object oriented approach ?
That was what someone at work said, he advocates Python.
Is it likely that Perl will improve it's object oriented features
in the next few years ?
Well, Perl's lack of a decent OO approach is one reason I converted to
Python. Another was Perl's syntax; I could not read my own code unless I
had put copious amounts of comments. Python enforces clean coding using
indentation levels that associates blocks of code; so no need of a {} or
BEGIN/END and you will be amazed at how indentation, which IMHO, any
programmer should anyway practice for readability, can make the code
easy to comprehend.
3. Perl is installed on our system and alot of other systems.
You don't have to make sys admins go out of there way to make it

That actually depends on the OS. I believe Sun OS comes with Perl and
that is because of the historic use of Perl for sys admin work. Redhat 8
onwards comes with Python installed because Redhat's install process is
written in Python. Windows comes with neither. And for your sysadmins,
installing Python should not be difficult at all. As long as you
identify the need and tell them that is what they must do for your
accomplish your tasks efficiently, I don't see this a stumbling block at
all!
available. It's usually allready there. I also did a search of job
postings on a popular website. 108 jobs where listed that require
knowledge of Perl, only 17 listed required Python. Becomeing more
familiar with Perl might then be usefull for ones resume ?


I don't see the correlation between the number of jobs available and
fashion-statement of a language, if that is what you are insinuating. My
job does not require me to know Python, but I use it and effectively.
So, how does one account for that? And since you already have a job and
are considering using Python for your current job, it should not matter
to you. Moreover you increase your marketability by learning both Perl
and Python...you have access to 108 + 17 jobs :-)

True, there are a few Python "shops" but there are many jobs that ask
for knowledge of Python, especially testing positions. The few Python
shops are places you will die to work for - like Google may be?

Other aspects that support adoption of Python are consistent syntax,
great OO, code maintainability and short development time (proportional
to the complexity of the design).

Good that you asked this question as part of due diligence. These are
the factors I can point out. If I have missed something or misquoted,
gurus out there can correct me.

Hope that helped!
-Kartic
Jul 18 '05 #3
su********@yahoo.com wrote:
I've read some posts on Perl versus Python and studied a bit of my
Python book.

I'm a software engineer, familiar with C++ objected oriented
development, but have been using Perl because it is great for pattern
matching, text processing, and automated testing. Our company is really
fixated on risk managnemt and the only way I can do enough testing
without working overtime (which some people have ended up doing) is by
automating my testing. That's what got me started on Perl.
Automated testing is essential in almost any software project, and not just
to make sure you don't have to work overtime.
I've read that many people prefer Python and that it is better than
Perl. However, I want to ask a few other questions.
Keep in mind that this is a somewhat biased audience to ask a question like
that. For the most part, c.l.p. is inhabited by rabid Pythonistas :-)
1. Perl seems to have alot of packaged utilities available through
CPAN, the comprehensive perl network.
There is no doubt that there's a lot of stuff on CPAN, and the architecture
of the repository makes it relatively easy to find what you want and get it
running. On the other hand, there are a lot of add-on modules for Python
too. You mention DBI; Python's version of that is the DB-API, and there
are quite a few modules that implement it
(http://www.python.org/topics/database/modules.html).
Perl also has excellent pattern matching compared to
sed, not sure about how Python measures up,
but this seems to make perl ideally suited to text processing.
As far as regular espressions themselves, Python supports exactly the same
regex syntax that Perl does. The packaging is a little different; instead
of being built-in to the language, it's a module you import and use in an
object-oriented way.
2. Python is apparantly better at object oriented. Perl has some kind
of name spacing, I have used that in a limited way. Does Perl use a
cheap and less than optimal Object oriented approach?
Python's OO support was designed-in from the ground up. Perl's is an ugly
wart held on with duct tape.
That was what someone at work said, he advocates Python.
Is it likely that Perl will improve it's object oriented features
in the next few years ?
There is a "Perl 6" project going on, which I imagine will have some major
changes to the language, but you'll have to ask the Perl people about that.
3. Perl is installed on our system and alot of other systems.
You don't have to make sys admins go out of there way to make it
available. It's usualy allready there.
Python now comes standard with a lot of operating systems, but it is
certainly true that if there is one lingua franca in the computer world
(and certainly the Unix world), Perl is it. If your prime motivation is
portability, that might be the feature which tips the balance in favor of
Perl.
I also did a search of job
postings on a popular website. 108 jobs where listed that require
knowledge of Perl, only 17 listed required Python. Becomeing more
familiar with Perl might then be usefull for ones resume?
There is no doubt that most employers expect you to know Perl. Even if
it's not on the job spec, there's enough Perl out there in the world that
it really is worth knowing. If your career goal is sysadmin rather than
programming, then I'd say Perl is absolutely essential to know.
If Python is better than Perl, I'm curious how really significant
those advantages are?


Well, now we're back to that biased audience stuff again. My answer is
that of course it's better. The biggest advantage of Python is that it has
a clean syntax with designed-in support of OOP.

Perl's basic syntax is a jumble of stuff stolen from shell, awk, sed, and
grep, with some vague OO ideas glommed onto it. The heavy reliance on
punctuation makes it almost impossible to read.

My suggestion is to learn Python, then make up your own mind. Grab one of
the tutorials available on-line and spend an afternoon getting the basics
down. Next step, pick a small real-life project and invest a couple of
days doing it in Python. By then, you should have a better idea of whether
it's worth investing some more time to get deeper into it.

One you know C++, Perl, and Python, you'll have exposure to a pretty broad
range of programming paradigms. But, don't stop there. If your goal is to
be a professional programmer, keep learning languages. Learn some because
they'll provide a paycheck, learn others because they'll expose you to
different ideas. In today's world, I'd put Java, SQL, VB, and C# in the
"paycheck" group. I'd put Lisp, Smalltalk, and Postscript in the "personal
improvement" group. Things like Python, Tcl, and Ruby fall somewhere
in-between; they're interesting because they explore different corners of
the "how to design a programming language" universe, but they also have a
reasonable chance of being a skill which will keep the paychecks flowing.
Jul 18 '05 #4
Reinhold Birkenfeld wrote:
su********@yahoo.com wrote:
I've read some posts on Perl versus Python and studied a bit of my
Python book.

I'm a software engineer, familiar with C++ objected oriented
development, but have been using Perl because it is great for pattern
matching, text processing, and automated testing. Our company is really
fixated on risk managnemt and the only way I can do enough testing
without working overtime (which some people have ended up doing) is by
automating my testing. That's what got me started on Perl.

I've read that many people prefer Python and that it is better than
Perl. However, I want to ask a few other questions.

"Better than Perl" is a very general statement. In my personal opinion,
this is true for every project being larger than one file of ~200 LOC.

1. Perl seems to have alot of packaged utilities available through
CPAN, the comprehensive perl network. These can aid in building
parsers, web development, perl DBI is heavily used. This seems to be a
very important benifit. I'm not sure that Python is as extenive at all
in that regard ?

There are the Python Package Index (PyPI), the Vaults of Parnassus, and
when you don't find a needed package there, just come and ask here;
almost always a decent solution is found.

A thing similar to CPAN is being worked on by various people, though I
don't know when it will become mature.

Perl also has excellent pattern matching compared to
sed, not sure about how Python measures up,
but this seems to make perl ideally suited to text processing.

Python has regular expressions much like Perl. The only difference is
that Perl carries syntactic support for them, while in Python regular
expressions are ordinary objects with methods etc.

2. Python is apparantly better at object oriented. Perl has some kind
of name spacing, I have used that in a limited way. Does Perl use a
cheap and less than optimal Object oriented approach ?
That was what someone at work said, he advocates Python.
Is it likely that Perl will improve it's object oriented features
in the next few years ?

There is the Perl 6 movement, but when you read some of the docs at
http://dev.perl.org, you will come to the conclusion that

- Perl 6 lies at least 3-5 years in the future and
- it will be a huge mess. Someone here once said "Perl 6 is the ultimate
failure of Perl's philosophy". There may be split views about this...

3. Perl is installed on our system and alot of other systems.
You don't have to make sys admins go out of there way to make it
available. It's usualy allready there.

Same goes with Python; it is installed per default on most modern
Unices. Windows is a completely different chapter, however, Perl isn't
more widespread there.

I also did a search of job
postings on a popular website. 108 jobs where listed that require
knowledge of Perl, only 17 listed required Python. Becomeing more
familiar with Perl might then be usefull for ones resume ?

It doesn't harm, of course. Recent statistics about programmers'
salaries indicate, however, that Python ranks top (I somehow lost the URL).

If Python is better than Perl, I'm curious how really significant
those advantages are ?

Try to decide yourself. The Python tutorial and website are your friends.
Reinhold

I like Ruby because it inherits so many (best) features from Python and
Perl ;) Someday all these languages will compile to a common
intermediate representation (ref. YAML: http://yaml.kwiki.org ||
http://yaml.org )

http://blade.nagaokaut.ac.jp/cgi-bin...uby-talk/79533

http://www.cs.washington.edu/homes/k...pythonruby.pdf

http://www.ntecs.de/old-hp/s-direktn...load_ruby.html

http://www.ruby-lang.org/en/
// moma
Jul 18 '05 #5
Reinhold Birkenfeld <re************************@wolke7.net> wrote:
...
Perl also has excellent pattern matching compared to
sed, not sure about how Python measures up,
but this seems to make perl ideally suited to text processing.


Python has regular expressions much like Perl. The only difference is
that Perl carries syntactic support for them, while in Python regular
expressions are ordinary objects with methods etc.


In many ways, Python's modularity is advantageous here. However, since
(I believe) about Perl 5.2 or so, Perl's regular expressions aren't --
they're more powerful than regular expressions, because you can embed
arbitrary Perl code in them as part of the matching process. Python's
regular expressions are very close to those of Perl 5.X for some X<2 (I
think it was 5.2 where the code-embedding trick was introduced, but
that's something of a guess on my part).
I also did a search of job
postings on a popular website. 108 jobs where listed that require
knowledge of Perl, only 17 listed required Python. Becomeing more
familiar with Perl might then be usefull for ones resume ?


It doesn't harm, of course. Recent statistics about programmers'
salaries indicate, however, that Python ranks top (I somehow lost the URL).


"Software Development" magazine has run such polls for years, and the
fact that Pythonistas' salaries are at the top has been true since the
first such poll -- not a huge difference, but statistically significant.
What this finding _means_ is, of course, somewhat of a mystery
(correlation isn't causation), as is, of course, the OP's less formal
observation about job postings.
Alex
Jul 18 '05 #6

If Python is better than Perl, I'm curious how really significant
those advantages are ?


The main advantage is Python's cleanliness. In Perl, there are so
many different ways of writing a thing, that to be adept in perl,
you have to know them all, otherwise you won't be able to read another
person's code.

Python and Perl accomplish similar things, but have strikingly different
design philosophies. Perl's design philosophy is the kitchen sink: throw
it all in. Python's is, "let's keep this simple." We add things carefully,
and with great deliberation, or not at all.

As a consequence, Python is far easier to learn than Perl.

This has non-trivial consequences on your enterprise operations.

For example, getting new engineers up to speed on the old code base is
a great deal easier.

C//

Jul 18 '05 #7
On 6 Feb 2005 05:19:09 -0800, su********@yahoo.com <su********@yahoo.com> wrote:
....
I'm a software engineer, familiar with C++ objected oriented
development, but have been using Perl because it is great for pattern
matching, text processing, and automated testing. Our company is really
fixated on risk managnemt and the only way I can do enough testing
without working overtime (which some people have ended up doing) is by
automating my testing. That's what got me started on Perl.

I've read that many people prefer Python and that it is better than
Perl. However, I want to ask a few other questions.
I could go on and on, but this essay by Eric Raymond says it better:

http://www.linuxjournal.com/article/3882
3. Perl is installed on our system and alot of other systems.
You don't have to make sys admins go out of there way to make it
available. It's usualy allready there.


Python is in most Linux installations ... but it's much more rare than perl
elsewhere. Yes, this is a reason to write smaller text-processing and
automation hacks in perl.

/Jorgen

--
// Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
\X/ algonet.se> R'lyeh wgah'nagl fhtagn!
Jul 18 '05 #8
Hi Surfunbear

I don't know about the stuff regarding jobs, resumes, etc, but I will tell
you the same thing I tell everyone I meet regarding python:

Set aside a morning, and work through the python tutorial that comes with
the documentation. People like me are going to tell you this and that,
perhaps try to convince of our particular world-view, and so on.

By the end of the tutorial (more likely at halfway) you will probably know
whether this is worth pursuing or not. Oh, and do this before you invest
too much time in Perl :)

Keep well
Caleb

On 6 Feb 2005 05:19:09 -0800, <su********@yahoo.com> wrote:

I've read some posts on Perl versus Python and studied a bit of my
Python book.

I'm a software engineer, familiar with C++ objected oriented
development, but have been using Perl because it is great for pattern
matching, text processing, and automated testing. Our company is really
fixated on risk managnemt and the only way I can do enough testing
without working overtime (which some people have ended up doing) is by
automating my testing. That's what got me started on Perl.

I've read that many people prefer Python and that it is better than
Perl. However, I want to ask a few other questions.
1. Perl seems to have alot of packaged utilities available through
CPAN, the comprehensive perl network. These can aid in building
parsers, web development, perl DBI is heavily used. This seems to be a
very important benifit. I'm not sure that Python is as extenive at all
in that regard ? Perl also has excellent pattern matching compared to
sed, not sure about how Python measures up,
but this seems to make perl ideally suited to text processing.

2. Python is apparantly better at object oriented. Perl has some kind
of name spacing, I have used that in a limited way. Does Perl use a
cheap and less than optimal Object oriented approach ?
That was what someone at work said, he advocates Python.
Is it likely that Perl will improve it's object oriented features
in the next few years ?

3. Perl is installed on our system and alot of other systems.
You don't have to make sys admins go out of there way to make it
available. It's usualy allready there. I also did a search of job
postings on a popular website. 108 jobs where listed that require
knowledge of Perl, only 17 listed required Python. Becomeing more
familiar with Perl might then be usefull for ones resume ?

If Python is better than Perl, I'm curious how really significant
those advantages are ?


Jul 18 '05 #9
Jorgen Grahn wrote:
I've read that many people prefer Python and that it is better than Perl. However, I want to ask a few other questions.


I could go on and on, but this essay by Eric Raymond says it better:

http://www.linuxjournal.com/article/3882


His survey of programming languages in "The Art of Unix Programming",
available at
http://www.catb.org/~esr/writings/ta...eschapter.html , is
interesting (and biased). Raymond evaluates C, C++, Shell, Perl, Tcl,
Python, Java, and Emacs Lisp.

Jul 18 '05 #10
I just recently picked up Python after using perl almost exclusively
for the last 8 years, and the above mentioned article by Eric Raymond
echos my feelings almost exactly.

The one drawback coming from the perl world is that you don't have as
many options when it comes stuff like application frameworks, and some
of the third party modules just aren't as well tested not having the
huge user base that perl does. I end up spending a bit more time
searching for different libraries than I did in perl, but beyond that
I think python is better overall.

Chris
Jul 18 '05 #11
EP
su********@yahoo.com asked
3. Perl is installed on our system and a lot of other systems.
You don't have to make sys admins go out of there way to make it
available. It's usualy allready there. I also did a search of job
postings on a popular website. 108 jobs where listed that require
knowledge of Perl, only 17 listed required Python. Becomeing more
familiar with Perl might then be usefull for ones resume ?
Python is trivial to install on one's workstation or PC, if it isn't already there. Getting Python on the company's servers can require some IT latitude or buy-in.

<opinion>

I've begun to view the availability of Python on company servers as a measure of an IT organization's fitness.

Perl was (probably) the right language at the right time at least for cgi work and text processing in the early days of the web, when there was a sudden increase in the need for such work. And Perl "works", especially as youbecome familiar with it and some of the non-obvious ways it works. Learning Perl is an investment and many folks becomes Perl people - why would youswitch from anything you've put that much time into?

And so a vast number of people and orgnizations remain in the cave, unwilling to risk going outside, unwilling to believe life could be better out there in the unknown. Congrats for being the rare person who takes a look. (That strange feeling you may get is from something we call "sunshine" and, on balance, I think you'll find it is a very nice thing.)

If Python is better than Perl, I'm curious how really significant
those advantages are ?


I'd say the advantages are significant if you develop anything complex, or like to think about the software you develop in clean abstractions. I'd say knowing Python probably does not lead to a higher salary, but that the software engineers attracted to Python tend to be the cream of the crop and are worth more money.
[Disclaimer: Python also attracts some who are not cream of the crop software engineers but rather see things - applications, large or small - that ought to be done, and are looking for the most efficient way of getting there.. Anyone can write some Python succssfully, but not everyone is capable ofcontributing to PyPy. Python is a great tool for each.]

</opinon>

Recommendation: Python requires little investment. Play in it. Read (briefly) about the aspects that seem interesting. Try writing a small progam in it. There are very very few cases where anyone is going to require you to use Python; it's a personal decision, and the people that use Python do so because they want to, not because someone required them to.
cheers/

Jul 18 '05 #12
"EP" <EP@zomething.com> wrote:
There are very very few cases where anyone is going to require
you to use Python


Conversely, it pays to understand when you are likely to be permitted to
use it (or any new technology), and when you are likely to be forbidden.

Companies are generally the most conservative about "customer-facing"
projects. Something that's going to be shipped to a customer, or used
directly by a customer, is not a good candidate to try and the the PHB to
approve using something new.

The next step down the line is something which is going to be used by many
people within your own organization. If you write a tool in language X and
want it to get adopted as a tool that everybody uses, don't be too
surprised if the answer is, "Yeah, but who's going to maintain it, nobody
but you knows X".

The easiest way to sneak a new technology in the door is on a project where
nobody else has to use the technology directly, in other words, a tool you
write to help you get your own work done. When the boss notices that
you're getting your stuff done in half the time most of the other group
spends doing it, and you tell him it's because you're using X and everybody
else is using Y, it's like waving dollar signs in front of his face.
Jul 18 '05 #13
snacktime <sn*******@gmail.com> wrote:
The one drawback coming from the perl world is that you don't have as
many options when it comes stuff like application frameworks, and some


URK -- _my_ feeling is that we have entirely *too many* options for
stuff like web application frameworks, GUI toolkits, XML processing, ...
Alex
Jul 18 '05 #14

"Alex Martelli" <al*****@yahoo.com> wrote in message
news:1grl63x.1f2tzwz1q984vpN%al*****@yahoo.com...
snacktime <sn*******@gmail.com> wrote:
The one drawback coming from the perl world is that you don't have as
many options when it comes stuff like application frameworks, and some


URK -- _my_ feeling is that we have entirely *too many* options for
stuff like web application frameworks, GUI toolkits, XML processing, ...


Alex's comment resonates so much with me right now that I propose it for
QOTW.
Jul 18 '05 #15
be*******@aol.com schrieb:
His survey of programming languages in "The Art of Unix Programming",
available at
http://www.catb.org/~esr/writings/ta...eschapter.html , is
interesting (and biased). Raymond evaluates C, C++, Shell, Perl, Tcl,
Python, Java, and Emacs Lisp.


One part of this survey strikes me:

esr> In fact it's generally thought to be the least efficient and
esr> slowest of the major scripting languages, a price it [Python]
esr> pays for runtime type polymorphism.

If I assume Perl, Python, Ruby, Tcl and PHP to be major scripting
languages some benchmarks (http://dada.perl.it/shootout and
http://shootout.alioth.debian.org) show that Python is probably the
fastest among these (Perl is 25% faster at regex matching).

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
-------------------------------------------------------------------
Jul 18 '05 #16
m
Courageous wrote:
If Python is better than Perl, I'm curious how really significant
those advantages are ?


speedwise, i think perl is faster than python and python performed the
slowest as shown in http://www.flat222.org/mac/bench/
Jul 18 '05 #17
m" <m@m.com> wrote:
If Python is better than Perl, I'm curious how really significant
those advantages are ?


speedwise, i think perl is faster than python and python performed the slowest as shown in
http://www.flat222.org/mac/bench/


if you use Python mostly to write empty loops, your programming license
should be revoked. the benchmark author seems to have realized that, as
can be seen from the "it's dead" paragraph at the top of the page, which
makes me wonder why you posted this link...

</F>

Jul 18 '05 #18
m
Fredrik Lundh wrote:
if you use Python mostly to write empty loops, your programming license
should be revoked. the benchmark author seems to have realized that, as
can be seen from the "it's dead" paragraph at the top of the page, which
makes me wonder why you posted this link...

</F>


i was trying to decide whether i needed perl or python for some work
that i had to get done and was seeing which was faster. and came across
this link which i tht was pertinent. is python as fast as perl for the
nonempty loops that the author wrote?
Jul 18 '05 #19
m wrote:
Fredrik Lundh wrote:
if you use Python mostly to write empty loops, your programming license
should be revoked. the benchmark author seems to have realized that, as
can be seen from the "it's dead" paragraph at the top of the page, which
makes me wonder why you posted this link...

</F>

i was trying to decide whether i needed perl or python for some work
that i had to get done and was seeing which was faster. and came across
this link which i tht was pertinent. is python as fast as perl for the
nonempty loops that the author wrote?


Why do you care?
Have you read http://www.python.org/moin/PythonSpeed ?

--Irmen
Jul 18 '05 #20
Fredrik Lundh wrote:
m" <m@m.com> wrote:
If Python is better than Perl, I'm curious how really significant
those advantages are ?


speedwise, i think perl is faster than python and python performed the slowest as shown in
http://www.flat222.org/mac/bench/


if you use Python mostly to write empty loops, your programming license
should be revoked. the benchmark author seems to have realized that, as
can be seen from the "it's dead" paragraph at the top of the page, which
makes me wonder why you posted this link...


Especially when you read

"""
I found the performance of Python for these benchmarks really surprising
as it is at odds to my everyday experience.
"""

you will seriously think about the benchmark's significance.

Reinhold
Jul 18 '05 #21
Hi m

Speed is a contentious issue here. Point is, if you really need raw
speed, why stop only at Perl and Python? There are plenty of statically
compiled languages that will produce native binaries.

The relative difference in speed between Perl and Python, whatever it is,
is completely washed out by the enormous jump using, say, C for example
[please, everyone else, I am aware of all the mitigating circumstances
regarding, e.g. parts of the standard library written in C, etc. That is
not my point.]

A Good Reason for thinking along these lines (Perl/Python) is more
something like speed and reliability of development. Another one is
maintaintability. I must confess that I know pretty much nothing about
Perl, so I can't comment about that. My opinion about Python is that it
is very, very good for these things.

The problem domains in which I do most of my work (chemical process
modelling and simulation) really do require speed. That's why I mostly
use Delphi (i.e. reasonably fast code) at work. I believe I know when
speed is and is not an issue, and (by far) most of the time, my experience
is that it is *not*. So I use Delphi for numerical code and python for
everything else.

You really will have to convince people here that execution speed is a
real issue for your programming task (in order to continue this
discussion). Otherwise the debate will go south real quick.

Keep well
Caleb
On Tue, 08 Feb 2005 12:17:05 -0600, m <m@m.com> wrote:
Courageous wrote:
If Python is better than Perl, I'm curious how really significant
those advantages are ?


speedwise, i think perl is faster than python and python performed the
slowest as shown in http://www.flat222.org/mac/bench/


Jul 18 '05 #22
m
Irmen de Jong wrote:
m wrote: Why do you care?
Have you read http://www.python.org/moin/PythonSpeed ?

--Irmen

i had not read it. thanks for pointing it out!

Jul 18 '05 #23
m
<snip>
You really will have to convince people here that execution speed is a
real issue for your programming task (in order to continue this
discussion). Otherwise the debate will go south real quick.

Keep well
Caleb
On Tue, 08 Feb 2005 12:17:05 -0600, m <m@m.com> wrote:
Courageous wrote:

If Python is better than Perl, I'm curious how really significant
those advantages are ?

speedwise, i think perl is faster than python and python performed
the slowest as shown in http://www.flat222.org/mac/bench/



i have nothing else to add. thanks caleb!
Jul 18 '05 #24
On Tue, 2005-02-08 at 22:44, Caleb Hattingh wrote:
Hi m

Speed is a contentious issue here. Point is, if you really need raw
speed, why stop only at Perl and Python? There are plenty of statically
compiled languages that will produce native binaries.

The relative difference in speed between Perl and Python, whatever it is,
is completely washed out by the enormous jump using, say, C for example
[please, everyone else, I am aware of all the mitigating circumstances
regarding, e.g. parts of the standard library written in C, etc. That is
not my point.]
I think the expression you seek is "comparing virtue among whores."

Now we can all acknowledge that there is a spectrum in the programmer
time vs machine time trade-off. (Voice reader users: Please forgive my
ASCII art ... imagine a data set that loosely fits a linear relationship
with a negative slope.)

ASCII art start

+
M|*
A| * *
C| *
H| * "STUPID"
I| * *
N| *
E| *
| *
C| * *
O| "Holy *
S| Grail" *
T| *
0------------------------- +
PROGRAMMER COST

ASCII art stop

This metric is actually in two dimensions, but we usually consider it in
one dimension with High Machine cost and low programmer cost at one
extreme and low machine cost and high programmer cost at the other
extreme.

ASCII art start

High Machine <---------------> High Programmer Cost

ASCII art stop

because there is a high inverse correlation between programmer and
machine costs. Only a fool would use a programing language in the
"stupid" area of the above chart (both costs high). Likewise, nobody
gets to use the language that does not exist in the "Holy Grail" area of
the chart (both costs low.)

Both Python and Perl are way up in the upper left ( machine cost high,
programmer cost low) of my little chart. Perl has much magic that
drives up its programmer cost. Not by much in the know, but by enough
that I would consider it to have a slightly higher programmer cost than
Python. If Perl code executes a bit faster, then fine, all I can say is
"that's nice." If machine costs were an issue I'd recode in vhdl and
compile to silicone.

Of the topic I want to address, you can entirely circumvent those
issues by coding in C and using the Python C-API instead of strcmp and
friends.

A Good Reason for thinking along these lines (Perl/Python) is more
something like speed and reliability of development. Another one is
maintaintability. I must confess that I know pretty much nothing about
Perl, so I can't comment about that. My opinion about Python is that it
is very, very good for these things.

The problem domains in which I do most of my work (chemical process
modelling and simulation) really do require speed. That's why I mostly
use Delphi (i.e. reasonably fast code) at work. I believe I know when
speed is and is not an issue, and (by far) most of the time, my experience
is that it is *not*. So I use Delphi for numerical code and python for
everything else.
Why don't you use C for the numerical work? Then you can do your number
crunching within a c-based python module. Have your cake and ...

You really will have to convince people here that execution speed is a
real issue for your programming task (in order to continue this
discussion). Otherwise the debate will go south real quick.


Not only most speed be an issue, but the economics must be such that any
alternative is better than throwing more hardware at the problem.

Adam DePrince
Jul 18 '05 #25
If you give it a good go, you will be amazed at how the text processing
is so much better than Perl's. The same with the object orientation
(what oop in Perl?? none... at least none worth mentioning :-) It's
been said before by many Python users... Python allows newbies to
program and wizards to be even more wizardly... or something to that
effect.

Jul 18 '05 #26
Hi Adam

Thanks for your comments.
I think the expression you seek is "comparing virtue among whores."
Sure, that's what I was saying, but not quite in as colourfil a manner
:)

The problem domains in which I do most of my work (chemical process modelling and simulation) really do require speed. That's why I mostly use Delphi (i.e. reasonably fast code) at work. I believe I know when speed is and is not an issue, and (by far) most of the time, my experience is that it is *not*. So I use Delphi for numerical code and python for everything else.


Why don't you use C for the numerical work? Then you can do your

number crunching within a c-based python module. Have your cake and ...


As you might imagine, I think about this constantly. However, there
are many other issues that make it complicated, such as having to work
in a team where the average guy knows pascal well (we're just a bunch
of chemical engineers), but has never even heard of python. Plus, were
I to go this type of route, I would almost definitely code the binary
modules in Delphi or FreePascal, make a DLL and use ctypes to call it.
I do not know C and have no desire to learn now :) On the other
hand, I know pascal quite well.

keep well
Caleb

Jul 18 '05 #27
su********@yahoo.com wrote:
I've read some posts on Perl versus Python and studied a bit of my
Python book.

I'm a software engineer, familiar with C++ objected oriented
development, but have been using Perl because it is great for pattern
matching, text processing, and automated testing. Our company is really fixated on risk managnemt and the only way I can do enough testing
without working overtime (which some people have ended up doing) is by automating my testing. That's what got me started on Perl.

I've read that many people prefer Python and that it is better than
Perl. However, I want to ask a few other questions.


This doesn't directly address your questions, but may be useful for
you, being a C++ programmer.

http://www.strombergers.com/python/

It is biased towards Python, obviously, but shows some practical
differences between Python and Perl that may be of interest.

-Chris

Jul 18 '05 #28
Caleb Hattingh wrote:
As you might imagine, I think about this constantly. However, there
are many other issues that make it complicated, such as having to work
in a team where the average guy knows pascal well (we're just a bunch
of chemical engineers), but has never even heard of python. Plus, were
I to go this type of route, I would almost definitely code the binary
modules in Delphi or FreePascal, make a DLL and use ctypes to call it.
I do not know C and have no desire to learn now :) On the other
hand, I know pascal quite well.

keep well
Caleb


You could always code Python extensions directly in Delphi:

http://membres.lycos.fr/marat/delphi/python.htm
http://www.atug.com/andypatterns/PythonDelphiLatest.htm

Demo09 (look in demodll.dpr & module.pas) in the download tells you how.

Peace,
Joe

Jul 18 '05 #29
Joe, thanks

Yes, I am on the P4D mailing list :) What you didn't say was that the
"python for delphi" extensions are *awesome*. full two-way communication,
and you get it all by drag&dropping a little component widget onto your
form in the IDE. Amazing.

However...

Dll's can be used by things other than python, which is the main reason
why we would go that route. However, with all the .NET hoopla, maybe
IronPython and a .NET dll would be the way to go in the future. I'm still
a little uneasy about adopting .NET as a standard just yet...

I should give it some more thought anyways.

Thanks again
Caleb

On Wed, 09 Feb 2005 12:38:37 -0500, Joe Francia
<gm**********@joefrancia.com> wrote:
Caleb Hattingh wrote:
As you might imagine, I think about this constantly. However, there
are many other issues that make it complicated, such as having to work
in a team where the average guy knows pascal well (we're just a bunch
of chemical engineers), but has never even heard of python. Plus, were
I to go this type of route, I would almost definitely code the binary
modules in Delphi or FreePascal, make a DLL and use ctypes to call it.
I do not know C and have no desire to learn now :) On the other
hand, I know pascal quite well.
keep well
Caleb


You could always code Python extensions directly in Delphi:

http://membres.lycos.fr/marat/delphi/python.htm
http://www.atug.com/andypatterns/PythonDelphiLatest.htm

Demo09 (look in demodll.dpr & module.pas) in the download tells you how.

Peace,
Joe


Jul 18 '05 #30

Alex Martelli wrote:
URK -- _my_ feeling is that we have entirely *too many* options for
stuff like web application frameworks, GUI toolkits, XML processing, ....

Alex


I entirely second that.

More, I'd heartily welcome an authoritative word on which to focus on
for each category... I hate to see scarce resources wasted.

Mauro

Jul 18 '05 #31
"Mauro Cicognini" <ma*************@gmail.com> wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:

Alex Martelli wrote:
URK -- _my_ feeling is that we have entirely *too many* options
for stuff like web application frameworks, GUI toolkits, XML
processing,

...


Alex


I entirely second that.

More, I'd heartily welcome an authoritative word on which to
focus on for each category... I hate to see scarce resources
wasted.


Alex also suggested that a revival of the anygui interface would be
a Good Thing. I would certainly love to see that.

It seems to me that Python should in fact include either anygui or
an equivalent to it as part of its core. Then to interface with a
given GUI package, it would be necessary to create a wrapper that
maps the wrapper's API to that standard Pythonic API. More work for
the package maintainers, and not easy to do in some cases, but for
the Python community it would be a huge gain. The same argument
could be made for the anydbm interface.

In both cases, the interface should not hinder the ability of a
developer to access any part of the package API, which implies that
parameters must be flexible. Maybe this is a strong use case for
bunch/data/namespace arguments and return values.

--
rzed

Jul 18 '05 #32

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

54
by: Brandon J. Van Every | last post by:
I'm realizing I didn't frame my question well. What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump up in your chair and scream "Wow! Ruby has *that*? That is SO...
13
by: Peter Mutsaers | last post by:
Hello, Up to now I mostly wrote simple filter scripts in Perl, e.g. while(<>) { # do something with $_, regexp matching, replacements etc. print; } Now I learned Python and like it much...
68
by: Lad | last post by:
Is anyone capable of providing Python advantages over PHP if there are any? Cheers, L.
9
by: Dieter Vanderelst | last post by:
Dear all, I'm currently comparing Python versus Perl to use in a project that involved a lot of text processing. I'm trying to determine what the most efficient language would be for our...
72
by: Gregory Petrosyan | last post by:
Please visit http://www.python.org/peps/pep-0204.html first. As you can see, PEP 204 was rejected, mostly because of not-so-obvious syntax. But IMO the idea behind this pep is very nice. So,...
6
by: metaperl | last post by:
Hello, I am responsible for converting 30 loosey-goosey Perl scripts into 30 well-documented easy to understand and use Python scripts. No one has said anything in particular about how this...
4
by: kettle | last post by:
Hi, I am rather new to python, and am currently struggling with some encoding issues. I have some utf-8-encoded text which I need to encode as iso-2022-jp before sending it out to the world. I am...
14
by: marcpenninga | last post by:
This is *not* an attempt to start yet another Python-versus- AnyOtherProgrammingLanguage flame war, but I thought people might be interested in this: http://www.tiobe.com/tpci.htm Marc
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.