Is anyone capable of providing Python advantages over PHP if there are
any?
Cheers,
L.
68  5763 
Lad skrev: Is anyone capable of providing Python advantages over PHP if there are
any?
Much more compact and yet much more readable code, making it easier to
maintain and extend your programs.
--
Leif Biberg Kristensen http://solumslekt.org/
Lad wrote: Is anyone capable of providing Python advantages over PHP if there are
any?
Python is a programming language in more ways than simple Turing
completeness. PHP isn't.
>>>>> "Leif" == Leif K-Brooks <eu*****@ecritters.biz> writes:
Leif> Lad wrote: Is anyone capable of providing Python advantages over PHP if there are
any?
Leif> Python is a programming language in more ways than simple Turing
Leif> completeness. PHP isn't.
+1 QOTW.
--
Ville Vainio http://tinyurl.com/2prnb
Tim Tyler wrote: Mage <ma**@mage.hu> wrote or quoted:
check this: http://wiki.w4py.org/pythonvsphp.html
Good - but it hardly mentions the issue of security - which seems
like a bit of a problem for PHP at the moment.
I don't think so. Bad programmers are able to write bad programs in any
language. Maybe there are more bad php programmers than python
programmers and the 70% of the dynamic world wide web is copied from
user comments in the php.net/manual. However one of the worst cases is
the sql injection attack. And sql injections must be handled neither by
php nor by python but by the programmer.
I think a website or even a large portal is a well constructed database
with triggers and stored procedures and some "echo", "if", "foreach" and
"while" in the php code.
To me the advantage of python seems to come out when you deal with xml,
file handling or when you have to write a native server application for
your website. But I am so new here, others may say other things.
Mage
"Lad" <py****@hope.cz> writes: Is anyone capable of providing Python advantages over PHP if there are
any?
Cheers,
L.
PHP is strongly wedded to providing web-based content, while Python can
be used to build a large number of different types of applications.
--
Kirk Job-Sluder
"The square-jawed homunculi of Tommy Hilfinger ads make every day an
existential holocaust." --Scary Go Round
I've been a PHP and Perl programmer (amongst others) for 10 years or
more now, and a Python coder for 3 or so.
I have come to hate PHP now, it's pseudo-OOP is awful, it's dog slow at
handling XML, it's so easy to use that most of the programmers I've had
contact with are very sloppy and do things like extract($_GET); or put
database usernames and passwords in index.php. I also have to agree
that php.net/manual seems to be the main reference that coders use -
which is not good if the comments are wrong!
Python seems to force you to write better code, maybe because of the
indentation, exception handling, proper OOP etc. Plus it's not so tied
into web stuff, in fact most of my Python programming is for the
desktop.
I still love Perl, it's a bit of an art form, as "there's more than one
way to do it", whereas Python usually only allows one way to do it,
which may or may not be a better mantra....
I've come to allocate PHP the same standing as ASP, VB or Java - the
language is OK, but the programmers are usually crap.
"Mage" wrote: I don't think so. Bad programmers are able to write bad programs in any
language.
in PHP, good programmers are able to write bad programs without
even noticing.
(every successful server attack I've seen closely the last few years
have been through PHP. it's totally without competition in this area)
However one of the worst cases is the sql injection attack. And sql
injections must be handled neither by php nor by python but by the
programmer.
sql injection? what's your excuse for not using data binding?
</F>
Fredrik Lundh wrote:
sql injection? what's your excuse for not using data binding?
I am not sure I truly understand your question.
So far my own servers didn't get successful sql injection attack. I just
saw some on other sites and did one for demonstration.
Avoid them is easy with set_type($value,"integer") for integer values
and correct escaping for strings.
However, php programmers usually don't initialize their variables
because they don't have to do. They even turn off warnings and errors.
Our php errorlog at my full time working company is so huge I could cry.
We have php-copypasters.
I don't know anyone IRL who uses python. So I started to learn it.
Mage
On Sat, 23 Apr 2005 20:13:24 +0200, Mage wrote: Avoid them is easy with set_type($value,"integer") for integer values and
correct escaping for strings.
"Avoiding buffer overflows in C is easy, as long as you check the buffers
each time."
The *existence* of a technique to avoid problems is not in question. The
problem is when the language makes it easier to *not* do the checks than
to do the checks. Any look at the real world shows that that pattern
causes trouble, and that clearly, the mere *existence* of a way to not get
in trouble is not sufficient in the general case.
Despite the fact that all you have to do to avoid cutting your finger off
with a saw is not stick your finger in the saw, most people, even
carpentry professionals, are going to want to use finger-guards and other
safety equipment. A programmer turning down such security protection
(without another good reason, which does happen), is being like the guy
too macho to use the finger guard; stupidity induced by arrogance, not
some one no longer using training wheels. Using PHP and futzing with SQL
directly is probably not a good enough reason, as surely PHP has safer
libraries available. (If not, my opinion of PHP goes down another notch.)
Data binding with something like SQLObject makes it *easier* to be secure
than insecure; barring an out-and-out bug in SQLObject (given the nature
of the requisite bug, it is extremely unlikely to have survived this
long), a programmer must go *way* out of their way to introduce the SQL
injection attacks that so plague PHP projects.
# ma**@mage.hu / 2005-04-23 15:53:17 +0200: Lad wrote:
Is anyone capable of providing Python advantages over PHP if there are
any?
I am also new to python but I use php for 4 years. I can tell:
- python is more *pythonic* than php
- python has its own perfume
http://www.1976.com.tw/image/trussardi_python_uomo.jpg and it's nice.
php doesn't have any smell
- writing python programs you feel much better
No, *you* feel better. :)
check this: http://wiki.w4py.org/pythonvsphp.html
The comparison found there is biased, the author is a Python
partisan.
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
Le Sat, 23 Apr 2005 19:11:19 +0200, Fredrik Lundh a écrit : in PHP, good programmers are able to write bad programs without
even noticing.
+1 QOTW
---
The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense.
Dr. E.W. Dijkstra
Mage wrote: However one of the worst cases is the sql injection attack. And sql
injections must be handled neither by php nor by python but by the
programmer.
But Python's DB-API (the standard way to connect to an SQL database from
Python) makes escaping SQL strings automatic. You can do this:
cursor.execute('UPDATE foo SET bar=%s WHERE id=%s', ["foo'bar", 123])
And "foo'bar" will be implicitly escaped to whatever is appropriate for
your database. How's that for Python handling SQL injection automatically?
Leif K-Brooks wrote: Mage wrote: However one of the worst cases is the sql injection attack. And sql
injections must be handled neither by php nor by python but by the
programmer.
But Python's DB-API (the standard way to connect to an SQL database
from Python) makes escaping SQL strings automatic. You can do this:
cursor.execute('UPDATE foo SET bar=%s WHERE id=%s', ["foo'bar", 123])
And "foo'bar" will be implicitly escaped to whatever is appropriate
for your database. How's that for Python handling SQL injection
automatically?
Not. Perl and Java use similar methods where one can specify place holders,
and pass on the data unescaped. But still injection is possible. Moreover,
a programmer still has to check if the values are acceptable or not.
AFAIK PHP is not able to do this, but goes at great length to "protect"
newbie programmers at great length, and hence give them a false feeling of
security. Defensive programming or a defensive programming language is
wrong.
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
"Simon John" <si************@yahoo.co.uk> writes: I still love Perl, it's a bit of an art form, as "there's more than one
way to do it", whereas Python usually only allows one way to do it,
which may or may not be a better mantra....
The Python mantra leads to 1) less programmer overhead, and 2) faster
improvements in the language.
To be a Perl expert, you have to know which of the many ways to do
various things is the fasted under what conditions. Python programmers
seldom have to worry about that - there's usually only one [obvious]
way to do things, so you just do it that way.
Having only one obvious way to do things means developers only have to
worry about impact on that way when making improvements, which will
speed them up.
The problem these days is that there are now multiple ways to do a
variety of things, because we have the "new, pythonic" way and the
"old, backwards-compatible way". So it's no longer clear which is the
fastest - and in the case of generators versus list comprehensions,
it's not clear which you should be using. To bad.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Mike Meyer wrote: "Simon John" <si************@yahoo.co.uk> writes:
I still love Perl, it's a bit of an art form, as "there's more than
one way to do it", whereas Python usually only allows one way to do
it, which may or may not be a better mantra....
The Python mantra leads to 1) less programmer overhead, and 2) faster
improvements in the language.
To be a Perl expert, you have to know which of the many ways to do
various things is the fasted under what conditions.
Why?
Python programmers
seldom have to worry about that - there's usually only one [obvious]
way to do things, so you just do it that way.
I doubt that :-D. I have never seen a programming language that forced
me in such a way :-D.
Having only one obvious way
I doubt that too ;-)
to do things means developers only have to
worry about impact on that way when making improvements, which will
speed them up.
Yeah, Perl programmers are extremely slow ;-)
The problem these days is that there are now multiple ways to do a
variety of things, because we have the "new, pythonic" way and the
"old, backwards-compatible way". So it's no longer clear which is the
fastest -
In most cases, why worry? If speed is an issue you should probably have
picked a different programming language in the first place (for that
part of the code).
and in the case of generators versus list comprehensions,
it's not clear which you should be using. To bad.
Use the one that is the easiest to read and understand by yourself.
That's how I program Perl, and that's how I am going to program Python.
An overloaded toolbox doesn't mean that if you have to hang a painting
on the wall that you have to think for 6 hours which tool you should
use. You just take the one that does the job in a way you feel
comfortable with. I know that the Perl mantra is often misunderstood,
but in my experience only by people who have very little experience with
the language.
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
John Bokma wrote: Not. Perl and Java use similar methods where one can specify place holders,
and pass on the data unescaped. But still injection is possible.
How?
John Bokma wrote: my $sort = $cgi->param( "sort" );
my $query = "SELECT * FROM table WHERE id=? ORDER BY $sort";
And the equivalent Python code:
cursor.execute('SELECT * FROM table WHERE id=%%s ORDER BY %s' % sort,
[some_id])
You're right, of course, about being *able* to write code with SQL
injection vulnerabilities in Python. But it's not even close to being as
easy as in PHP.
Leif K-Brooks skrev: But Python's DB-API (the standard way to connect to an SQL database
from Python) makes escaping SQL strings automatic. You can do this:
cursor.execute('UPDATE foo SET bar=%s WHERE id=%s', ["foo'bar", 123])
So. I've been writing SQL queries in Python like this, using PostgreSQL
and psycopg:
cursor.execute("select * from foo where bar=%s" % baz)
Is that wrong, and how should I have been supposed to know that this is
bad syntax? No doc I have seen actually has told me so.
--
Leif Biberg Kristensen http://solumslekt.org/
Leif K-Brooks wrote: John Bokma wrote:
my $sort = $cgi->param( "sort" );
my $query = "SELECT * FROM table WHERE id=? ORDER BY $sort";
And the equivalent Python code:
cursor.execute('SELECT * FROM table WHERE id=%%s ORDER BY %s' % sort,
[some_id])
You're right, of course, about being *able* to write code with SQL
injection vulnerabilities in Python. But it's not even close to being as
easy as in PHP.
I'm bewildered why you haven't mentioned magic quotes. A one line
change to the configuration file can render your PHP site almost
entirely immune to SQL injection attacks.
-Peter
--
Pull out a splinter to reply.
On Sun, 24 Apr 2005 01:35:31 +0200, Leif Biberg Kristensen
<ab***@solumslekt.org> declaimed the following in comp.lang.python: Is that wrong, and how should I have been supposed to know that this is
bad syntax? No doc I have seen actually has told me so.
The Python DB-API documents should have recommended against it
(or, at least, mentioned how they are designed to work...)
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <
John Bokma <po********@castleamber.com> writes: Mike Meyer wrote:
"Simon John" <si************@yahoo.co.uk> writes:
I still love Perl, it's a bit of an art form, as "there's more than
one way to do it", whereas Python usually only allows one way to do
it, which may or may not be a better mantra....
The Python mantra leads to 1) less programmer overhead, and 2) faster
improvements in the language.
To be a Perl expert, you have to know which of the many ways to do
various things is the fasted under what conditions.
Why?
One of the stated conditions for more than one Perl position I've
looked at.
Python programmers
seldom have to worry about that - there's usually only one [obvious]
way to do things, so you just do it that way.
I doubt that :-D. I have never seen a programming language that forced
me in such a way :-D.
I'd say you haven't seen a lot of languages - including Python. COBOL,
Eiffel, Rexx, Scheme, APL and a few others come to mind as "there's
usually only one way to do things". Python is one of them.
As a programmer, I find this very *freeing*. I can quite worrying
about implementation minutia - just do things the obvious way - and
worry instead about the "big picture"
Having only one obvious way
I doubt that too ;-)
Try programming in older Python for a while. You'll quit doubting it.
to do things means developers only have to
worry about impact on that way when making improvements, which will
speed them up.
Yeah, Perl programmers are extremely slow ;-)
Nah, they aren't slow. They just have to worry about more things than
the Python developers.
The problem these days is that there are now multiple ways to do a
variety of things, because we have the "new, pythonic" way and the
"old, backwards-compatible way". So it's no longer clear which is the
fastest -
In most cases, why worry? If speed is an issue you should probably have
picked a different programming language in the first place (for that
part of the code).
You apparently haven't been programming in Python very long. If speed
is an issue, you should probably pick a different
algorithm. Well-written Python programs use the C-coded parts of
Python for the time-critical part of the code.
and in the case of generators versus list comprehensions,
it's not clear which you should be using. To bad.
Use the one that is the easiest to read and understand by yourself.
That's how I program Perl, and that's how I am going to program Python.
The thing is, in Python there usually is one obvious way to do
things. That's changed in recent years as improvements have been added
without dropping the features they replaced so as not to break old
programs.
An overloaded toolbox doesn't mean that if you have to hang a painting
on the wall that you have to think for 6 hours which tool you should
use. You just take the one that does the job in a way you feel
comfortable with. I know that the Perl mantra is often misunderstood,
but in my experience only by people who have very little experience with
the language.
The problem with using "the way you feel comfortable with" is that it
may not be comfortable for the maintainer - even if that's you six
months from now. My Perl evolved from very shell script like (lots of
backticks and passing around the full text of files) to one more
C-like as I used the language. That change was largely driven by
performance concerns as my understanding of the language grew.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Peter Ammon wrote: I'm bewildered why you haven't mentioned magic quotes. A one line
change to the configuration file can render your PHP site almost
entirely immune to SQL injection attacks.
PHP's magic quotes is one of the most poorly-designed features I can
think of. Instead of magically escaping only strings which will actually
be passed to a database (like Python's DB-API does), it escapes every
string that comes from the user, meaning that strings which will be sent
back to the user have to be manually unescaped.
Even worse, since it can be turned on and off, code which is designed
for a magic_quotes=on environment will become seriously vulnerable when
moved to an environment with magic_quotes on. Security-related features
should never be toggleable!
Leif K-Brooks wrote: John Bokma wrote: my $sort = $cgi->param( "sort" );
my $query = "SELECT * FROM table WHERE id=? ORDER BY $sort";
And the equivalent Python code:
cursor.execute('SELECT * FROM table WHERE id=%%s ORDER BY %s' % sort,
[some_id])
You're right, of course, about being *able* to write code with SQL
injection vulnerabilities in Python.
I can only speak for Perl for now, but I am sure it has been done, and I
don't want to know how often :-D (Unless everyone who did pays me 1 USD).
But it's not even close to being as
easy as in PHP.
I didn't deny that :-) Personally I don't like PHPs "magicaddslashquote"
stuff. It gives beginners the impression that everything is taken care of.
It's like giving someone a house with a door with 7 locks, without telling
all windows at ground level can't be closed (and the master key is under
the doormat)
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Peter Ammon wrote: Leif K-Brooks wrote: John Bokma wrote:
my $sort = $cgi->param( "sort" );
my $query = "SELECT * FROM table WHERE id=? ORDER BY $sort";
And the equivalent Python code:
cursor.execute('SELECT * FROM table WHERE id=%%s ORDER BY %s' % sort,
[some_id])
You're right, of course, about being *able* to write code with SQL
injection vulnerabilities in Python. But it's not even close to being
as easy as in PHP.
I'm bewildered why you haven't mentioned magic quotes. A one line
change to the configuration file can render your PHP site almost
entirely immune to SQL injection attacks.
There is no almost in security.
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Leif K-Brooks wrote: Peter Ammon wrote: I'm bewildered why you haven't mentioned magic quotes. A one line
change to the configuration file can render your PHP site almost
entirely immune to SQL injection attacks.
PHP's magic quotes is one of the most poorly-designed features I can
think of. Instead of magically escaping only strings which will actually
be passed to a database (like Python's DB-API does), it escapes every
string that comes from the user, meaning that strings which will be sent
back to the user have to be manually unescaped.
Yup, I recently downloaded a script that required grc_magic_quotes (IIRC
the name) to be *off*
I looked it up, and one has to do such a thing in the ini (!!!) file.
Even worse, since it can be turned on and off, code which is designed
for a magic_quotes=on environment will become seriously vulnerable when
moved to an environment with magic_quotes on. Security-related features
should never be toggleable!
Amen.
And quite some people who nowadays install PHP scripts are the same ones
who reply to questions like "My messenger program doesn't work" with "Did
you disable the firewall?".
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Mike Meyer wrote: John Bokma <po********@castleamber.com> writes:
Mike Meyer wrote:
"Simon John" <si************@yahoo.co.uk> writes:
I still love Perl, it's a bit of an art form, as "there's more than
one way to do it", whereas Python usually only allows one way to do
it, which may or may not be a better mantra....
The Python mantra leads to 1) less programmer overhead, and 2)
faster improvements in the language.
To be a Perl expert, you have to know which of the many ways to do
various things is the fasted under what conditions.
Why?
One of the stated conditions for more than one Perl position I've
looked at.
That's weird, since some can differ between versions of Perl like for
example a map in a void context. And I am sure Python has now and then
improvements which make one operation suddenly 10% faster in a new
version.
So it tells you a lot about the people providing the position ;-)
Having only one obvious way
I doubt that too ;-)
Try programming in older Python for a while. You'll quit doubting it.
Again I doubt that. I doubt that if I give 100 old Python programmers a
certain computer science problem I will see 100 exactly the same
solutions, which when benchmarked run equally fast.
to do things means developers only have to
worry about impact on that way when making improvements, which will
speed them up.
Yeah, Perl programmers are extremely slow ;-)
Nah, they aren't slow. They just have to worry about more things than
the Python developers.
Do you have references to this? I would love to see if indeed 100 Python
programmers do implement, say 5 CS tasks faster compared to 100 Perl
programmers, on average.
In most cases, why worry? If speed is an issue you should probably
have picked a different programming language in the first place (for that
part of the code).
You apparently haven't been programming in Python very long.
Nope. I think I copied 3 examples and had a peek at it. I did read the
tutorial (twice) and am rereading Dive into Python.
If speed
is an issue, you should probably pick a different
algorithm. Well-written Python programs use the C-coded parts of
Python for the time-critical part of the code.
Why are those time critical parts not written in Python ;-)
Use the one that is the easiest to read and understand by yourself.
That's how I program Perl, and that's how I am going to program
Python.
The thing is, in Python there usually is one obvious way to do
things. That's changed in recent years as improvements have been added
without dropping the features they replaced so as not to break old
programs.
I know to little about Python, especially about old Python, to have an
idea of what you mean. I only saw, quite recently, someones solution to
a problem that used 30 lines of Python, and I am sure I could have
written it in 3-4. And I doubt that's because he was using, or I was
thinking in, new Python
:-D.
An overloaded toolbox doesn't mean that if you have to hang a
painting on the wall that you have to think for 6 hours which tool you should
use. You just take the one that does the job in a way you feel
comfortable with. I know that the Perl mantra is often misunderstood,
but in my experience only by people who have very little experience
with the language.
The problem with using "the way you feel comfortable with" is that it
may not be comfortable for the maintainer - even if that's you six
months from now.
After 5 years one gets comfortable with most constructions in a
language. I am more often uncomfortable with the way someone translates
a problem into code. And there is no way how you can force people with a
language that is, to do that the same, not even close.
My Perl evolved from very shell script like (lots of
backticks and passing around the full text of files)
I am sure you can do that with Python too.
to one more
C-like as I used the language. That change was largely driven by
performance concerns as my understanding of the language grew.
Yup, in Perl one should program Perl, not bash, not C. Same for Python.
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
John Bokma <po********@castleamber.com> writes: Mike Meyer wrote:
John Bokma <po********@castleamber.com> writes:
Mike Meyer wrote:
"Simon John" <si************@yahoo.co.uk> writes:
> I still love Perl, it's a bit of an art form, as "there's more than
> one way to do it", whereas Python usually only allows one way to do
> it, which may or may not be a better mantra....
The Python mantra leads to 1) less programmer overhead, and 2) faster improvements in the language.
To be a Perl expert, you have to know which of the many ways to do
various things is the fasted under what conditions.
Why?
One of the stated conditions for more than one Perl position I've
looked at.
That's weird, since some can differ between versions of Perl like for
example a map in a void context. And I am sure Python has now and then
improvements which make one operation suddenly 10% faster in a new
version.
The things is - it doesn't matter nearly as much in Python. Since
there's only one obvious way to do most simple things, that's the one
that most programmers will choose, and that's the one the developers
will worry about making faster.
So it tells you a lot about the people providing the position ;-)
Yeah - they expect their people to be on top of such things. I've
never run across a Python position where knowing which of several ways
was faster was an important criterion - because there usually aren't
several ways. Having only one obvious way
I doubt that too ;-)
Try programming in older Python for a while. You'll quit doubting it.
Again I doubt that. I doubt that if I give 100 old Python programmers a
certain computer science problem I will see 100 exactly the same
solutions, which when benchmarked run equally fast.
Depends on the problem. If it's one of the things for which Python has
an obvious solution (sort a list; split a string on whitespace; pull
select list elements based on a criteria of some kind; search a file
for lines with a given word in them; etc.) you'd get back the same
answer from almost all of them.
As I've said a number of times, this has changed lately as new
features have been added without removing their older counterparts. to do things means developers only have to
worry about impact on that way when making improvements, which will
speed them up.
Yeah, Perl programmers are extremely slow ;-)
Nah, they aren't slow. They just have to worry about more things than
the Python developers.
Do you have references to this? I would love to see if indeed 100 Python
programmers do implement, say 5 CS tasks faster compared to 100 Perl
programmers, on average.
I'm talking about the people developing the language, not the ones
developing in the language. And this is just my impression from
watching the developers lists. If speed
is an issue, you should probably pick a different
algorithm. Well-written Python programs use the C-coded parts of
Python for the time-critical part of the code.
Why are those time critical parts not written in Python ;-)
Because then they'd be slower. A good scripting environment has lots
of operations available that are coded at a low level. Since this code
is usually hand-tuned and optimized over time (like the dictionary
lookup or string operations in Python, or regular expressions in Perl
- I'm not sure about the RE library in Python), it may well be faster
than what you'd write in the low level language if you did it
yourself. Use the one that is the easiest to read and understand by yourself.
That's how I program Perl, and that's how I am going to program Python. The thing is, in Python there usually is one obvious way to do
things. That's changed in recent years as improvements have been added
without dropping the features they replaced so as not to break old
programs.
I know to little about Python, especially about old Python, to have an
idea of what you mean. I only saw, quite recently, someones solution to
a problem that used 30 lines of Python, and I am sure I could have
written it in 3-4. And I doubt that's because he was using, or I was
thinking in, new Python
:-D.
Just because there's only one obvious way to do things doesn't mean
it's obvious to everyone. Witness the recent spate of people asking
for "goto".
An overloaded toolbox doesn't mean that if you have to hang a painting on the wall that you have to think for 6 hours which tool you should
use. You just take the one that does the job in a way you feel
comfortable with. I know that the Perl mantra is often misunderstood,
but in my experience only by people who have very little experience with the language.
The problem with using "the way you feel comfortable with" is that it
may not be comfortable for the maintainer - even if that's you six
months from now.
After 5 years one gets comfortable with most constructions in a
language. I am more often uncomfortable with the way someone translates
a problem into code. And there is no way how you can force people with a
language that is, to do that the same, not even close.
Of course not. The best you can do is provide one obvious way to do
things, and then hope most people find that. My Perl evolved from very shell script like (lots of
backticks and passing around the full text of files)
I am sure you can do that with Python too.
That hasn't happened in 9 years of Python. Some of the idioms have
changed because the language has changed, but not because my
perceptions/expectations/etc have changed. to one more
C-like as I used the language. That change was largely driven by
performance concerns as my understanding of the language grew.
Yup, in Perl one should program Perl, not bash, not C. Same for Python.
Right. But Perl makes it *easy* to program in bash or C while staying
in Perl, and provides no obvious drawbacks from doing so - all because
it's trying to be comfortable to sh and C programmers by providing
ways to do things that those users are comfortable with. Trying to
write sh or C in Python is painfull, and you usually run into
problems/drawbacks fairly quickly - because that's not the obvious way
to do things.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Mike Meyer wrote: John Bokma <po********@castleamber.com> writes:
Mike Meyer wrote:
John Bokma <po********@castleamber.com> writes:
Mike Meyer wrote:
> "Simon John" <si************@yahoo.co.uk> writes:
>
>> I still love Perl, it's a bit of an art form, as "there's more
>> than one way to do it", whereas Python usually only allows one
>> way to do it, which may or may not be a better mantra....
>
> The Python mantra leads to 1) less programmer overhead, and 2) faster> improvements in the language.
>
> To be a Perl expert, you have to know which of the many ways to do
> various things is the fasted under what conditions.
Why?
One of the stated conditions for more than one Perl position I've
looked at.
That's weird, since some can differ between versions of Perl like for
example a map in a void context. And I am sure Python has now and
then improvements which make one operation suddenly 10% faster in a
new version.
The things is - it doesn't matter nearly as much in Python. Since
there's only one obvious way to do most simple things, that's the one
that most programmers will choose, and that's the one the developers
will worry about making faster.
Of course the same holds for Perl. I remember thing that got quite
faster (I made up 10%), which is a map in void context. I guess it was
done because it's quite easy to do, not because it was on top of the
"this must be made faster" list :-)
I quickly read over http://www.xml.com/pub/a/2004/03/31/pycon.html
So it tells you a lot about the people providing the position ;-)
Yeah - they expect their people to be on top of such things. I've
never run across a Python position where knowing which of several ways
was faster was an important criterion - because there usually aren't
several ways.
I have no idea about the number of Perl programmers v.s. Python
programmers, but I can imagine if one wants to hire a Perl programmer
that one goes at great length to drop the "I downloaded 7 CGI scripts,
and managed to make them even more insecure" people.
If I had to write a Perl test, a lot of people who *call* themselves
Perl programmers would fail :-). (I was tested once for Perl, and I was
shown snippets from badly written source, and had to tell what certain
things did, which is quite hard if the source is written by people
clearly knew less of Perl than I do of Python :-) )
I guess that Python suffers less from this, but I am just a beginner
:-).
Again I doubt that. I doubt that if I give 100 old Python programmers
a certain computer science problem I will see 100 exactly the same
solutions, which when benchmarked run equally fast.
Depends on the problem. If it's one of the things for which Python has
an obvious solution (sort a list; split a string on whitespace; pull
select list elements based on a criteria of some kind; search a file
for lines with a given word in them; etc.) you'd get back the same
answer from almost all of them.
And what makes you doubt it would be different with Perl? :-D
( sort @alist, split ' ', $astring, grep criteria, @list, etc )
As I've said a number of times, this has changed lately as new
features have been added without removing their older counterparts.
The only variation I expect for the above Perl solutions is the use of
(), and the first argument of split. However, the last one might show
some exotic solutions :-)
> to do things means developers only have to
> worry about impact on that way when making improvements, which
> will speed them up.
Yeah, Perl programmers are extremely slow ;-)
Nah, they aren't slow. They just have to worry about more things
than the Python developers.
Do you have references to this? I would love to see if indeed 100
Python programmers do implement, say 5 CS tasks faster compared to
100 Perl programmers, on average.
I'm talking about the people developing the language, not the ones
developing in the language. And this is just my impression from
watching the developers lists.
I have no idea, since I read neither list. I have the idea that Perl is
indeed more fat, especially since the (too big) number of built in
stuff, that Python has in libraries (where it should be IMNSHO).
One could say (and should) that the regular expression thingy in Perl is
a language on its own :-)
If speed
is an issue, you should probably pick a different
algorithm. Well-written Python programs use the C-coded parts of
Python for the time-critical part of the code.
Why are those time critical parts not written in Python ;-)
Because then they'd be slower. A good scripting environment has lots
of operations available that are coded at a low level. Since this code
is usually hand-tuned and optimized over time (like the dictionary
lookup or string operations in Python, or regular expressions in Perl
- I'm not sure about the RE library in Python), it may well be faster
than what you'd write in the low level language if you did it
yourself.
Agreed, I forget to write down that it was a joke. Some time ago someone
asked that question to me, with the Python relaced with Perl. And I gave
a similar answer.
But you probably agree, that if speed is an issue, and the programmer's
skills are not the issue, that the only thing one can do is code it in a
different language (probably by another programmer).
I know to little about Python, especially about old Python, to have
an idea of what you mean. I only saw, quite recently, someones
solution to a problem that used 30 lines of Python, and I am sure I
could have written it in 3-4. And I doubt that's because he was
using, or I was thinking in, new Python
:-D.
Just because there's only one obvious way to do things doesn't mean
it's obvious to everyone.
My point. Moreover, most skilled Perl programmers (or at least the ones
I know) fall back to a shared common set of idioms, which probably are
not always the fastest one (which I consider a good thing)). So to them
there are often obvious ways to do things. Put them together, and for
the small problems you gave they very likely will come up with similar
results.
So restrictions on the number of ways fails for beginners, because: life
will find a way. And skilled programmers don't need it, because they
somehow stick together.
Witness the recent spate of people asking
for "goto".
I was a witness, moreover I stated my opinion, which in short stated
that there is nothing wrong with goto as a statement. Keeping a
statement from a language because beginners don't understand it, and
write bad code with it, is wrong. Moreover, every time I see some kind
of protection in a language, I see people who consider them safe, and
make other, equally bad (or worse) mistakes. (See my other replies in
this thread regarding the special "protection" PHP has).
You either understand why something is bad at a given moment, or not. If
a language must make up for the understanding a programmer lacks,
something is very very wrong.
I doubt that Python needs a goto, since I am sure it has enough "syntax
sugared" versions of goto to solve most, if not all things that one
needs a goto for.
I never used goto in Perl, but I do use early return, break, continue,
last, next. Some are called bad, because they make more then one exit
point. There was a time I belonged to the same camp, until I discovered
that my C code started to move off the right of the screen, and all the
if, else, etc stuff only made it unreadable, moreover:
}
}
}
}
}
}
}
Didn't help either (almost each and every one needed a comment, adding
more clutter)
After 5 years one gets comfortable with most constructions in a
language. I am more often uncomfortable with the way someone
translates a problem into code. And there is no way how you can force
people with a language that is, to do that the same, not even close.
Of course not. The best you can do is provide one obvious way to do
things, and then hope most people find that.
Beginners get lost anyway, experienced programmers don't need it
My Perl evolved from very shell script like (lots of
backticks and passing around the full text of files)
I am sure you can do that with Python too.
That hasn't happened in 9 years of Python.
That was not what I wrote: I am sure one can program that way in Python
too.
Some of the idioms have
changed because the language has changed, but not because my
perceptions/expectations/etc have changed.
In 9 years? I learned so much in 9 years about programming that I
probably am ashamed to show Perl code I wrote 9 years back :-) (Even if
I left out the Perl 4 syntax). Moreover, I think that my current Perl
code is quite different from 3-4 years back. And no, not all is related
to the "there are more ways to do things". I changed my mind on certain
things (mostly style issues), learned new modules (some are really new,
others I just didn't know about), but also: I learned new programming
techniques, or other ways to look at a problem, and hence, write a
different solution (but using the same idioms as 3-4 years back). to one more
C-like as I used the language. That change was largely driven by
performance concerns as my understanding of the language grew.
Yup, in Perl one should program Perl, not bash, not C. Same for
Python.
Right. But Perl makes it *easy* to program in bash or C while staying
in Perl, and provides no obvious drawbacks from doing so - all because
it's trying to be comfortable to sh and C programmers by providing
ways to do things that those users are comfortable with. Trying to
write sh or C in Python is painfull, and you usually run into
problems/drawbacks fairly quickly - because that's not the obvious way
to do things.
But again, it doesn't keep people who want to do this. And moreover, I
think beginners are able to write even worse code, wether it provides
sh/C support or not. Some people are extremely good at inventing their
own syntax, and ideas of what certain things do (or don't).
Also, Perl borrows a lot of its syntax from C, which Python (as far as I
have seen) does extremely little, if at all. So it's already easier to
program C-like in Perl, by design, even if Perl was as "restrictive" as
Python.
If the current direction of Python means relaxing it a bit, I personally
think that is a good thing. Sometimes more than one way makes it
possible to introduce a construction that's well known in another
language, and turn it into an idiom for the "more than one way"
language, and hence, teach "new" ideas to people.
And my quick peek at http://www.xml.com/pub/a/2004/03/31/pycon.html
gives me the impression that the current direction of Python is to make
such things available (for example more lazy, which I like thanks to my
functional programming experience :-) )
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
John Bokma <po********@castleamber.com> writes: Mike Meyer wrote: Depends on the problem. If it's one of the things for which Python has
an obvious solution (sort a list; split a string on whitespace; pull
select list elements based on a criteria of some kind; search a file
for lines with a given word in them; etc.) you'd get back the same
answer from almost all of them.
And what makes you doubt it would be different with Perl? :-D
Perl's "There's more than one way to do it" attitude.
( sort @alist, split ' ', $astring, grep criteria, @list, etc )
In the one case where perl provides you two ways to do things, you
chose the one that doesn't solve the problem. You want map, not grep.
You also chose the wrong way to do things globally, by leaving off the
optional parens on the function invocations. That makes the list a
PITA to parse, in that you have to know the number of arguments to
each function in order to parse the list you provided.
Consider the python version:
(alist.sort(), astring.split(), [x for x in alist if criteria(x)])
This list can be parsed by a machine. Given proper bindings for all
the variables, Python will turn it into a tuple.
N.B.: split(' ', $astring) is wrong as well. In this case, Perl
doesn't provide the right tool for the job; you have to build it from
parts.
As I've said a number of times, this has changed lately as new
features have been added without removing their older counterparts.
The only variation I expect for the above Perl solutions is the use of
(), and the first argument of split. However, the last one might show
some exotic solutions :-)
And those trivial variations are enough that you chose the wrong
ones. And you're (by your own admission) an experienced Perl
programmer.
>> to do things means developers only have to
>> worry about impact on that way when making improvements, which
>> will speed them up.
> Yeah, Perl programmers are extremely slow ;-)
Nah, they aren't slow. They just have to worry about more things
than the Python developers.
Do you have references to this? I would love to see if indeed 100
Python programmers do implement, say 5 CS tasks faster compared to
100 Perl programmers, on average.
I'm talking about the people developing the language, not the ones
developing in the language. And this is just my impression from
watching the developers lists.
I have no idea, since I read neither list. I have the idea that Perl is
indeed more fat, especially since the (too big) number of built in
stuff, that Python has in libraries (where it should be IMNSHO).
If you think Perl is fat now, read the apocalypses for Perl 6. Perl 6
is going to make Common LISP look small.
One could say (and should) that the regular expression thingy in Perl is
a language on its own :-)
It is. For what Perl was designed for, having that be part of the
grammar of the language makes sense. For a general-purpose programming
language, I'm not so sure.
But you probably agree, that if speed is an issue, and the programmer's
skills are not the issue, that the only thing one can do is code it in a
different language (probably by another programmer).
I don't agree. The better alternative is to look for a faster
algorithm. Programming "in the large" (as allowed by Python, Perl,
etc. when compared to C) sometimes makes that easier.
Changing languages is a potshoot. I once recoded a Python program into
Eiffel (which is compiled), only to have it slow down by a factor of
4. The program used a large collection of static objects - hundreds of
thousands of them - which the SmallEiffel garbage collector would scan
every time it ran. Python's reference counting ignore them, so the
Python version ran noticably faster even though the basic operations
were all faster in Eiffel.
Now, I could have recoded it in C and gotten *much* faster. But then
I'd have to deal with all the dynamically allocated objects (millions
of them!) by hand, plus writing the code to deal with the trie and
such like. Ugly.
Oh yeah - this algorithm was the third crack at the problem. Changing
the algorithms had sped things up noticably.
I know to little about Python, especially about old Python, to have
an idea of what you mean. I only saw, quite recently, someones
solution to a problem that used 30 lines of Python, and I am sure I
could have written it in 3-4. And I doubt that's because he was
using, or I was thinking in, new Python
:-D.
Just because there's only one obvious way to do things doesn't mean
it's obvious to everyone.
My point. Moreover, most skilled Perl programmers (or at least the ones
I know) fall back to a shared common set of idioms, which probably are
not always the fastest one (which I consider a good thing)). So to them
there are often obvious ways to do things. Put them together, and for
the small problems you gave they very likely will come up with similar
results.
So restrictions on the number of ways fails for beginners, because: life
will find a way. And skilled programmers don't need it, because they
somehow stick together.
My experience with Perl is just the opposite. Everytime I have to
maintain Perl code, I come across a different set of idioms - with no
obvious downside to them. You can, of course, define "skilled
programmers" as those who use your idiom set. This makes the set of
skilled Perl programmers very small. That few programmers are skilled
is a downside of TMTOWTDI, as the only time I see new idioms in Python
are newbies doing very odd things here.
I will conceede that the itertools module puts the lie to me. It
provides a lot of list manipulation functions that I haven't
thoroughly explored, which represent new idioms. However, those aren't
part of the grammar of the language, and are a recent addition. It's
not clear how Python should evolve with them added to the language.
Witness the recent spate of people asking
for "goto".
I was a witness, moreover I stated my opinion, which in short stated
that there is nothing wrong with goto as a statement. Keeping a
statement from a language because beginners don't understand it, and
write bad code with it, is wrong. Moreover, every time I see some kind
of protection in a language, I see people who consider them safe, and
make other, equally bad (or worse) mistakes. (See my other replies in
this thread regarding the special "protection" PHP has).
I, on the other hand, feel that adding something to the language just
because you can is a *really* bad idea. Unless the new construct
solves a real problem, there's no point in adding it. It just bloats
the language processor and increases the mental load on people who
program in the language. The best you can do is ignore it in your
code, meaning you're going to have pause and think about it every time
you run into it in someone elses code. I never saw a good use case for
goto in Python (as opposed to C, where it's clearly needed).
Adding things just because you can leads to monstrosities like Common
LISP, PL/I, Algol 68 and Perl 6. Adding features only when they add
functionality (or better yet, by removing restrictions) leads to
jewels like Python, Scheme and Eiffel.
You either understand why something is bad at a given moment, or not. If
a language must make up for the understanding a programmer lacks,
something is very very wrong.
There's a difference between "making up for the understanding a
programmer lacks" and "handicapping the programmer". Missing gotos is
like missing explicit pointer manipulation. Carefully designed
features added to the language (or restrictions removed from it) can
provide the same functionality as those features, without exposing
programmers to all the potential bugs that can occur when those
features are used.
Adding something that doesn't extend the language and creates
potential bugs is a *mistake*. You run that risk every time you add
just another way to do something.
I doubt that Python needs a goto, since I am sure it has enough "syntax
sugared" versions of goto to solve most, if not all things that one
needs a goto for.
Exactly.
After 5 years one gets comfortable with most constructions in a
language. I am more often uncomfortable with the way someone
translates a problem into code. And there is no way how you can force
people with a language that is, to do that the same, not even close.
Of course not. The best you can do is provide one obvious way to do
things, and then hope most people find that.
Beginners get lost anyway, experienced programmers don't need it
I disagree. If there's not one obvious way to do things, experienced
programmers tend to choose the one they are most comfortable with, and
will have to work out what all the others mean. This has been my
experience with Perl and Common LISP, and from what I hear is true of
C++ as well.
On the other hand, my experience with languages that provide one
obvious way to do things (Python, Scheme, Eiffel) is that experienced
programmers tend to find that way, and beginners quickly become
frustrated when they fight the language.
My Perl evolved from very shell script like (lots of
backticks and passing around the full text of files)
I am sure you can do that with Python too.
That hasn't happened in 9 years of Python.
That was not what I wrote: I am sure one can program that way in Python
too.
No, you said "one can do that with Python", leaving the word "that"
open to interpretation. I assumed you meant "migrate from writing sh
to writing C", which, as I said, hasn't happened.
If you meant writing sh or C in Python, try it. You'll find it clumsy
and frustrating. Python wasn't *designed* to make it comfortable to
write that way. Perl was - just a couple of more ways to do things.
Some of the idioms have
changed because the language has changed, but not because my
perceptions/expectations/etc have changed.
In 9 years? I learned so much in 9 years about programming that I
probably am ashamed to show Perl code I wrote 9 years back :-) (Even if
I left out the Perl 4 syntax). Moreover, I think that my current Perl
code is quite different from 3-4 years back. And no, not all is related
to the "there are more ways to do things". I changed my mind on certain
things (mostly style issues), learned new modules (some are really new,
others I just didn't know about), but also: I learned new programming
techniques, or other ways to look at a problem, and hence, write a
different solution (but using the same idioms as 3-4 years back).
The only one of those that really matters is "changing your mind on
certain things". The only way to do that is if there's more than one
way to do those things in the first place. My Perl style changed
radically over the years. My python style has as well, but only
because the language has changed as time passed. In the cases where a
new construct/module hasn't been added, the idiom that was obvious
with Python 1.4 is still the right choice with Python 2.4. With Perl,
there's no obvious right choice, so you and I could both change our
minds.
to one more
C-like as I used the language. That change was largely driven by
performance concerns as my understanding of the language grew.
Yup, in Perl one should program Perl, not bash, not C. Same for
Python.
Right. But Perl makes it *easy* to program in bash or C while staying
in Perl, and provides no obvious drawbacks from doing so - all because
it's trying to be comfortable to sh and C programmers by providing
ways to do things that those users are comfortable with. Trying to
write sh or C in Python is painfull, and you usually run into
problems/drawbacks fairly quickly - because that's not the obvious way
to do things.
But again, it doesn't keep people who want to do this.
Um - this sentence isn't complete. It doesn't keep those people from
*what*?
A langauge can make it easy to write ugly code, or it can make it hard
to write ugly code. After all, "You can write FORTRAN in any
language(*)". If I have to maintain the code, I'd *much* prefer that
the language make it hard to write ugly code, as I'm that much less
likely to get ugly code to maintain. TMTOWTDI makes it easy to write
ugly code. TOOWTDI makes it hard to write ugly code.
Also, Perl borrows a lot of its syntax from C, which Python (as far as I
have seen) does extremely little, if at all. So it's already easier to
program C-like in Perl, by design, even if Perl was as "restrictive" as
Python.
If Perl only borrowed a lot of it's syntax from C, this wouldn't be a
problem. But it borrows a lot of it's syntax from sh as well,
sometimes supporting both (because TMTOWTDI). If it had done one or
the other, it would have been a better language.
If the current direction of Python means relaxing it a bit, I personally
think that is a good thing. Sometimes more than one way makes it
possible to introduce a construction that's well known in another
language, and turn it into an idiom for the "more than one way"
language, and hence, teach "new" ideas to people.
Considering that I've been arguing all along that "more than one way"
is a bad thing, I have to disagree with you.
I will agree that adding new idioms from other programming paradigms
is a good thing (see <URL:
http://en.wikipedia.org/wiki/Programming_paradigm >). In theory, the
reason for that is that changing paradigms changes the set of things
you do, so you aren't adding more ways to do things, you're adding
more things to do.
The reality is that such changes often do introduce new ways to do
things that already exist. There have already been threads where it's
been argued (by others - I just read them) that this is detrimental to
Python.
And my quick peek at http://www.xml.com/pub/a/2004/03/31/pycon.html
gives me the impression that the current direction of Python is to make
such things available (for example more lazy, which I like thanks to my
functional programming experience :-) )
Right. But read <URL: http://www.python.org/peps/pep-3000.html > and
you'll see that many of the things that are now redundant are
scheduled to go away when we break backwards compatability. The
philosophy is still that "There should be one-- and preferably only
one --obvious way to do it." (from "import this"), even if we are
drifting from that in the current implementations.
<mike
*) I still remember seeing FORTRAN programmers writing ALGOL-W
conditionals as:
if not condition then
else
begin
code
end
Because they learned to write the FORTRAN version:
if (.not. condition) goto 100
code
100 continue
They even had the gall to bitch about it when I marked them down for
it.
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Mage <ma**@mage.hu> wrote or quoted: Tim Tyler wrote:Mage <ma**@mage.hu> wrote or quoted:
check this: http://wiki.w4py.org/pythonvsphp.html
Good - but it hardly mentions the issue of security - which seems
like a bit of a problem for PHP at the moment.
I don't think so. Bad programmers are able to write bad programs in any
language. Maybe there are more bad php programmers than python
programmers and the 70% of the dynamic world wide web is copied from
user comments in the php.net/manual. However one of the worst cases is
the sql injection attack. And sql injections must be handled neither by
php nor by python but by the programmer.
SQL injection "only" gives you access to the database and its contents.
A bigger problem in practice for PHP at the moment is the way
fopen can allow access to the entire filing system.
That does things such as allowing trivial programming mistakes to expose
the unix password file to attackers - exposing not just the particular
site's database - but all users on the maching (on machines not using
shadow passwords) with passwords subject to dictionary and brute force
attacks.
The current defense involves switching off fopen - but unfortunately,
that rather cripples many PHP programs.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Mage a écrit : I can tell:
- python is more *pythonic* than php
Keyboard !-)
Lad a trollé : Is anyone capable of providing Python advantages over PHP if there are
any?
Why don't you check by yourself ?
Roman Neuhauser wrote: # ma**@mage.hu / 2005-04-23 15:53:17 +0200:
Lad wrote:
Is anyone capable of providing Python advantages over PHP if there are
any?
The irreverant would point you to
http://www.python.org/doc/Humor.html#vowels
*I* wouldn't consider doing anything like that, though. <wink>
check this: http://wiki.w4py.org/pythonvsphp.html
The comparison found there is biased, the author is a Python
partisan.
Yeah, as opposed to the completely unbiased opinions the OP expected to
find on comp.lang.PYTHON
Mike Meyer wrote: John Bokma <po********@castleamber.com> writes:
Mike Meyer wrote: Depends on the problem. If it's one of the things for which Python
has an obvious solution (sort a list; split a string on whitespace;
pull select list elements based on a criteria of some kind; search a
file for lines with a given word in them; etc.) you'd get back the
same answer from almost all of them.
And what makes you doubt it would be different with Perl? :-D
Perl's "There's more than one way to do it" attitude.
There's doesn't mean that you have to use or know them all. I think
every language here and there more ways to do something. And at a
broader scope, e.g. a simple algorithm, it doesn't matter that much
anymore.
( sort @alist, split ' ', $astring, grep criteria, @list, etc )
In the one case where perl provides you two ways to do things, you
chose the one that doesn't solve the problem. You want map, not grep.
You think? Please read perldoc -f grep (and map).
If you guess extra ways, you make Perl more complicated than it is :-D.
You also chose the wrong way to do things globally, by leaving off the
optional parens on the function invocations. That makes the list a
PITA to parse,
First of all, who cares? Not the programmer. But I doubt if you are
correct; why is
OP PARAMETER, LIST
a PITA to parse, and
OP( PARAMETER, LIST )
not? I would even say that the former is easier to parse, since there is
no need for checking the ( and ) (and matching them).
Moreover, if it's perfectly normal to write:
1 + 4 * 7
why would
OP PARAMETER, LIST
be any problem?
in that you have to know the number of arguments to
each function in order to parse the list you provided.
It has been a while since I wrote a lexer, but uhm, you set up a rule?
LIST := ITEM
LIST := LIST,ITEM
(I made up the syntax, but I guess it's clear)
Consider the python version:
(alist.sort(), astring.split(), [x for x in alist if
criteria(x)])
( told you it was grep ;-) )
This list can be parsed by a machine. Given proper bindings for all
the variables, Python will turn it into a tuple.
What makes you think a machine can not parse Perl? I didn't get a Larry
Wall with my version of Perl :-D
N.B.: split(' ', $astring) is wrong as well. In this case, Perl
doesn't provide the right tool for the job; you have to build it from
parts.
You either misread your own problem specifications, or you should read
perldoc -f split (near the end, it starts with "As a special case," )
And those trivial variations are enough that you chose the wrong
ones. And you're (by your own admission) an experienced Perl
programmer.
And you don't even come close :-D.
One could say (and should) that the regular expression thingy in Perl
is a language on its own :-)
It is. For what Perl was designed for, having that be part of the
grammar of the language makes sense. For a general-purpose programming
language, I'm not so sure.
Same could be said of floating point numbers, or complex numbers, or
lists, dictionaries, etc. etc.
But you probably agree, that if speed is an issue, and the
programmer's skills are not the issue, that the only thing one can do
is code it in a different language (probably by another programmer).
I don't agree. The better alternative is to look for a faster
algorithm.
"The programmer's skills are not the issue"
Now, I could have recoded it in C and gotten *much* faster. But then
I'd have to deal with all the dynamically allocated objects (millions
of them!) by hand,
weird, I let the computer do that :-D.
[ skilled Perl programmers use similar or same idioms ]
My experience with Perl is just the opposite. Everytime I have to
maintain Perl code, I come across a different set of idioms - with no
obvious downside to them. You can, of course, define "skilled
programmers" as those who use your idiom set. This makes the set of
skilled Perl programmers very small. That few programmers are skilled
is a downside of TMTOWTDI, as the only time I see new idioms in Python
are newbies doing very odd things here.
If I could have a peek at the Perl code you maintained I could tell you
(often by just seeing 3-5 lines) the status of the programmer who wrote
it :-)
As I wrote before, I have little experience with Python (one could say I
only read 2 books on it, and haven't written a stand alone piece of code
myself). But I have the feeling that the percentage of badly skilled
Perl programmers is way higher compared to Python for two reasons:
Quite some people have been "tweaking" CGI scripts
Quite some people "know" PHP, and hence consider themselves Perl
programmers.
part of the grammar of the language, and are a recent addition. It's
not clear how Python should evolve with them added to the language.
More fat: so I would say: learn to live with it. I only see advantages.
If you want a minimal set of operations, I recommend programming ARM
assembly, and don't go beyond ARM3 :-D.
Witness the recent spate of people asking
for "goto".
I was a witness, moreover I stated my opinion, which in short stated
that there is nothing wrong with goto as a statement. Keeping a
statement from a language because beginners don't understand it, and
write bad code with it, is wrong. Moreover, every time I see some
kind of protection in a language, I see people who consider them
safe, and make other, equally bad (or worse) mistakes. (See my other
replies in this thread regarding the special "protection" PHP has).
I, on the other hand, feel that adding something to the language just
because you can is a *really* bad idea.
As I said: the sugared versions of goto very likely solves all problems
that need (or "need") a goto.
you run into it in someone elses code. I never saw a good use case for
goto in Python (as opposed to C, where it's clearly needed).
I can only speak for Perl, and indeed, I never used a real goto.
You either understand why something is bad at a given moment, or not.
If a language must make up for the understanding a programmer lacks,
something is very very wrong.
There's a difference between "making up for the understanding a
programmer lacks" and "handicapping the programmer". Missing gotos is
like missing explicit pointer manipulation.
Neither has ever handicapped me in any way. I remember how Sun claimed
that their language was safe from memory leaking. I could come up with a
simple example that leaked memory like crazy in a few seconds. Moreover,
garbage collection gives newbies the impression that everything is
handled automatically, and hence, they forget that other resources are
less unforgiven, and *have to be* released.
Carefully designed
features added to the language (or restrictions removed from it) can
provide the same functionality as those features, without exposing
programmers to all the potential bugs that can occur when those
features are used.
A beginner will find a way. A nice example is garbage collection,
beginners think they don't have to think. And then suddenly things pop
up like: memory leaking, how are circular references handled, and oops,
suddenly things like weak references are needed. Add, things like
threading, and shared resources, resources that are limited in one way
or another and I doubt programming has become easier, or less error
prone.
Has anyone ever did serious research to the number of bugs per 10k lines
for several programming languages?
I remember to have read that air bags makes people drive more reckless.
I am quite convinced the same holds for programming languages. A
language can't cover your behind, so to speak.
Adding something that doesn't extend the language and creates
potential bugs is a *mistake*. You run that risk every time you add
just another way to do something.
potential bugs is often equal to something people *think* a beginner is
going to make.
Of course not. The best you can do is provide one obvious way to do
things, and then hope most people find that.
Beginners get lost anyway, experienced programmers don't need it
I disagree. If there's not one obvious way to do things, experienced
programmers tend to choose the one they are most comfortable with, and
and if they are not hermits, they choose the ones they see the most
often used (unless it's Perl golf).
will have to work out what all the others mean. This has been my
experience with Perl and Common LISP, and from what I hear is true of
C++ as well.
If I look at which things I have to work out the most: libraries. It
sounds a lot like you want an extremely pure language. I almost get the
impression that you hand code almost everything yourself. It doesn't
matter how clean you make the language, the libraries will be fat. I
rarely have to "work out" a piece of Perl. The "there is more than one
way to do it" is much more about the combination of basic blocks. Perl
is like legos. What you want sounds a lot like legos that can instead of
round thingies to connect them uses triangles, so there is only one way
to stack them. Oh, and you want them dull grey.
On the other hand, my experience with languages that provide one
obvious way to do things (Python, Scheme, Eiffel) is that experienced
programmers tend to find that way, and beginners quickly become
frustrated when they fight the language.
I wonder how much this has to do with how you learned Perl, and how you
learned Python.
> My Perl evolved from very shell script like (lots of
> backticks and passing around the full text of files)
I am sure you can do that with Python too.
That hasn't happened in 9 years of Python.
That was not what I wrote: I am sure one can program that way in
Python too.
No, you said "one can do that with Python", leaving the word "that"
open to interpretation. I assumed you meant "migrate from writing sh
to writing C", which, as I said, hasn't happened.
But it doesn't mean that one can't do ;-)
If you meant writing sh or C in Python, try it.
You talked about "lots of backticks and passing around etc." I am sure
one do things that are similar to backticks in Python, and also do the
passing around thing.
You'll find it clumsy and frustrating.
Yes, most languages make it clumsy and frustrating. Perl is a rare
exception.
Python wasn't *designed* to make it comfortable to
write that way. Perl was - just a couple of more ways to do things.
But not clumsy, nor frustrating ;-) Perl is like a nice toolbox, and you
want Python to be just one of this tools. Moreover, written on it:
guarantee is void if used in any other way then stated in the manual.
if I left out the Perl 4 syntax). Moreover, I think that my current
Perl code is quite different from 3-4 years back. And no, not all is
related to the "there are more ways to do things". I changed my mind
on certain things (mostly style issues), learned new modules (some
are really new, others I just didn't know about), but also: I learned
new programming techniques, or other ways to look at a problem, and
hence, write a different solution (but using the same idioms as 3-4
years back).
The only one of those that really matters is "changing your mind on
certain things".
To you.
The only way to do that is if there's more than one
way to do those things in the first place.
yup, the number of whitespace for example. Even python lets you free in
the number of spaces here and there ;-)
My Perl style changed
radically over the years. My python style has as well, but only
because the language has changed as time passed. In the cases where a
new construct/module hasn't been added, the idiom that was obvious
with Python 1.4 is still the right choice with Python 2.4. With Perl,
there's no obvious right choice,
To a newbie, nothing is obvious right, and a skilled programmer is able
to find the obvious right choice. You make it sound like the perl
community leaves people in the dark, and they have to find out what
everything means and does by trial and error. As I already wrote: the
more than one way is more often the *combination* of well known building
blocks.
Trying to write sh or C in Python is painfull, and you usually run
into problems/drawbacks fairly quickly - because that's not the
obvious way to do things.
But again, it doesn't keep people who want to do this.
Um - this sentence isn't complete. It doesn't keep those people from
*what*?
Trying to
A langauge can make it easy to write ugly code, or it can make it hard
to write ugly code.
But who writes this code? The language, or the programmer? A programmer
who writes ugly Perl code is suddenly going to be a skilled Python
programmer? Are you serious?
After all, "You can write FORTRAN in any
language(*)". If I have to maintain the code, I'd *much* prefer that
the language make it hard to write ugly code, as I'm that much less
likely to get ugly code to maintain.
Nonsense.
TMTOWTDI makes it easy to write
ugly code. TOOWTDI makes it hard to write ugly code.
And the funny thing is: it shouldn't matter to a skilled programmer. And
an unskilled programmer will make up for the TOOWTDI restriction in more
ways than you and I can imagine.
Also, Perl borrows a lot of its syntax from C, which Python (as far
as I have seen) does extremely little, if at all. So it's already
easier to program C-like in Perl, by design, even if Perl was as
"restrictive" as Python.
If Perl only borrowed a lot of it's syntax from C,
You can not borrow only a lot. Where is the rest coming from?
this wouldn't be a
problem. But it borrows a lot of it's syntax from sh as well,
Yeah, it has to come from somewhere. So either borrow it from some well
know "language", or make up a new syntax. It doesn't matter either way.
sometimes supporting both (because TMTOWTDI). If it had done one or
the other, it would have been a better language.
In your opinion, which sounds quite restrictive.
[ new things ] I will agree that adding new idioms from other programming paradigms
is a good thing (see <URL:
http://en.wikipedia.org/wiki/Programming_paradigm >). In theory, the
reason for that is that changing paradigms changes the set of things
you do, so you aren't adding more ways to do things, you're adding
more things to do.
The reality is that such changes often do introduce new ways to do
things that already exist.
Which is no problem at all. The new way is either better, or the old
way. One way will be picked up more. As I already stated: the more than
one way is more the combination of basic blocks.
There have already been threads where it's
been argued (by others - I just read them) that this is detrimental to
Python.
There are always language purists, who prefer a minimal set of
statements, 1001 restrictions, and move everything to libraries. Often I
have the idea that they don't use libraries at all, but prefer to write
their own, pure, language.
Right. But read <URL: http://www.python.org/peps/pep-3000.html > and
you'll see that many of the things that are now redundant are
scheduled to go away when we break backwards compatability. The
philosophy is still that "There should be one-- and preferably only
one --obvious way to do it." (from "import this"), even if we are
drifting from that in the current implementations.
:-) I will stay tuned, since I want to add Python to my skill set.
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
>>>>> "John" == John Bokma <po********@castleamber.com> writes: Nah, they aren't slow. They just have to worry about more things than
the Python developers.
John> Do you have references to this? I would love to see if
John> indeed 100 Python programmers do implement, say 5 CS tasks
John> faster compared to 100 Perl programmers, on average.
I am quite sure that given random sample of python and perl
programmers, the python programmers would be faster. Less thinking is
necessarily, no $ chars and generally less punctuation to worry about,
no error handling needed (exceptions take care of it automatically).
I would also venture to guess that random (adult) Python programmers
would be of higher skill level as far as programming in general goes
(know more languages, have a "good taste"...).
--
Ville Vainio http://tinyurl.com/2prnb
Leif Biberg Kristensen wrote: Leif K-Brooks skrev:
But Python's DB-API (the standard way to connect to an SQL database
from Python) makes escaping SQL strings automatic. You can do this:
cursor.execute('UPDATE foo SET bar=%s WHERE id=%s', ["foo'bar", 123])
So. I've been writing SQL queries in Python like this, using PostgreSQL
and psycopg:
cursor.execute("select * from foo where bar=%s" % baz)
Is that wrong, and how should I have been supposed to know that this is
bad syntax? No doc I have seen actually has told me so.
It's *wrong* for some value of "wrong" - it does potentially introduce a
SQL injection vulnerability into your code.
Suppose I provide as input into the baz variable
1; drop table foo
Your statement then becomes
select * from foo where bar=1; drop table foo
which is clearly not such a good idea. More sophisticated attackes are
possible, but this gives you the idea.
regards
Steve
--
Steve Holden +1 703 861 4237 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
John Bokma <po********@castleamber.com> writes: Mike Meyer wrote: John Bokma <po********@castleamber.com> writes: Mike Meyer wrote:
Depends on the problem. If it's one of the things for which Python
has an obvious solution (sort a list; split a string on whitespace;
pull select list elements based on a criteria of some kind; search a
file for lines with a given word in them; etc.) you'd get back the
same answer from almost all of them.
And what makes you doubt it would be different with Perl? :-D Perl's "There's more than one way to do it" attitude.
There's doesn't mean that you have to use or know them all. I think
every language here and there more ways to do something. And at a
broader scope, e.g. a simple algorithm, it doesn't matter that much
anymore.
Except that, as I said elsewhere, that having more than one way to do
it bloats the language processor and increases the semantic load on
the programmer. The best the programmer can do, as you imply, is to
ignore the extraneous methods. Then the poor programmer has to puzzle
over them every time they show up in someone else's code.
( sort @alist, split ' ', $astring, grep criteria, @list, etc )
In the one case where perl provides you two ways to do things, you
chose the one that doesn't solve the problem. You want map, not grep.
You think? Please read perldoc -f grep (and map).
I did, and could have sworn that grep modifed the list in place. Mia
culpa.
You also chose the wrong way to do things globally, by leaving off the
optional parens on the function invocations. That makes the list a
PITA to parse,
First of all, who cares? Not the programmer.
Of course the programmer doesn't care. They jyust have to deal with it
for the rather short development period. The *maintainer* cares,
though - as they have to deal with it for the life of the program.
But I doubt if you are correct; why is
OP PARAMETER, LIST
a PITA to parse, and
OP( PARAMETER, LIST )
not? I would even say that the former is easier to parse, since there is
no need for checking the ( and ) (and matching them).
Look at the *context*. You wrote
word word, word word, word, word word, word, word.
Unless you know what the words mean, this is nearly impossible to
parse out into proper perl expressions. Putting in the parens makes
it:
word(word, word), word(word, word), word(word, word), word.
This is trivial to parse into perl expressions without having to know
the meaning of any of the words.
in that you have to know the number of arguments to
each function in order to parse the list you provided.
It has been a while since I wrote a lexer, but uhm, you set up a rule?
LIST := ITEM
LIST := LIST,ITEM
Right. So is
item, item, item, item
one list or two seperated by an English-level comma?
(I made up the syntax, but I guess it's clear)
Consider the python version:
(alist.sort(), astring.split(), [x for x in alist if
criteria(x)])
( told you it was grep ;-) )
This list can be parsed by a machine. Given proper bindings for all
the variables, Python will turn it into a tuple.
What makes you think a machine can not parse Perl? I didn't get a Larry
Wall with my version of Perl :-D
What would it take to get Perl to parse the line you typed in?
N.B.: split(' ', $astring) is wrong as well. In this case, Perl
doesn't provide the right tool for the job; you have to build it from
parts.
You either misread your own problem specifications, or you should read
perldoc -f split (near the end, it starts with "As a special case," )
No, I missed the wart hiding under the "special case". How, pray tell,
do you do the equivalent of Python's string.split(' ') in Perl?
And those trivial variations are enough that you chose the wrong
ones. And you're (by your own admission) an experienced Perl
programmer.
And you don't even come close :-D.
No, one I blew. One you still got wrong.
One could say (and should) that the regular expression thingy in Perl
is a language on its own :-)
It is. For what Perl was designed for, having that be part of the
grammar of the language makes sense. For a general-purpose programming
language, I'm not so sure.
Same could be said of floating point numbers, or complex numbers, or
lists, dictionaries, etc. etc.
Right. And for each of those, there are languages that don't have them
as a built in type.
But you probably agree, that if speed is an issue, and the
programmer's skills are not the issue, that the only thing one can do
is code it in a different language (probably by another programmer).
I don't agree. The better alternative is to look for a faster
algorithm.
"The programmer's skills are not the issue"
Good point. I should have skipped the whole thing, as the programmers
skills are *never* not the issue.
[ skilled Perl programmers use similar or same idioms ]
My experience with Perl is just the opposite. Everytime I have to
maintain Perl code, I come across a different set of idioms - with no
obvious downside to them. You can, of course, define "skilled
programmers" as those who use your idiom set. This makes the set of
skilled Perl programmers very small. That few programmers are skilled
is a downside of TMTOWTDI, as the only time I see new idioms in Python
are newbies doing very odd things here. If I could have a peek at the Perl code you maintained I could tell you
(often by just seeing 3-5 lines) the status of the programmer who wrote
it :-)
So you'd either say you were wrong, or that my second contention was
right. Either one would be a bad side effect of TMTOWTDI.
As I wrote before, I have little experience with Python (one could say I
only read 2 books on it, and haven't written a stand alone piece of code
myself). But I have the feeling that the percentage of badly skilled
Perl programmers is way higher compared to Python for two reasons:
Quite some people have been "tweaking" CGI scripts
Quite some people "know" PHP, and hence consider themselves Perl
programmers.
Quite right. Neither is in the set of Perl things I maintain. The
first you can recognize by occasional style oddities in the middle of
the script. The second I'm not sure I'd recognize, as I don't do PHP.
part of the grammar of the language, and are a recent addition. It's
not clear how Python should evolve with them added to the language.
More fat: so I would say: learn to live with it. I only see advantages.
If you want a minimal set of operations, I recommend programming ARM
assembly, and don't go beyond ARM3 :-D.
You could also say more bloat. It's not a good thing. I don't want a
minimal set of operations; I want an orthogonal 1-1 coverage of
operations. That's will account for the least bloat in the processor,
the least load on the programmer, and the least bad code.
You either understand why something is bad at a given moment, or not.
If a language must make up for the understanding a programmer lacks,
something is very very wrong.
There's a difference between "making up for the understanding a
programmer lacks" and "handicapping the programmer". Missing gotos is
like missing explicit pointer manipulation.
Neither has ever handicapped me in any way. I remember how Sun claimed
that their language was safe from memory leaking. I could come up with a
simple example that leaked memory like crazy in a few seconds. Moreover,
garbage collection gives newbies the impression that everything is
handled automatically, and hence, they forget that other resources are
less unforgiven, and *have to be* released.
Other resources are less forgivving only if they are badly
designed. That means they *should* be released, but not *have to be*
released. Consider the file type in Python. It'll be closed after
you're through with it, guaranteed. However, garbage collection isn't
triggered by running out of file descriptors, so you *should* close
them.
Carefully designed
features added to the language (or restrictions removed from it) can
provide the same functionality as those features, without exposing
programmers to all the potential bugs that can occur when those
features are used.
A beginner will find a way. A nice example is garbage collection,
beginners think they don't have to think. And then suddenly things pop
up like: memory leaking, how are circular references handled, and oops,
suddenly things like weak references are needed. Add, things like
threading, and shared resources, resources that are limited in one way
or another and I doubt programming has become easier, or less error
prone.
Having dealt with memory leaks in C (and other such languages) for a
decade, I'd say programming is *much* easier than it would be if you
didn't have some form of garbage collection. Sure, programming in the
typical piss-poor threading model you find in popular languages and
etc. may be harder than programming in C without those things, but
it's still easier than programming in C *with* those things.
In fact, as the programming environment becomes more complicated, the
need for eliminating certain classes of errors by proper language
design increases, not decreases.
Has anyone ever did serious research to the number of bugs per 10k lines
for several programming languages?
Yeah. The LISP community did some research on garbage collection
vs. explicit allocate/free a couple of decades ago. The explicit
allocate/free methodology was found to be noticably more bug
prone. Like I said, those date from a couple of decades ago, so I've
lost the reference and google didn't turn anything up.
I remember to have read that air bags makes people drive more reckless.
I am quite convinced the same holds for programming languages. A
language can't cover your behind, so to speak.
Could you provide examples of what kind of behavior you're talking
about? What would be the analog of "driving more reckless" given that
I've got a garbage collector?
Of course, if you really believe that all the protections are a waste
of language spec, you should be writing assembler.
Adding something that doesn't extend the language and creates
potential bugs is a *mistake*. You run that risk every time you add
just another way to do something.
potential bugs is often equal to something people *think* a beginner is
going to make.
Yes, but potential bugs even more often turn up in *real*
programs. I've fixed enough bogus pointer/using free'd memory/memory
leaks in C to know that.
Of course not. The best you can do is provide one obvious way to do
things, and then hope most people find that.
Beginners get lost anyway, experienced programmers don't need it
I disagree. If there's not one obvious way to do things, experienced
programmers tend to choose the one they are most comfortable with, and
and if they are not hermits, they choose the ones they see the most
often used (unless it's Perl golf).
Which means they adopt to their subset of the community. Which means
that supporting code from another community will in practice require
learning a new programming language that happens to have a syntax they
are familiar with.
will have to work out what all the others mean. This has been my
experience with Perl and Common LISP, and from what I hear is true of
C++ as well.
If I look at which things I have to work out the most: libraries. It
sounds a lot like you want an extremely pure language. I almost get the
impression that you hand code almost everything yourself. It doesn't
matter how clean you make the language, the libraries will be fat. I
rarely have to "work out" a piece of Perl. The "there is more than one
way to do it" is much more about the combination of basic blocks. Perl
is like legos. What you want sounds a lot like legos that can instead of
round thingies to connect them uses triangles, so there is only one way
to stack them. Oh, and you want them dull grey.
Nope, I make heavy use of libraries. The Python standard library isn't
exemplary, and it some cases provides overlapping functionality. But
it does try to avoid that. It also tries to come with "batteries
included". You can get an aweful lot done in Python without ever going
to third party libraries. With Perl, you wind up going to CPAN for a
lot of things - which puts you back into TMTOWTDI land.
Haven't you heard the story of the professor who had seven identical
suites, one for each day of the week? It saved him the work of having
to decide what to wear each day. If you've ever been married, you may
be familiar with how much work that can involve given a large
wardrobe.
I want programming to be the professors route. I don't want to worry
about which for loop to use - I want there to be just one for loop, so
I take that one and *get on with solving the problem*. Having multiple
for loops (or other TMTOWTDI things) bloats the language
processor/library and increases the load on the programmer to no
benefit.
On the other hand, my experience with languages that provide one
obvious way to do things (Python, Scheme, Eiffel) is that experienced
programmers tend to find that way, and beginners quickly become
frustrated when they fight the language.
I wonder how much this has to do with how you learned Perl, and how you
learned Python.
True. The WWW was extant when I learned Python, so I could learn it by
reading the documention on the web site, and looking through the
library. Perl, on the other hand, I had to learn from the
documentation that shipped with it, and the library that shipped with
it. Come to think of it, Python has a larger library than Perl as
well. Given that, one would expect that the variance in idioms would
be larger than Perl, but it ain't.
>> My Perl evolved from very shell script like (lots of
>> backticks and passing around the full text of files)
> I am sure you can do that with Python too.
That hasn't happened in 9 years of Python.
That was not what I wrote: I am sure one can program that way in
Python too.
No, you said "one can do that with Python", leaving the word "that"
open to interpretation. I assumed you meant "migrate from writing sh
to writing C", which, as I said, hasn't happened.
But it doesn't mean that one can't do ;-)
I guess if you can write FORTRAN in anything, you can write C or sh in
anythin as well.
If you meant writing sh or C in Python, try it.
You talked about "lots of backticks and passing around etc." I am sure
one do things that are similar to backticks in Python, and also do the
passing around thing.
You'll find it clumsy and frustrating.
Yes, most languages make it clumsy and frustrating. Perl is a rare
exception.
Right - Perl makes writing ugly, slow code easy. Python makes it
hard. I think this makes python the superior language.
Python wasn't *designed* to make it comfortable to
write that way. Perl was - just a couple of more ways to do things.
But not clumsy, nor frustrating ;-) Perl is like a nice toolbox, and you
want Python to be just one of this tools. Moreover, written on it:
guarantee is void if used in any other way then stated in the manual.
Um, Perl isn't like a nice toolbox. Python is like a nice,
well-organized toolbox where everything is easy to find and use (well,
it used to be that way. It's gotten cluttered of late). Perl is like a
cluttered workbench with tools stacked on top of tools, with the
metric and english wrenches dumped in a heap - what ones aren't
scattered elsewhere on the workbench, anyway.
My Perl style changed
radically over the years. My python style has as well, but only
because the language has changed as time passed. In the cases where a
new construct/module hasn't been added, the idiom that was obvious
with Python 1.4 is still the right choice with Python 2.4. With Perl,
there's no obvious right choice,
To a newbie, nothing is obvious right, and a skilled programmer is able
to find the obvious right choice. You make it sound like the perl
community leaves people in the dark, and they have to find out what
everything means and does by trial and error. As I already wrote: the
more than one way is more often the *combination* of well known building
blocks.
Now you're trying to change the story. But I know better. Perl
provides multiple ways to do things at the syntactic level, and that's
the root of the problem. There are two iterative loops. There are two
conditional loops. There are two conditional execution statements, not
counting the variants that conditionalize the execution of a single
statement. There are two different syntaxes for invoking builtin
functions (though I don't think one of them works on user-defined
functions; never tried it).
A langauge can make it easy to write ugly code, or it can make it hard
to write ugly code.
But who writes this code? The language, or the programmer? A programmer
who writes ugly Perl code is suddenly going to be a skilled Python
programmer? Are you serious?
No, he's not going to be a skilled Python programmer. But you avoiding
ugly code in Python doesn't take a skilled programmer. It's not clear
that even skilled Perl programmers can avoid writing code that some
other community won't find ugly.
After all, "You can write FORTRAN in any
language(*)". If I have to maintain the code, I'd *much* prefer that
the language make it hard to write ugly code, as I'm that much less
likely to get ugly code to maintain.
Nonsense.
I make that claim based on experiene maintaing both Perl and Python
code. What basis do you have for calling it nonsense.
TMTOWTDI makes it easy to write
ugly code. TOOWTDI makes it hard to write ugly code.
And the funny thing is: it shouldn't matter to a skilled programmer. And
an unskilled programmer will make up for the TOOWTDI restriction in more
ways than you and I can imagine.
I don't agree. It doesn't say "There's one obvious to the skilled
programmer way to do it." It says "There's one obvious way to do it."
And it's usually obvious to anyone who's read the tutorials. The
newbie postings on c.l.python back that up - an amazingly small
percentage contain code that does things in the non-obvious way. A lot
of them are trying to do baroque things, usually because they are
trying to write in their last language. They wind up asking on the
list because they get frustrated trying to write something that isn't
Python in Python. If Python allowed all those things to work, they'd
wind up writing ugly code without having a clue that they had done
anything to be ashamed of. It's all to the good.
Also, Perl borrows a lot of its syntax from C, which Python (as far
as I have seen) does extremely little, if at all. So it's already
easier to program C-like in Perl, by design, even if Perl was as
"restrictive" as Python.
If Perl only borrowed a lot of it's syntax from C,
You can not borrow only a lot. Where is the rest coming from?
sh.
this wouldn't be a
problem. But it borrows a lot of it's syntax from sh as well,
Yeah, it has to come from somewhere. So either borrow it from some well
know "language", or make up a new syntax. It doesn't matter either way.
But Perl didn't do either one of those. It borrowed from *two*
languages, including overlapping functionality. Then it threw in a
bunch of stuff from other places, possibly fabricated from thin air -
again adding overlapping functionality.
sometimes supporting both (because TMTOWTDI). If it had done one or
the other, it would have been a better language.
In your opinion, which sounds quite restrictive.
It's no more restrictive than not having goto or explicit pointers.
[ new things ] I will agree that adding new idioms from other programming paradigms
is a good thing (see <URL:
http://en.wikipedia.org/wiki/Programming_paradigm >). In theory, the
reason for that is that changing paradigms changes the set of things
you do, so you aren't adding more ways to do things, you're adding
more things to do.
The reality is that such changes often do introduce new ways to do
things that already exist.
Which is no problem at all. The new way is either better, or the old
way. One way will be picked up more. As I already stated: the more than
one way is more the combination of basic blocks.
Nope. The new things in Python are distinct new things, not just new
combinations of basic blocks. For instance, list comprehensions
replace both map and filter. Those are all three basic blocks.
If the new way isn't better, it shouldn't have been added. It just
adds bloat to the language processor and mental load on the
programmer. There have already been threads where it's
been argued (by others - I just read them) that this is detrimental to
Python.
There are always language purists, who prefer a minimal set of
statements, 1001 restrictions, and move everything to libraries. Often I
have the idea that they don't use libraries at all, but prefer to write
their own, pure, language.
Well, I'm certainly not that language purist. I like a minimal set of
statements that do the job, as redundancies just make my job harder. I
hate restrictions - and consider removing restrictions to be an
excellent way to extend the functionality of a language. Compared to
other languages, Python is a joy because of the lack of restrictions:
functions are first-class objects; built-in types can be inheritied
from; user defined classes can be called like functions; in fact, most
of the built-in syntax elements can be made to do something usefull on
user-defined functions. Sure, it's missing some things - like there's
no way to define new operators - but it has fewer restrictions than
most of the languages I've worked with.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Ville Vainio wrote: >> "John" == John Bokma <po********@castleamber.com> writes: >> Nah, they aren't slow. They just have to worry about more
>> things than the Python developers.
John> Do you have references to this? I would love to see if
John> indeed 100 Python programmers do implement, say 5 CS tasks
John> faster compared to 100 Perl programmers, on average.
I am quite sure
I am sorry, "quite sure" doesn't count :-D
no error handling needed (exceptions take care of it automatically).
Who told you Perl can't do exceptions?
I would also venture to guess that random (adult) Python programmers
would be of higher skill level as far as programming in general goes
(know more languages, have a "good taste"...).
I already gave two very good reasons why this is the case.
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Mike Meyer wrote: John Bokma <po********@castleamber.com> writes:
Mike Meyer wrote: John Bokma <po********@castleamber.com> writes:
Mike Meyer wrote:
> Depends on the problem. If it's one of the things for which Python
> has an obvious solution (sort a list; split a string on
> whitespace; pull select list elements based on a criteria of some
> kind; search a file for lines with a given word in them; etc.)
> you'd get back the same answer from almost all of them.
And what makes you doubt it would be different with Perl? :-D
Perl's "There's more than one way to do it" attitude. There's doesn't mean that you have to use or know them all. I think
every language here and there more ways to do something. And at a
broader scope, e.g. a simple algorithm, it doesn't matter that much
anymore.
Except that, as I said elsewhere, that having more than one way to do
it bloats the language processor
do you really think that for / foreach and things like if / unless bloat
a language processor? I think you take your "pure programming lanuage"
way to far, and really don't understand your choice of Python in your
crusade.
and increases the semantic load on
the programmer. The best the programmer can do, as you imply, is to
ignore the extraneous methods.
I am curious of a list of extraneous methods in Perl (more about the
size by the way)
Then the poor programmer has to puzzle
over them every time they show up in someone else's code.
A poorly skilled programmer has to puzzle about a lot of more things. Or
you think list comprehension (sp?) and all the tricks with it are clear?
or the and or trick? I just had a glance on Python, but what probably to
you is one clear path isn't clear to me yet. And I doubt that can all be
blamed on unpure new Python.
You also chose the wrong way to do things globally, by leaving off
the optional parens on the function invocations. That makes the list
a PITA to parse, First of all, who cares? Not the programmer.
Of course the programmer doesn't care. They jyust have to deal with it
for the rather short development period. The *maintainer* cares,
though - as they have to deal with it for the life of the program.
You keep confusing me: are you talking about the programmer who designs
/ maintains the parser? I guess yes. I talk about the programmers who
use the language.
But I doubt if you are correct; why is
OP PARAMETER, LIST
a PITA to parse, and
OP( PARAMETER, LIST )
not? I would even say that the former is easier to parse, since there
is no need for checking the ( and ) (and matching them).
Look at the *context*. You wrote
word word, word word, word, word word, word, word.
Yes, since it where several examples on one line. You gave several
problems. The etc. was a kind of give away.
N.B.: split(' ', $astring) is wrong as well. In this case, Perl
doesn't provide the right tool for the job; you have to build it
from parts.
You either misread your own problem specifications, or you should
read perldoc -f split (near the end, it starts with "As a special
case," )
No, I missed the wart hiding under the "special case". How, pray tell,
do you do the equivalent of Python's string.split(' ') in Perl?
split /PATTERN/,EXPR (from perldoc -f split), so:
^^^^^^^^^
split / /, $string
No, one I blew. One you still got wrong.
Which one?
Same could be said of floating point numbers, or complex numbers, or
lists, dictionaries, etc. etc.
Right. And for each of those, there are languages that don't have them
as a built in type.
True, perl has no built in complex numbers.
If I could have a peek at the Perl code you maintained I could tell
you (often by just seeing 3-5 lines) the status of the programmer who
wrote it :-)
So you'd either say you were wrong, or that my second contention was
right. Either one would be a bad side effect of TMTOWTDI.
I am right, and you are wrong ;-)
Quite some people have been "tweaking" CGI scripts
Quite some people "know" PHP, and hence consider themselves Perl
programmers.
Quite right. Neither is in the set of Perl things I maintain.
Does that matter? What matters is what are the skills and background of
the Perl programmer who wrote the code you maintain.
part of the grammar of the language, and are a recent addition. It's
not clear how Python should evolve with them added to the language.
More fat: so I would say: learn to live with it. I only see
advantages. If you want a minimal set of operations, I recommend
programming ARM assembly, and don't go beyond ARM3 :-D.
You could also say more bloat. It's not a good thing. I don't want a
minimal set of operations; I want an orthogonal 1-1 coverage of
operations.
ARM assembly, told you ;-)
That's will account for the least bloat in the processor,
the least load on the programmer, and the least bad code.
ARM, maybe even ARM2. And the last thing depends on you.
seconds. Moreover, garbage collection gives newbies the impression
that everything is handled automatically, and hence, they forget that
other resources are less unforgiven, and *have to be* released.
Other resources are less forgivving only if they are badly
designed.
Sure, a resource outside of your program that has certain limits is
badly designed. Yup, a database for example.
That means they *should* be released, but not *have to be*
released.
Trust me: they *have to be* released.
Consider the file type in Python. It'll be closed after
you're through with it, guaranteed. However, garbage collection isn't
triggered by running out of file descriptors, so you *should* close
them.
Or otherwise?
A beginner will find a way. A nice example is garbage collection,
beginners think they don't have to think. And then suddenly things
pop up like: memory leaking, how are circular references handled, and
oops, suddenly things like weak references are needed. Add, things
like threading, and shared resources, resources that are limited in
one way or another and I doubt programming has become easier, or less
error prone.
Having dealt with memory leaks in C (and other such languages) for a
decade, I'd say programming is *much* easier than it would be if you
didn't have some form of garbage collection.
Easier, sure. But does it turn beginners in rock solid programmers?
Has anyone ever did serious research to the number of bugs per 10k
lines for several programming languages?
Yeah. The LISP community did some research on garbage collection
vs. explicit allocate/free a couple of decades ago. The explicit
allocate/free methodology was found to be noticably more bug
prone. Like I said, those date from a couple of decades ago, so I've
lost the reference and google didn't turn anything up.
So they looked close at one aspect of the language. But you think that
10k lines of, say Java, has less bugs then 10k lines of C?
I remember to have read that air bags makes people drive more
reckless. I am quite convinced the same holds for programming
languages. A language can't cover your behind, so to speak.
Could you provide examples of what kind of behavior you're talking
about? What would be the analog of "driving more reckless" given that
I've got a garbage collector?
I already gave that one: forgetting to release resources which are not
unlimited.
Of course, if you really believe that all the protections are a waste
of language spec, you should be writing assembler.
Since programming languages have several more advantages then
"protecting" and "guiding" and "limiting" programmers, why?
potential bugs is often equal to something people *think* a beginner
is going to make.
Yes, but potential bugs even more often turn up in *real*
programs. I've fixed enough bogus pointer/using free'd memory/memory
leaks in C to know that.
And I am sure that you fixed enough bugs in the same *real* programs
that were in no way related to this. I have fixed enough bugs in Perl,
Java, etc, to know that "life will find a way", so to speak.
and if they are not hermits, they choose the ones they see the most
often used (unless it's Perl golf).
Which means they adopt to their subset of the community. Which means
that supporting code from another community will in practice require
learning a new programming language that happens to have a syntax they
are familiar with.
What makes you think there are isolated communities?
blocks. Perl is like legos. What you want sounds a lot like legos
that can instead of round thingies to connect them uses triangles, so
there is only one way to stack them. Oh, and you want them dull grey.
Nope, I make heavy use of libraries. The Python standard library isn't
exemplary, and it some cases provides overlapping functionality.
I haven't seen a library that doesn't :-D
But
it does try to avoid that. It also tries to come with "batteries
included". You can get an aweful lot done in Python without ever going
to third party libraries. With Perl, you wind up going to CPAN for a
lot of things - which puts you back into TMTOWTDI land.
How long haven't you been in touch with Perl?
I want programming to be the professors route. I don't want to worry
about which for loop to use - I want there to be just one for loop, so
I take that one and *get on with solving the problem*. Having multiple
for loops (or other TMTOWTDI things) bloats the language
processor/library and increases the load on the programmer to no
benefit.
I use either for or while.
True. The WWW was extant when I learned Python, so I could learn it by
reading the documention on the web site, and looking through the
library. Perl, on the other hand, I had to learn from the
documentation that shipped with it, and the library that shipped with
it. Come to think of it, Python has a larger library than Perl as
well.
How did you measure this? And which distribution of Perl are you talking
about?
Yes, most languages make it clumsy and frustrating. Perl is a rare
exception.
Right - Perl makes writing ugly,
Nope, the programmer does that.
slow code easy. Python makes it
hard. I think this makes python the superior language.
And I think that there is the main problem in your whole story. You
think this is a quest for superiority. It isn't.
what everything means and does by trial and error. As I already
wrote: the more than one way is more often the *combination* of well
known building blocks.
Now you're trying to change the story. But I know better. Perl
provides multiple ways to do things at the syntactic level, and that's
the root of the problem. There are two iterative loops.
for and foreach?
There are two conditional loops.
while and do while?
There are two conditional execution statements, not
if and unless?
counting the variants that conditionalize the execution of a single
statement.
? :, and and or
( hmmm, and or trick ;-) )
There are two different syntaxes for invoking builtin
functions (though I don't think one of them works on user-defined
functions; never tried it).
Uhm, you mean with and without () ? Yes, you can do that with user-
defined functions.
But if this all bothers you *this* much, I am afraid that the problem is
really behind the keyboard :-) But who writes this code? The language, or the programmer? A
programmer who writes ugly Perl code is suddenly going to be a
skilled Python programmer? Are you serious?
No, he's not going to be a skilled Python programmer. But you avoiding
ugly code in Python doesn't take a skilled programmer.
Funny, I saw recently something I consider ugly code, written by someone
I thought was a skilled programmer. After all, "You can write FORTRAN in any
language(*)". If I have to maintain the code, I'd *much* prefer that
the language make it hard to write ugly code, as I'm that much less
likely to get ugly code to maintain.
Nonsense.
I make that claim based on experiene maintaing both Perl and Python
code. What basis do you have for calling it nonsense.
If you are talking about maintaining your own code, maybe you are right.
But I claim that it's nonense that code written by other people, with
clearly different programming skills compared to the maintainer are a
PITA, no matter what language is used. TMTOWTDI makes it easy to write
ugly code. TOOWTDI makes it hard to write ugly code.
And the funny thing is: it shouldn't matter to a skilled programmer.
And an unskilled programmer will make up for the TOOWTDI restriction
in more ways than you and I can imagine.
I don't agree. It doesn't say "There's one obvious to the skilled
programmer way to do it." It says "There's one obvious way to do it."
Yup, to pick a tool out of a organized toolbox. Which is fine if that's
the only job involved. Programming, or as I see it, is not about picking
tools out of a box, but combining them.
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
John Bokma <po********@castleamber.com> writes: Mike Meyer wrote: John Bokma <po********@castleamber.com> writes: Mike Meyer wrote:
John Bokma <po********@castleamber.com> writes:
> Mike Meyer wrote:
>> Depends on the problem. If it's one of the things for which Python
>> has an obvious solution (sort a list; split a string on
>> whitespace; pull select list elements based on a criteria of some
>> kind; search a file for lines with a given word in them; etc.)
>> you'd get back the same answer from almost all of them.
> And what makes you doubt it would be different with Perl? :-D
Perl's "There's more than one way to do it" attitude.
There's doesn't mean that you have to use or know them all. I think
every language here and there more ways to do something. And at a
broader scope, e.g. a simple algorithm, it doesn't matter that much
anymore. Except that, as I said elsewhere, that having more than one way to do
it bloats the language processor
do you really think that for / foreach and things like if / unless bloat
a language processor? I think you take your "pure programming lanuage"
way to far, and really don't understand your choice of Python in your
crusade.
I don't think I take it to far. All my experience dealing with
languages that took the opposite tack (i.e. - Perl and Common LISP)
demonstrate that such things are a bad idea.
Python got chosen for this discussion for two reasons. One, we're
posting in comp.lang.python. Two, part of the Python philosophy -
which you can get by doing "import this" - is:
There should be one-- and preferably only one --obvious way to do it.
and increases the semantic load on
the programmer. The best the programmer can do, as you imply, is to
ignore the extraneous methods.
I am curious of a list of extraneous methods in Perl (more about the
size by the way)
Methods isn't a very good word choice on my part, as it has to many
meanings. But saying "extraneous ways to do it" is a bit wordy. I
already gave you one such list, covering just the syntactic elements
of the language.
Then the poor programmer has to puzzle
over them every time they show up in someone else's code.
A poorly skilled programmer has to puzzle about a lot of more things. Or
you think list comprehension (sp?) and all the tricks with it are clear?
or the and or trick? I just had a glance on Python, but what probably to
you is one clear path isn't clear to me yet. And I doubt that can all be
blamed on unpure new Python.
Correct - newbies have to puzzle about a lot of things. A good
language design won't add to that set of things without a good
reason. Adding features because you can is adding things to puzzle
about without a good reason.
List comprehensions are part of that "new, unpure python". They
duplicate functionality that was already in the language. Of course,
they are a lot clearer than what was there, and if Python were a
research language rather than a production language, map, filter and
lambda would be gone.
No, one I blew. One you still got wrong.
Which one?
Faling to put in the parens that would have distinguished the argument
lists from the list of operators.
Actually, it's not clear the grep was right either. The return value
of grep (and map) isn't always the right thing. You have to force the
return value into a list context to get the right result. Oh
well. Just one more thing for the programmer to worry about.
If I could have a peek at the Perl code you maintained I could tell
you (often by just seeing 3-5 lines) the status of the programmer who
wrote it :-)
So you'd either say you were wrong, or that my second contention was
right. Either one would be a bad side effect of TMTOWTDI.
I am right, and you are wrong ;-)
In which case, I'm right in claiming that having more than one way to
do things fragments the community - which is *still* a bad thing for
the people writing the language.
Quite some people have been "tweaking" CGI scripts
Quite some people "know" PHP, and hence consider themselves Perl
programmers.
Quite right. Neither is in the set of Perl things I maintain.
Does that matter? What matters is what are the skills and background of
the Perl programmer who wrote the code you maintain.
They all come from different backgrounds, which is why they all use
different subsets of the language. Having a language that makes such
division of the community easy is a *bad* thing. Look at the history
of LISP to see why.
part of the grammar of the language, and are a recent addition. It's
not clear how Python should evolve with them added to the language.
More fat: so I would say: learn to live with it. I only see
advantages. If you want a minimal set of operations, I recommend
programming ARM assembly, and don't go beyond ARM3 :-D.
You could also say more bloat. It's not a good thing. I don't want a
minimal set of operations; I want an orthogonal 1-1 coverage of
operations.
ARM assembly, told you ;-)
That's not a coverage. Unless ARM assembly includes garbage
collection, dictionaries and similar things.
seconds. Moreover, garbage collection gives newbies the impression
that everything is handled automatically, and hence, they forget that
other resources are less unforgiven, and *have to be* released.
Other resources are less forgivving only if they are badly
designed.
Sure, a resource outside of your program that has certain limits is
badly designed. Yup, a database for example.
Nope, the resource is the interface to the database. If it's
well-designed, then you won't have to worry about shutting down the
connection. It'll get shut down when it's garbage collected.
That means they *should* be released, but not *have to be*
released.
Trust me: they *have to be* released.
Then the interface is badly designed.
Consider the file type in Python. It'll be closed after
you're through with it, guaranteed. However, garbage collection isn't
triggered by running out of file descriptors, so you *should* close
them.
Or otherwise?
Depends on how the garbage collector is implemented. In CPython, with
reference counting, the files will get closed as soon as the
descriptor is no longer referenced, and nobody will be any the
wiser. In Jython, which used the Java garbage collector, you can run
out of file descriptors, meaning your file opens will start failing. I
have no idea what IronPython does.
You *should* close the files. There are external conditions that make
not doing so perfectly safe. For instance, you could know your code
will only be run on CPython, or you could know that it will only be
run on platforms with many file descriptors and you only use a few.
As a program maintainer, I'll tell you the conditions will almost
certainly change in ways you don't expect, and you *should* close the
files.
A beginner will find a way. A nice example is garbage collection,
beginners think they don't have to think. And then suddenly things
pop up like: memory leaking, how are circular references handled, and
oops, suddenly things like weak references are needed. Add, things
like threading, and shared resources, resources that are limited in
one way or another and I doubt programming has become easier, or less
error prone.
Having dealt with memory leaks in C (and other such languages) for a
decade, I'd say programming is *much* easier than it would be if you
didn't have some form of garbage collection.
Easier, sure. But does it turn beginners in rock solid programmers?
It means they never make errors like using free'd memory, or failing
to free allocated memory. So in that since, yes, they are rock solid.
Has anyone ever did serious research to the number of bugs per 10k
lines for several programming languages?
Yeah. The LISP community did some research on garbage collection
vs. explicit allocate/free a couple of decades ago. The explicit
allocate/free methodology was found to be noticably more bug
prone. Like I said, those date from a couple of decades ago, so I've
lost the reference and google didn't turn anything up.
So they looked close at one aspect of the language. But you think that
10k lines of, say Java, has less bugs then 10k lines of C?
Nah. Then again, counting lines of code is a silly thing to do. You
think 10K lines of C does as much as 10K lines of Java? The crucial
question isn't how many bugs you get per line of code, it's how many
bugs you get to achieve a given functionality. You can improve this
number by cutting down the number of bugs per line of code, or by
cutting down the number of lines of code needed to acheive a given
functionality. Modern programming environments clearly improve the
latter.
Of course, you can take terseness to far. Just ask anyone who's ever
written TECO or APL.
I remember to have read that air bags makes people drive more
reckless. I am quite convinced the same holds for programming
languages. A language can't cover your behind, so to speak.
Could you provide examples of what kind of behavior you're talking
about? What would be the analog of "driving more reckless" given that
I've got a garbage collector?
I already gave that one: forgetting to release resources which are not
unlimited.
And I already pointed out that if that's a serious problem, your air
bags are poorly designed. The wrapper around the resource should hide
that problem for you. Can you come up with another one?
potential bugs is often equal to something people *think* a beginner
is going to make.
Yes, but potential bugs even more often turn up in *real*
programs. I've fixed enough bogus pointer/using free'd memory/memory
leaks in C to know that.
And I am sure that you fixed enough bugs in the same *real* programs
that were in no way related to this. I have fixed enough bugs in Perl,
Java, etc, to know that "life will find a way", so to speak.
We both agree you're always going to have bugs. I think that
programming languages designed to eliminate whole classes of bugs are
good thing, because bugs are a bad thing. You seem to argue that
because we can't elimnate all bugs, we shouldn't eliminate any. That's
simply silly.
and if they are not hermits, they choose the ones they see the most
often used (unless it's Perl golf).
Which means they adopt to their subset of the community. Which means
that supporting code from another community will in practice require
learning a new programming language that happens to have a syntax they
are familiar with.
What makes you think there are isolated communities?
Let's see. LISP - some of the communities were MacLISP, InterLISP,
Zeta LISP, and Standard LISP. There are certainly others I
forgot. Perl - they don't have names, they just show up in the code I
have to maintain. C++ - all I have is hearsay.
But
it does try to avoid that. It also tries to come with "batteries
included". You can get an aweful lot done in Python without ever going
to third party libraries. With Perl, you wind up going to CPAN for a
lot of things - which puts you back into TMTOWTDI land.
How long haven't you been in touch with Perl?
Oh, are you claiming that PERL ships with HTML and XML parsers, SMTP
clients and web servers in the standard library? That's odd - all the
packages I see seem to want to install those things from CPAN.
I want programming to be the professors route. I don't want to worry
about which for loop to use - I want there to be just one for loop, so
I take that one and *get on with solving the problem*. Having multiple
for loops (or other TMTOWTDI things) bloats the language
processor/library and increases the load on the programmer to no
benefit.
I use either for or while.
You never use the Perl foreach loop? That doesn't sound like a skilled
Perl programmer to me.
True. The WWW was extant when I learned Python, so I could learn it by
reading the documention on the web site, and looking through the
library. Perl, on the other hand, I had to learn from the
documentation that shipped with it, and the library that shipped with
it. Come to think of it, Python has a larger library than Perl as
well.
How did you measure this? And which distribution of Perl are you talking
about?
By looking at the functionality installed programs used from third
parties (i.e. - CPAN in recent version) vs. what they used from the
standard library. And in Perl 4 and 5.
Yes, most languages make it clumsy and frustrating. Perl is a rare
exception.
Right - Perl makes writing ugly,
Nope, the programmer does that.
No, the programme writes the ugly code. Perl makes it easy.
slow code easy. Python makes it
hard. I think this makes python the superior language.
And I think that there is the main problem in your whole story. You
think this is a quest for superiority. It isn't.
What? You're not trying to find the superior tool for the application
domain? Then what *are* you doing?
But if this all bothers you *this* much, I am afraid that the problem is
really behind the keyboard :-)
No, what bothers me *this* much is that every time I have to maintain
a Perl program, I have to learn somebody else's subset/idioms/etc of
the language. "All this" is the cause of that. After all, "You can write FORTRAN in any
language(*)". If I have to maintain the code, I'd *much* prefer that
the language make it hard to write ugly code, as I'm that much less
likely to get ugly code to maintain.
Nonsense.
I make that claim based on experiene maintaing both Perl and Python
code. What basis do you have for calling it nonsense.
If you are talking about maintaining your own code, maybe you are right.
But I claim that it's nonense that code written by other people, with
clearly different programming skills compared to the maintainer are a
PITA, no matter what language is used.
Yes, but the language influences how much of a PITA it is, and how
often it's a PITA. I prefer languages that make it less and infrequent
to languages that make it more and frequent. TMTOWTDI makes it easy to write
ugly code. TOOWTDI makes it hard to write ugly code.
And the funny thing is: it shouldn't matter to a skilled programmer.
And an unskilled programmer will make up for the TOOWTDI restriction
in more ways than you and I can imagine.
I don't agree. It doesn't say "There's one obvious to the skilled
programmer way to do it." It says "There's one obvious way to do it."
Yup, to pick a tool out of a organized toolbox. Which is fine if that's
the only job involved. Programming, or as I see it, is not about picking
tools out of a box, but combining them.
Right. A good language will have an obvious tool for each part of the
combination, so you don't spend time worrying about picking the right
tools - the right choices are obvious. A bad language will have more
than one tool for many parts of the combination, so you wind up
wasting time on which of n interchangable tools is the right one
instead of actually solving the problem at hand.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
>>>>> "John" == John Bokma <po********@castleamber.com> writes:
John> Who told you Perl can't do exceptions?
Back when I learned (heh, I never 'really' learned, but knew enough to
write programs in it) perl, almost every function call was followed by
or die("blah");
i.e. the user had to check the error code. If the function would have
raised an exception instead, such check would be redundant because it
would never be executed.
In Python, all error conditions raise exceptions. If python
'supported' exceptions but standard library functions didn't raise
them, the feature would not be worth much.
--
Ville Vainio http://tinyurl.com/2prnb
Steve Holden <st***@holdenweb.com> wrote: Your statement then becomes
select * from foo where bar=1; drop table foo
which is clearly not such a good idea.
I'm sure Steve is very well aware of this and was just providing a
simple and obvious example, nevertheless it might be worth pointing
out that anyody who connects their web application to their database
as a user that has DROP TABLE privileges, would clearly be in need of
a lot more help on basic security concepts than just advice on
choosing a programming language.
This goes back to the point somebody made earlier on in the thread -
many web applications can be implemented as fairly simple wrappers
around properly designed databases. "Properly designed" includes
giving some thought to table ownership and privileges.
Mike Meyer wrote: John Bokma <po********@castleamber.com> writes: Mike Meyer wrote:
[ snip ]
do you really think that for / foreach and things like if / unless
bloat a language processor? I think you take your "pure programming
lanuage" way to far, and really don't understand your choice of
Python in your crusade.
I don't think I take it to far. All my experience dealing with
languages that took the opposite tack (i.e. - Perl and Common LISP)
demonstrate that such things are a bad idea.
Funny, quite a lot of Perl programmers consider using unless instead of
if ! a good idea. And if a programmer is not able to grasp the meaning
of unless if he sees it the first time, he should be able to look it up.
And if a programmer says that it burdens his mental processes, or slows
him down, I hope I never have to work with him/her and/or maintain
his/her code.
and increases the semantic load on
the programmer. The best the programmer can do, as you imply, is to
ignore the extraneous methods.
I am curious of a list of extraneous methods in Perl (more about the
size by the way)
Methods isn't a very good word choice on my part, as it has to many
meanings. But saying "extraneous ways to do it" is a bit wordy. I
already gave you one such list, covering just the syntactic elements
of the language.
I must have missed it, since I didn't see it.
A poorly skilled programmer has to puzzle about a lot of more things.
Or you think list comprehension (sp?) and all the tricks with it are
clear? or the and or trick? I just had a glance on Python, but what
probably to you is one clear path isn't clear to me yet. And I doubt
that can all be blamed on unpure new Python.
Correct - newbies have to puzzle about a lot of things. A good
language design won't add to that set of things without a good
reason. Adding features because you can is adding things to puzzle
about without a good reason.
I doubt that features have been added to Perl just because. Even ones
that look like it, unless for example, have an excellent use, it makes
the code more readable.
No, one I blew. One you still got wrong.
Which one?
Faling to put in the parens that would have distinguished the argument
lists from the list of operators.
*sigh* you gave a list of problems, I replied by putting all answers on
one line, with () around them, and commas between them. I was not
constructing a tuple, or a list in Perl
Actually, it's not clear the grep was right either. The return value
of grep (and map) isn't always the right thing.
If you want to have a list of results and you assign it to a scalar, you
are doing the wrong thing.
But the bottom line is: I gave you answers to all, except one, of your
problems, you think my set of answers is a kind of Perl list, you
thought the grep was plainly wrong, and I guess you are not comfortable
with split.
And this gives me the feeling that you either haven't been using Perl
for over 4 years, or was never got beyond the absolute beginner level.
In the latter case I can imagine that you are overwhelmed by Perl. As
would one by any language.
If I could have a peek at the Perl code you maintained I could tell
you (often by just seeing 3-5 lines) the status of the programmer
who wrote it :-)
So you'd either say you were wrong, or that my second contention was
right. Either one would be a bad side effect of TMTOWTDI.
I am right, and you are wrong ;-)
In which case, I'm right in claiming that having more than one way to
do things fragments the community - which is *still* a bad thing for
the people writing the language.
It fragments it in a way every programming community is fragmented:
absoluut beginner, beginner, junior, senior, guru.
ARM assembly, told you ;-)
That's not a coverage. Unless ARM assembly includes garbage
collection, dictionaries and similar things.
In a pure language such things are in the library.
Easier, sure. But does it turn beginners in rock solid programmers?
It means they never make errors like using free'd memory, or failing
to free allocated memory. So in that since, yes, they are rock solid.
LOL, but they will make other mistakes. Otherwise, I am really curious,
can you show a publication that shows that the number of bugs /
application is much smaller when a garbage collection language is used,
and one that does bounds checking?
So they looked close at one aspect of the language. But you think
that 10k lines of, say Java, has less bugs then 10k lines of C?
Nah. Then again, counting lines of code is a silly thing to do. You
think 10K lines of C does as much as 10K lines of Java?
Depends of course, but rephrase: we take 10 programs of C, 10 of Java,
each which are equal (except in the number of bugs). You think Java has
less?
The crucial
question isn't how many bugs you get per line of code, it's how many
bugs you get to achieve a given functionality. You can improve this
number by cutting down the number of bugs per line of code, or by
cutting down the number of lines of code needed to acheive a given
functionality. Modern programming environments clearly improve the
latter.
But are there now less bugs compared to a few years ago? Are, say, Java
programs in general more bug free?
And I am sure that you fixed enough bugs in the same *real* programs
that were in no way related to this. I have fixed enough bugs in
Perl, Java, etc, to know that "life will find a way", so to speak.
We both agree you're always going to have bugs. I think that
programming languages designed to eliminate whole classes of bugs are
good thing, because bugs are a bad thing. You seem to argue that
because we can't elimnate all bugs, we shouldn't eliminate any. That's
simply silly.
Nope, I got the impression from you that Python restricts programmers,
so they make less mistakes. They can't make mistakes of "whole classes",
but that doesn't mean they are suddenly good programmers.
If I considered garbage collection bad, I would say so. But like airbags
doesn't improve the driving skills of someone, so doesn't all kind of
restrictions turn bad programmers suddenly in good programmers.
Moreover, good programmers rarely need to be restricted. But I don't see
garbage collection as an anti-memory-leak restriction (which it can't be
in all cases) but as a time saver.
What makes you think there are isolated communities?
Let's see. LISP - some of the communities were MacLISP, InterLISP,
Zeta LISP, and Standard LISP. There are certainly others I
forgot. Perl - they don't have names, they just show up in the code I
have to maintain.
But is that because there are separate communities, or because there are
different skill levels? Moreover, I hope that "have to maintain" was
"had to maintain (some time ago)", because your Perl skills are more
than lacking.
How long haven't you been in touch with Perl?
Oh, are you claiming that PERL ships with HTML and XML parsers, SMTP
clients and web servers in the standard library?
Which Perl? ActiveState Perl does indeed come with HTML, and XML
parsers, SMTP, etc, clients. Web server(s), I have no idea, haven't
needed a Perl webserver, I doubt it comes with AS Perl.
That's odd - all the
packages I see seem to want to install those things from CPAN.
Is there such a centralized place for libraries for Python? I use either for or while.
You never use the Perl foreach loop? That doesn't sound like a skilled
Perl programmer to me.
I already stated you have little Perl experience. Now I have to change
that to *extremely* little Perl experience.
So it seems I am right: the overwhelming effect of "many ways" is mainly
seen by absolute beginners, who are able to make up many ways, even if
there is just one or two :-D. How did you measure this? And which distribution of Perl are you
talking about?
By looking at the functionality installed programs used from third
parties (i.e. - CPAN in recent version) vs. what they used from the
standard library. And in Perl 4 and 5.
Perl 4? Even Perl 5 is almost 11 years old. Which version of Perl 5 are
you talking about? Right - Perl makes writing ugly,
Nope, the programmer does that.
No, the programme writes the ugly code. Perl makes it easy.
So, and who is to blame? Would you trust a programmer who can only write
code in a certain way because he is restricted by the langauge to do so?
And do you really think his/her code would be better compared to a
skilled programmer? And I think that there is the main problem in your whole story. You
think this is a quest for superiority. It isn't.
What? You're not trying to find the superior tool for the application
domain? Then what *are* you doing?
Programming, in a skilled way. There is no ultimate superior tool. Why
do you think I am learning Python? Because I found the holy grail? Or
that I just want another way to do things? But if this all bothers you *this* much, I am afraid that the problem
is really behind the keyboard :-)
No, what bothers me *this* much is that every time I have to maintain
a Perl program, I have to learn somebody else's subset/idioms/etc of
the language. "All this" is the cause of that.
No. If this was crossposted in a Perl group, by now quite a lot of
people would have pointed you out, probably in a less nice way, that
your Perl skills are of a person who hasn't even gone beyond the first
few chapters of "Learning Perl". Yup, to pick a tool out of a organized toolbox. Which is fine if
that's the only job involved. Programming, or as I see it, is not
about picking tools out of a box, but combining them.
Right. A good language will have an obvious tool for each part of the
combination, so you don't spend time worrying about picking the right
tools - the right choices are obvious. A bad language will have more
than one tool for many parts of the combination, so you wind up
wasting time on which of n interchangable tools is the right one
instead of actually solving the problem at hand.
And a bad programmer will go at great length explaining how bad the
tools are, because he has to learn them :-D
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Ville Vainio wrote: >> "John" == John Bokma <po********@castleamber.com> writes:
John> Who told you Perl can't do exceptions?
Back when I learned (heh, I never 'really' learned, but knew enough to
write programs in it) perl, almost every function call was followed by
or die("blah");
Yup, which throws an exception.
i.e. the user had to check the error code.
If the function would have
raised an exception instead, such check would be redundant because it
would never be executed.
true, Perl doesn't throw exceptions for you when an "or die" is required.
In Python, all error conditions raise exceptions. If python
'supported' exceptions but standard library functions didn't raise
them, the feature would not be worth much.
Agreed, one common error that beginners make a lot is not throwing
exceptions.
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Alan Little wrote: Steve Holden <st***@holdenweb.com> wrote:
Your statement then becomes
select * from foo where bar=1; drop table foo
which is clearly not such a good idea.
I'm sure Steve is very well aware of this and was just providing a
simple and obvious example, nevertheless it might be worth pointing
out that anyody who connects their web application to their database
as a user that has DROP TABLE privileges, would clearly be in need of
a lot more help on basic security concepts than just advice on
choosing a programming language.
True. But how does it stop someone who uses inserts? (I exclude the case
inserts are not needed).
This goes back to the point somebody made earlier on in the thread -
many web applications can be implemented as fairly simple wrappers
around properly designed databases. "Properly designed" includes
giving some thought to table ownership and privileges.
One should stop SQL injection always, no matter if the database takes care
of it or not. There is no excuse (like, yeah, but I set up the privileges
right) for allowing SQL injection, ever.
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
