Python or PHP?
Lad
any?
Cheers,
L.
Leif B. Kristensen
> 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/
Leif K-Brooks
> 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.
Mage
>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
check this: http://wiki.w4py.org/pythonvsphp.html
Mage
Ville Vainio
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
Diez B. Roggisch
au contraire! I've seen many code smells in PHP.
http://c2.com/cgi/wiki?CodeSmell
--
Regards,
Diez B. Roggisch
Tim Tyler
> 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.
--
__________
|im |yler http://timtyler.org/ t...@tt1lock.org Remove lock to reply.
Mage
>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
Kirk Job Sluder
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
Simon John
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.
Fredrik Lundh
> 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>
Mage
>
>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
Jeremy Bowers
> 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.
Roman Neuhauser
> Lad wrote:
>
> >Is anyone capable of providing Python advantages over PHP if there are
> >any?
>
>
> - 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.
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
F. Petitjean
> 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
Leif K-Brooks
> 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?
John Bokma
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
Mike Meyer
> 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 <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
John Bokma
> "Simon John" <simonin...@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.
Leif K-Brooks
> 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
my $sort = $cgi->param( "sort" );
my $query = "SELECT * FROM table WHERE id=? ORDER BY $sort";
Leif K-Brooks
> 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 Biberg Kristensen
> 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.
Peter Ammon
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.
Mike Meyer
> Mike Meyer wrote:
>
>> "Simon John" <simonin...@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.
Leif K-Brooks
> 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!
John Bokma
> 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 Bokma
There is no almost in security.
John Bokma
> 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 Bokma
> John Bokma <postm...@castleamber.com> writes:
>
>> Mike Meyer wrote:
>>
>>> "Simon John" <simonin...@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.
Mike Meyer
> Mike Meyer wrote:
>
>> John Bokma <postm...@castleamber.com> writes:
>>
>>> Mike Meyer wrote:
>>>
>>>> "Simon John" <simonin...@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
John Bokma
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 :-) )
Mike Meyer
> 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.
Tim Tyler
> 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/ t...@tt1lock.org Remove lock to reply.
Bruno Desthuilliers
> I can tell:
> - python is more *pythonic* than php
Keyboard !-)
Bruno Desthuilliers
> Is anyone capable of providing Python advantages over PHP if there are
> any?
Why don't you check by yourself ?
Rocco Moretti
> # 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
John Bokma
> John Bokma <postm...@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.
Ville Vainio
>> 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
Steve Holden
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/
Mike Meyer
> Mike Meyer wrote:
>> John Bokma <postm...@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
John Bokma
>>>>>> "John" == John Bokma <postm...@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 Bokma
> John Bokma <postm...@castleamber.com> writes:
>
>> Mike Meyer wrote:
>>> John Bokma <postm...@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.
Mike Meyer
> Mike Meyer wrote:
>> John Bokma <postm...@castleamber.com> writes:
>>> Mike Meyer wrote:
>>>> John Bokma <postm...@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.
Ville Vainio
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.
Alan Little
>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.
John Bokma
> John Bokma <postm...@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 Bokma
>>>>>> "John" == John Bokma <postm...@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 Bokma
> 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.
Steve Holden
> 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.
>
In security several levels of defense are better than just one, so
database authorization and SQL injection removal should be considered
complimentary techniques of a "belt and braces" (US: "belt and
suspenders") approach.
John Bokma
Yup, would say different, I normally set up the privileges before I even
start to program.
Mike Meyer
> Mike Meyer wrote:
>
>> John Bokma <postm...@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.
Yeah - unless is a bad idea. If that were the only such problem in
Perl, it wouldn't be a problem. Unfortnately, it's a symptom of the
design philosphy of the language.
>>>> 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.
Um - you commented on 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.
Then why do most Perl programmers consider unless "! a good idea"? No,
things were added to Perl so there would be more than one way to do
them - which is even *worse* than adding them without a good reason.
>>>> 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
Right. You were constructing something for humans to read - and
managed to construct something that was a PITA to read. If you'd made
the oher choice, it wouldn't have been a PITA to read.
>> 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.
And what if you do something with it other than assign it to a
variable?
You're right - the assignment is doing something wrong. A good
language would catch things at that point and let the programmer know
about it, so you get notified of the bug at the location of the
bug. Python doesn't do this any better, though.
> 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.
I thought your answer was a kind of list, but the syntax you chose
made it completely unclear where each item ended, because you
overloaded the "," character to seperate arguments to functions in the
list as well as to separate items in the list. Choosing the other
option would have grouped the arguments, and made things clear. And
yes, I consider the Perl split atrocious.
> 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.
I'll admit it's been a while since I did anything other than
debugging. I haven't had much call to do the things that Perl is
really good at (simple re-heavy scripts), so I haven't done much
development in it.
You may be overwhelmed by any language. I'm not. The only one that
ever overwhelmed me was Common LISP. It looks like Perl 6 would, if I
ever bothered to learn it - because it's going to be bigger than
Common LISP.
>>>>> 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.
It also fragments along subsets of the language, which is the bad thing.
>>> 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.
So, where's the ARM assemblly library that includes dictionaries?
>>> 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?
Of course they'll make other mistakes. No programmer is perfect. I
already pointed out the LISP study on garbage collection. Bounds
checking doesn't prevent mistakes, it just makes them easier to find
by causing an error report at the point the bug occured, instead of at
some point in the future.
>>> 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?
If they have the same functionality, then yes, I think the java will
have fewer bugs, because it will have fewer lines of code.
>> 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?
No, because programs do more things than they did a few years ago.
>>> 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.
Python doesn't restrict programmers. Python is one of the *least*
restrictive languages I know. It eliminates certain classes of bugs by
providing well-designed facilities in lieue of older facilities, but
that's not a restriction. And that's not a unique to Python,
either. Most modern languages share those facilities.
> 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.
You keep harping on restrictions. Garbage collection isn't a
restriction. It's a feature. It replaces the explicit alloc/free found
in older languages. Since good language design calls for one way to do
things, you lose the older, more bug-prone facility. After all, it now
contributes nothing to the language. No restriction at all.
As I said before, I hate restrictions. Restrictions hamper
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.
I think garbage collection is a time saver as well. It saves me time
hunting bugs caused by incorrect usage of the facilities it
replaced. It may save a little time in not having to write explicit
deallocation instructions, but that's trivial.
>>> 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.
No, unfortunately I still have to maintain Perl code.
Ok, so it's only the skill level of the programmers that's the cause
of the changes. So why does the language offer bad choices to the
programmers? That's as silly as a language having garbage collection
and alloc/free. Good programmers won't use the latter. Bad ones will,
just because it's there.
>>> 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.
Sure, anyone can bundle whatever they want up as a distribution, but
that doesn't mean those things are part of the base library. The
original contention which caused your reaction was that Python came
with a larger base library than Perl does. It seems that this claim is
still true even if you use the ActiveState distribution of 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?
Unfortunately, no. PyPI is the one linked to from the web site. It
doesn't have CPAN's auto-install capabilities
>>> 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.
Are you afraid to answer the question? Do you or do you not use the
"foreach" loop in perl? Until you do, I can't know why my asking that
question makes you call my perl experience into question.
Is it because only an idiot would never use the foreach loop? I
agree. Which is why I find your claim not to use it ludicruous.
Is it because only an idiot would use the foreach loop? If so, please
back that up by telling me what's wrong with the foreach loop.
>>> 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?
Yup - I was using Perl back when it was at version 3. The currently
installed Perl is 5.8.5.
>>>> 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?
Which would you trust more - a programmer who had to unlearn all his
bad habits, or one who never had the chance to develop them?
> And do you really think his/her code would be better compared to a
> skilled programmer?
No, I don't think it would be better. I don't think it would be as
good. I never claimed any of those things - I claimed that code
written in a TOOWTDI language is more maintainable than code written
in a TMTOWTDI 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?
> 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?
Of course there's no holy grail, just as there's no silver
bullet. However, languages can be compared as to their suitability for
an application domain, and I try to chose the superior language for
each application domain. At one point, I did a lot of work in
application domains for which Perl was a good choice. That simply
isn't true any more.
>>> 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".
Oh, bullshit. I admit my perl skills are rusty - that comes from
having found a language that is superior to it across a large
collection of problem domains. I never read "Learning Perl". It didnt'
exist when I learned Perl.
Even if it is true, the point still stands - Perl programs are less
maintainable than Python programs. I maintain that the difference in
philosphy on the number of ways to do things is a cause for that.
>>> 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
A good programmer will compare the toolset to others he's familiar
with, and choose the toolset that is best for the jobs he does. An
evangelical programmer will then spend a lot of effort explaining why
one toolset is better than another.
John Bokma
> John Bokma <jo...@castleamber.com> writes:
[ unless ]
> Yeah - unless is a bad idea.
LOL, because you don't like it? You already showed code like:
if condition then
nothing
else
something
unless IMNSHO improves readability.
>> 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.
>
> Then why do most Perl programmers consider unless "! a good idea"?
Reread the last part of the last sentence you quoted above.
>> *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
>
> Right. You were constructing something for humans to read - and
> managed to construct something that was a PITA to read. If you'd made
> the oher choice, it wouldn't have been a PITA to read.
*sigh*, you asked several *stand alone* problems, from the context of
your question especially *you* should have been able to grasp that I
wasn't creating some silly list. The etc was a giveaway.
>>> 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.
>
> And what if you do something with it other than assign it to a
> variable?
Depends on what you are going to do with it. If you give it to something
that turns the context into scalar, you get the number of items, but
either that is what you want, or you make a mistake.
>> 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.
>
> I thought your answer was a kind of list, but the syntax you chose
> made it completely unclear where each item ended, because you
> overloaded the "," character to seperate arguments to functions in the
> list as well as to separate items in the list.
You claimed to have some experience with perl, so I was *hoping* that
you at least were able to understand sort, split, and grep are perl
keywords. I mean, as a joke, I even almost translated your examples
literaly e.g.
sort a list sort @alist
split a string on white space split ' ', $astring
pull select list elements based grep criteria, @list
on some criteria of some kind
> Choosing the other
> option would have grouped the arguments, and made things clear.
I doubt it, you are just looking everywhere for a point, there is none.
Your Perl skills are doubtfull to say the least. And yet you think you
can say how badly it is designed, and so many things are wrong with it.
To me you appear like a parrot, just repeating what you read somewhere,
or heard somewhere.
>> 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.
>
> I'll admit it's been a while since I did anything other than
> debugging. I haven't had much call to do the things that Perl is
> really good at (simple re-heavy scripts), so I haven't done much
> development in it.
Amazing, how can you debug if you know next to nothing of it?
> You may be overwhelmed by any language. I'm not.
Sure, LOL. You are so overwhelmed with Perl that you even lack the basic
skills, but yet nag about it a lot.
>> In a pure language such things are in the library.
>
> So, where's the ARM assemblly library that includes dictionaries?
I don't have access to a small one I wrote ages ago. But I am sure there
are enough people who can provide you with one, or otherwise, as a
skilled programmer, you would be able to write one in a day or less.
> already pointed out the LISP study on garbage collection. Bounds
> checking doesn't prevent mistakes, it just makes them easier to find
> by causing an error report at the point the bug occured, instead of at
> some point in the future.
So it prevents a mistake from poping up in production code. That's
enough for me.
>> 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.
>
> You keep harping on restrictions. Garbage collection isn't a
> restriction. It's a feature.
It's also a restriction. Why do you think in Java one can call the gc
explicitly?
>> 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.
>
> I think garbage collection is a time saver as well. It saves me time
> hunting bugs caused by incorrect usage of the facilities it
> replaced. It may save a little time in not having to write explicit
> deallocation instructions, but that's trivial.
In my case it saves time the other way around, I consider correct usage
trivial, but the typing all the time...
>> 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.
>
> No, unfortunately I still have to maintain Perl code.
Then I seriously would recommend you to take a few days to read, and re-
read Learning Perl. Not as a joke, but to save yourself a lot of time.
Make notes the second pass.
> Ok, so it's only the skill level of the programmers that's the cause
> of the changes. So why does the language offer bad choices to the
> programmers?
Who are "the programmers" to you? And what is a bad choice?
> That's as silly as a language having garbage collection
> and alloc/free. Good programmers won't use the latter.
Good programmers in your opinion. A really good programmer would use
alloc/free, if garbage collection works as it does with Java, in those
cases it's better.
>> 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.
>
> Sure, anyone can bundle whatever they want up as a distribution, but
> that doesn't mean those things are part of the base library. The
> original contention which caused your reaction was that Python came
> with a larger base library than Perl does. It seems that this claim is
> still true even if you use the ActiveState distribution of Perl.
I have no idea. Which modules do you miss in Perl that come with Python?
>>> 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?
>
> Unfortunately, no. PyPI is the one linked to from the web site. It
> doesn't have CPAN's auto-install capabilities
So instead of the ability to install a Perl module with just a few lines
of typing, one has to eh... what? Use google? Ask around?
>> 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.
>
> Are you afraid to answer the question? Do you or do you not use the
> "foreach" loop in perl? Until you do, I can't know why my asking that
> question makes you call my perl experience into question.
I haven't been using *foreach* for quite some time, I use *for* all the
time. Which is just because I am lazy.
>> Perl 4? Even Perl 5 is almost 11 years old. Which version of Perl 5
>> are you talking about?
>
> Yup - I was using Perl back when it was at version 3. The currently
> installed Perl is 5.8.5.
You used Perl 3!?? LOL! For what? To write poetry? I mean, if you used
version 3, and you still make extremely basic mistakes...
>>>>> 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?
>
> Which would you trust more - a programmer who had to unlearn all his
> bad habits, or one who never had the chance to develop them?
Neither, and think about that for some time.
>> 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".
>
> Oh, bullshit. I admit my perl skills are rusty - that comes from
> having found a language that is superior to it across a large
> collection of problem domains. I never read "Learning Perl". It didnt'
> exist when I learned Perl.
So you got stuck with Perl 3 somehow?
> Even if it is true, the point still stands - Perl programs are less
> maintainable than Python programs. I maintain that the difference in
> philosphy on the number of ways to do things is a cause for that.
But to me, you don't sound qualified to make that statement, your Perl
skills are, well, rusty.
>> And a bad programmer will go at great length explaining how bad the
>> tools are, because he has to learn them :-D
>
> A good programmer will compare the toolset to others he's familiar
> with,
which only can be done when he/she knows both (almost) equally well.
> and choose the toolset that is best for the jobs he does. An
> evangelical programmer will then spend a lot of effort explaining why
> one toolset is better than another.
without a good understanding of the other toolset, yup.
Jeremy Bowers
> Mike Meyer wrote:
>
>> John Bokma <jo...@castleamber.com> writes:
Nobody ever changed their mind as a result of a 20-thread endless
reply-fest. As usual, the posters aren't about to admit anything, and none
of the bystanders are reading any more.
Jorey Bump
@l41g2000cwc.googlegroups.com:
> Is anyone capable of providing Python advantages over PHP if there are
> any?
As you learn Python, you will find that your PHP code will improve,
possibly becoming more and more concise until it disappears completely.
Steve Holden
Yup.
zzzzzzzzzzzzzz-ly y'r - steve
John Bokma
So why do you have that unstopable pathetic urge to contribute with whining
to this thread? Aren't you able enough to configure your newsreader? Stay
out of a thread if you have zero to add.
John Bokma
> Yup.
Even aol in this group...
Mike Meyer
Yeah, but I'm having fun. What's the point of usenet, if it's not fun?
Mike Meyer
> Mike Meyer wrote:
>
>> John Bokma <jo...@castleamber.com> writes:
> [ unless ]
>> Yeah - unless is a bad idea.
> LOL, because you don't like it?
Oh, come on. You say something, I agree with it, so you remove your
original comment so you can argue with me? You're just being
argumentative. Surely you can do better than that. But I'll humor you.
> You already showed code like:
Actually, I never showed you this code. You went out of your way to
make it uglier than it was.
> if condition then
> nothing
> else
> something
> unless IMNSHO improves readability.
Anyone can create bogus use cases to show how some random construct
can improve readability. If you show the construct to a *good*
programmer and they come up with a rewrite that doesn't need the
construct, then the construct is a bad idea.
In this case, the good rewrite invokes the well-known logical operator
"not":
if not condition then
something
>>> 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.
>> Then why do most Perl programmers consider unless "! a good idea"?
> Reread the last part of the last sentence you quoted above.
I can't - in being argumentative, you neglected to include it.
>>> *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
>> Right. You were constructing something for humans to read - and
>> managed to construct something that was a PITA to read. If you'd made
>> the oher choice, it wouldn't have been a PITA to read.
> *sigh*, you asked several *stand alone* problems, from the context of
> your question especially *you* should have been able to grasp that I
> wasn't creating some silly list. The etc was a giveaway.
Um, I suggest you brust up on your English skills. What you created
was a list. Not in Python or Perl, but in English. It turned out to be
a silly list because a syntactic element of the items in the list was
identical to a syntactic element in the list, with nothing to set it
off.
>>> 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.
>>
>> I thought your answer was a kind of list, but the syntax you chose
>> made it completely unclear where each item ended, because you
>> overloaded the "," character to seperate arguments to functions in the
>> list as well as to separate items in the list.
>
> You claimed to have some experience with perl, so I was *hoping* that
> you at least were able to understand sort, split, and grep are perl
> keywords. I mean, as a joke, I even almost translated your examples
> literaly e.g.
Oh, I understood it. It just took more work than it would have if
you'd done it the other way. Ok, so you were making a joke. I'll get
around to laughing at it eventually.
>> Choosing the other
>> option would have grouped the arguments, and made things clear.
> I doubt it, you are just looking everywhere for a point, there is none.
> Your Perl skills are doubtfull to say the least. And yet you think you
> can say how badly it is designed, and so many things are wrong with it.
If you look, you'll find the example where I chose the right
option. That will put your doubts at rest.
And so far, I've only said *two* things were wrong with Perl. One is
that it provides more than one way to do things - which point you've
made for me by arguing about how you did/didn't choose the right one
in an example. I also said that it's failure to flag assigning the
output of map/grep (there's that multiple choices thing again) to a
scalar when you wanted a list was bad. You haven't argued that I was
wrong about Perl in either case.
> To me you appear like a parrot, just repeating what you read somewhere,
> or heard somewhere.
Nah, I seldom listen to what other people have to say about Perl - at
least since I stopped developing in it. I did read "The seven deadly
sins" page, but have mostly forgotten that.
>>> 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.
>> I'll admit it's been a while since I did anything other than
>> debugging. I haven't had much call to do the things that Perl is
>> really good at (simple re-heavy scripts), so I haven't done much
>> development in it.
> Amazing, how can you debug if you know next to nothing of it?
So either your assessment of my skills is *way* off, or I'm an
*amazing* programmer.
>> You may be overwhelmed by any language. I'm not.
> Sure, LOL. You are so overwhelmed with Perl that you even lack the basic
> skills, but yet nag about it a lot.
At this point, I'm *underwhelmed* with Perl. And let's see - less than
one conversation a year for the past nine years. Yeah, that's nagging
about it a lot. I'd say both your assessments were equally accurate.
>>> In a pure language such things are in the library.
>> So, where's the ARM assemblly library that includes dictionaries?
> I don't have access to a small one I wrote ages ago. But I am sure there
> are enough people who can provide you with one, or otherwise, as a
> skilled programmer, you would be able to write one in a day or less.
In other words, I have to write in a dialect of the language. As I'm
sure you're aware by now, that's a sign of bad language design. No
thanks.
>> You keep harping on restrictions. Garbage collection isn't a
>> restriction. It's a feature.
> It's also a restriction. Why do you think in Java one can call the gc
> explicitly?
If it's a restriction, there must be something it restricts you from
doing. Care to tell me exactly what garbage collection keeps you from
doing?
>>> 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.
>> I think garbage collection is a time saver as well. It saves me time
>> hunting bugs caused by incorrect usage of the facilities it
>> replaced. It may save a little time in not having to write explicit
>> deallocation instructions, but that's trivial.
> In my case it saves time the other way around, I consider correct usage
> trivial, but the typing all the time...
I guess you haven't had to chase many bugs related to missing free's
(though those have gotten easier to find with modern free/alloc tools)
or a reference through a free'd pointer. I can type free(mem) an awful
lot of times in the time it takes to read through the stack trace from
the first crash related to one of those bugs.
>> Ok, so it's only the skill level of the programmers that's the cause
>> of the changes. So why does the language offer bad choices to the
>> programmers?
> Who are "the programmers" to you? And what is a bad choice?
The programmers in this case are the people who write code in the
language under discussion. A bad choice is the one that skilled coders
don't make. TOOWTDI makes the right choice obvious to even the least
skilled programmers, and makes wrong choices painful. TMTOWTDI makes
wrong choices - or ugly code - easy. Which is one of the reasons that
multiple nearly identical constructs is a bad design.
>> That's as silly as a language having garbage collection
>> and alloc/free. Good programmers won't use the latter.
> Good programmers in your opinion. A really good programmer would use
> alloc/free, if garbage collection works as it does with Java, in those
> cases it's better.
So the jvm implementations you're familiar with have really bad
garbage collectors. A good programmer won't immediately abandon either
Java or garbage collection. They'd check out other implementations of
the jvm to see if one of those has a better garbage collector. Failing
that, they'd check out other languages to see if one of them might
have a garbage collector that will perform adequately to the problem
at hand - assuming such is politically feasible. After that, they'd
begin to consider alternatives to garbage collection. Explicit
alloc/free is one possibility. A stack-based allocation scheme is
another. There are probably others as well. You can't simply tag one
as "better" without knowing what the problem domain is.
>>> 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.
>> Sure, anyone can bundle whatever they want up as a distribution, but
>> that doesn't mean those things are part of the base library. The
>> original contention which caused your reaction was that Python came
>> with a larger base library than Perl does. It seems that this claim is
>> still true even if you use the ActiveState distribution of Perl.
> I have no idea. Which modules do you miss in Perl that come with Python?
I already pointed out some modules that come with Python that Perl (as
installed by my system packaging system) doesn't come with. A quick
check shows that it still doesn't come with mail-handling modules -
parsing mailboxes, parsing mail messages, and sending mail via smtp. I
tend to use those on a regular basis. I'm sure I can find them in CPAN
if I really need them, though.
>>>> 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?
>> Unfortunately, no. PyPI is the one linked to from the web site. It
>> doesn't have CPAN's auto-install capabilities
> So instead of the ability to install a Perl module with just a few lines
> of typing, one has to eh... what? Use google? Ask around?
Personally, I check PyPI, and a few other sites. Google helps at
times. If all else fails, I ask on c.l.python.
>>> 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.
>> Are you afraid to answer the question? Do you or do you not use the
>> "foreach" loop in perl? Until you do, I can't know why my asking that
>> question makes you call my perl experience into question.
> I haven't been using *foreach* for quite some time, I use *for* all the
> time. Which is just because I am lazy.
You make my case for me. You write in a subset of Perl that excludes
"foreach". Is that the "absolute beginner" or the "beginner" subet?
Or maybe it's a subset that doesn't depend on the skill level of the
programmer.
>>> Perl 4? Even Perl 5 is almost 11 years old. Which version of Perl 5
>>> are you talking about?
>> Yup - I was using Perl back when it was at version 3. The currently
>> installed Perl is 5.8.5.
> You used Perl 3!?? LOL! For what? To write poetry? I mean, if you used
> version 3, and you still make extremely basic mistakes...
No, I wrote systems adminstration utilities in Perl 3. I wrote web
application in Perl 4. I just maintain Perl 5. Your "basic mistakes"
was forgetting the warts on strip. BFD.
>>>>>> 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?
>> Which would you trust more - a programmer who had to unlearn all his
>> bad habits, or one who never had the chance to develop them?
> Neither, and think about that for some time.
So you write all your code yourself, and don't avail yourself of Perls
best feature - CPAN?
>>> 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".
>> Oh, bullshit. I admit my perl skills are rusty - that comes from
>> having found a language that is superior to it across a large
>> collection of problem domains. I never read "Learning Perl". It didnt'
>> exist when I learned Perl.
> So you got stuck with Perl 3 somehow?
I got stuck with the latest version of Perl that was available. It was
a major improvement over shell scripts. That's not saying a lot, even
today - and shell scripting has improved since then.
>> Even if it is true, the point still stands - Perl programs are less
>> maintainable than Python programs. I maintain that the difference in
>> philosphy on the number of ways to do things is a cause for that.
> But to me, you don't sound qualified to make that statement, your Perl
> skills are, well, rusty.
Ok, ask in both groups. See how many people you find that maintain
both who feel that each is better. I'm positive you'll find the
majority who do both find Python programs more maintainable.
>>> And a bad programmer will go at great length explaining how bad the
>>> tools are, because he has to learn them :-D
>> A good programmer will compare the toolset to others he's familiar
>> with,
> which only can be done when he/she knows both (almost) equally well.
Nope. A quick survey of a toolset is all that's needed to make a first
approximation as to it's quality - to someone who's familiar with
enough toolsets, anyway.
>> and choose the toolset that is best for the jobs he does. An
>> evangelical programmer will then spend a lot of effort explaining why
>> one toolset is better than another.
> without a good understanding of the other toolset, yup.
A good understanding of toolset design allows you to point out flaws
in a toolset without becoming intimately familiar with it. For
instance, mutliple nearly identical ways to express the same construct
is always a flaw in a toolset. Which has been the point I've been
making the whole time.
John Bokma
> John Bokma <jo...@castleamber.com> writes:
>> You already showed code like:
>
> Actually, I never showed you this code.
hence *like*, and yes you did, in a footnote.
> In this case, the good rewrite invokes the well-known logical operator
> "not":
>
> if not condition then
> something
unless condition then
something
Weird, we use constructions like that in normal language all the time,
and when we program it's suddenly bloat?
>>>> it makes the code more readable.
>>> Then why do most Perl programmers consider unless "! a good idea"?
>> Reread the last part of the last sentence you quoted above.
>
> I can't - in being argumentative, you neglected to include it.
*sigh* in your obsession to call me argumentative, your skipped over it:
"it makes the code more readable"
>> wasn't creating some silly list. The etc was a giveaway.
>
> Um, I suggest you brust up on your English skills.
^^^^^
> What you created was a list. Not in Python or Perl, but in English.
I doubt if any Perl programmer in the given context would have any
problem with it, but lets drop it.
> Oh, I understood it.
Sure, is that why you talked about a tuple? But, lets drop it.
> And so far, I've only said *two* things were wrong with Perl. One is
> that it provides more than one way to do things - which point you've
> made for me by arguing about how you did/didn't choose the right one
> in an example.
If you think I gave a wrong example, give the right one. The only reason
for an argument was your lack of knowledge about split and map, which
only tells something about you, not Perl.
> I also said that it's failure to flag assigning the
> output of map/grep (there's that multiple choices thing again)
There is that lack of understanding again: map and grep are two
different things. I can't help if you consider map/grep a *choice*
> to a
> scalar when you wanted a list was bad. You haven't argued that I was
> wrong about Perl in either case.
*sigh* if you want a list, you assign it to something that can handle a
list. If you assing a list to a scalar, you get the count. So if you
want to select items out of a list on a criteria, you use grep in a list
context, if you want to count the items, guess...
>> Amazing, how can you debug if you know next to nothing of it?
>
> So either your assessment of my skills is *way* off, or I'm an
> *amazing* programmer.
If you consider map/grep a multiple choice, what do you think?
(rethorical question).
>> It's also a restriction. Why do you think in Java one can call the gc
>> explicitly?
>
> If it's a restriction, there must be something it restricts you from
> doing. Care to tell me exactly what garbage collection keeps you from
> doing?
real time guaranteed memory allocation/deallocation (which might be
fixed by now in Java)
>> In my case it saves time the other way around, I consider correct
>> usage trivial, but the typing all the time...
>
> I guess you haven't had to chase many bugs related to missing free's
In my own code? I can't remember. In code written by other people: in
the cases they forget to free memory they did so many other things wrong
that I sincerly hope they have found other work by now.
> skilled programmers, and makes wrong choices painful. TMTOWTDI makes
> wrong choices - or ugly code - easy.
Especially if one keeps mixing up map and grep :-D
> Which is one of the reasons that
> multiple nearly identical constructs is a bad design.
Worse is when self proclaimed perl programmers call map and grep
identical constructs...
> So the jvm implementations you're familiar with have really bad
> garbage collectors.
I have no idea if this has changed recently. The last thing I read about
it is that there are 4 kinds of garbage collection one can select in
Sun's implementation.
> A good programmer won't immediately abandon either
> Java or garbage collection. They'd check out other implementations of
> the jvm to see if one of those has a better garbage collector.
Uhm, people often pick Java because of write once, run everywhere. So
that is not always, or even rarely an option.
> another. There are probably others as well. You can't simply tag one
> as "better" without knowing what the problem domain is.
I didn't say better, what I meant: there are situations real time
free/alloc is prefered, unless my knowledge of gc in general is
outdated.
>> I haven't been using *foreach* for quite some time, I use *for* all
>> the time. Which is just because I am lazy.
>
> You make my case for me. You write in a subset of Perl that excludes
> "foreach". Is that the "absolute beginner" or the "beginner" subet?
> Or maybe it's a subset that doesn't depend on the skill level of the
> programmer.
"The foreach keyword is just a synonym for the for keyword, so you can
just use foreach and for interchangeably, whichever you think is more
readable in a given situation" (Programming Perl, 3rd edition, p118)
>> You used Perl 3!?? LOL! For what? To write poetry? I mean, if you
>> used version 3, and you still make extremely basic mistakes...
>
> No, I wrote systems adminstration utilities in Perl 3. I wrote web
> application in Perl 4. I just maintain Perl 5. Your "basic mistakes"
> was forgetting the warts on strip. BFD.
The BFD was calling map / grep a *choice*. I am not sure about for and
foreach, it could be that you call for $item ( @list ) a foreach loop,
which I hope. Otherwise, if you really thought there where two
*different* loop ops (as you wrote) then there is another BFD to add.
>>> Which would you trust more - a programmer who had to unlearn all his
>>> bad habits, or one who never had the chance to develop them?
>> Neither, and think about that for some time.
>
> So you write all your code yourself,
Ok, let me rephrase that: think about that for a long time.
>> So you got stuck with Perl 3 somehow?
>
> I got stuck with the latest version of Perl that was available. It was
> a major improvement over shell scripts. That's not saying a lot, even
> today - and shell scripting has improved since then.
Perl 1.0?
>>> Even if it is true, the point still stands - Perl programs are less
>>> maintainable than Python programs. I maintain that the difference in
>>> philosphy on the number of ways to do things is a cause for that.
>> But to me, you don't sound qualified to make that statement, your
>> Perl skills are, well, rusty.
>
> Ok, ask in both groups. See how many people you find that maintain
> both who feel that each is better. I'm positive you'll find the
> majority who do both find Python programs more maintainable.
I just did (asking). And hope to be able to answer your question in a
year or so. Oh, and I want to add to your latter sentence: code written
by programmers who didn't learn Perl in 3 hours by downloading and
editing CGI scripts.
>>> A good programmer will compare the toolset to others he's familiar
>>> with,
>> which only can be done when he/she knows both (almost) equally well.
>
> Nope. A quick survey of a toolset is all that's needed to make a first
> approximation as to it's quality - to someone who's familiar with
> enough toolsets, anyway.
Weird: I am going study Python for at least one year. Unless you call
that a quick survey :-D.
> A good understanding of toolset design allows you to point out flaws
> in a toolset without becoming intimately familiar with it. For
> instance, mutliple nearly identical ways to express the same construct
> is always a flaw in a toolset. Which has been the point I've been
> making the whole time.
So a hammer is a bad tool, since one can use a scewdriver...
I always wondered why an artist, like for example a painter, has so many
nearly identical tools...
John Bokma
> Yeah, but I'm having fun. What's the point of usenet, if it's not fun?
:-D. I am always amazed how people now the opinion of "the bystanders", I
mean, are they having secret polls I am not aware of?
Mike Meyer
> Mike Meyer wrote:
>
>> John Bokma <jo...@castleamber.com> writes:
>>> You already showed code like:
>> Actually, I never showed you this code.
> hence *like*, and yes you did, in a footnote.
Yes, but *I* didn't say like, because I wanted to point out that you
had purposely uglified it.
>> In this case, the good rewrite invokes the well-known logical operator
>> "not":
>>
>> if not condition then
>> something
>
> unless condition then
> something
>
> Weird, we use constructions like that in normal language all the time,
> and when we program it's suddenly bloat?
If you want to program in a normal language, I recommend
COBOL. Natural languages have a different purpose than programming
languages, which are designed to communicate algorithms clearly and
concisely. In that domain, it's just bloat.
>>>>> it makes the code more readable.
>>>> Then why do most Perl programmers consider unless "! a good idea"?
>>> Reread the last part of the last sentence you quoted above.
>> I can't - in being argumentative, you neglected to include it.
> *sigh* in your obsession to call me argumentative, your skipped over it:
> "it makes the code more readable"
Let's get the facts straight here. I may have skipped over it the
first time, but I didn't call you argumentative then. It wasn't until
you argumentative until after you deleted it that I said you were
argumentative.
>> What you created was a list. Not in Python or Perl, but in English.
> I doubt if any Perl programmer in the given context would have any
> problem with it, but lets drop it.
No, let's not. It's a perfect example of why having multiple ways to
do things is a bad idea.
>> Oh, I understood it.
> Sure, is that why you talked about a tuple? But, lets drop it.
No, I talked about a tuple to point out that doing it right made
something a machine could parse properly, with no thought at all.
>> And so far, I've only said *two* things were wrong with Perl. One is
>> that it provides more than one way to do things - which point you've
>> made for me by arguing about how you did/didn't choose the right one
>> in an example.
> If you think I gave a wrong example, give the right one. The only reason
> for an argument was your lack of knowledge about split and map, which
> only tells something about you, not Perl.
I already gave the right one. The one with the optional parens put
back in.
>> to a
>> scalar when you wanted a list was bad. You haven't argued that I was
>> wrong about Perl in either case.
> *sigh* if you want a list, you assign it to something that can handle a
> list. If you assing a list to a scalar, you get the count. So if you
> want to select items out of a list on a criteria, you use grep in a list
> context, if you want to count the items, guess...
You still haven't argued that I'm wrong about Perl. You're arguing
about whether or not a behavior is bad, not the behavior.
Trying to argue that I'm wrong because I'm wrong about Perl's behavior
being bad would be a lot more effective if you pointed out where the
descriptions of bad behavior were incorrect.
>>> It's also a restriction. Why do you think in Java one can call the gc
>>> explicitly?
>> If it's a restriction, there must be something it restricts you from
>> doing. Care to tell me exactly what garbage collection keeps you from
>> doing?
> real time guaranteed memory allocation/deallocation (which might be
> fixed by now in Java)
That's an implementation feature, not a language feature. That's an
implementation feature, not a language feature. I might also note that
you're wrong about alloc/free, in that you don't get real time
guaranteed memory allocation/deallocation with it, either.
Care to try again?
>>> In my case it saves time the other way around, I consider correct
>>> usage trivial, but the typing all the time...
>> I guess you haven't had to chase many bugs related to missing free's
> In my own code? I can't remember. In code written by other people: in
> the cases they forget to free memory they did so many other things wrong
> that I sincerly hope they have found other work by now.
I'd say you've never done anything but trivial
>> skilled programmers, and makes wrong choices painful. TMTOWTDI makes
>> wrong choices - or ugly code - easy.
> Especially if one keeps mixing up map and grep :-D
Righ - you once again avoid the real issue.
>> So the jvm implementations you're familiar with have really bad
>> garbage collectors.
> I have no idea if this has changed recently. The last thing I read about
> it is that there are 4 kinds of garbage collection one can select in
> Sun's implementation.
If you had enough experience with jvm's, you'd know that Sun's wasn't
the only one out ther.
>> A good programmer won't immediately abandon either
>> Java or garbage collection. They'd check out other implementations of
>> the jvm to see if one of those has a better garbage collector.
> Uhm, people often pick Java because of write once, run everywhere. So
> that is not always, or even rarely an option.
Switching jvm's doesn't mean you switch away from Java. It means you
switch the implementation of the jvm that Java is running on. "Run
anywhere" has nothing to do with this.
>> another. There are probably others as well. You can't simply tag one
>> as "better" without knowing what the problem domain is.
> I didn't say better, what I meant: there are situations real time
> free/alloc is prefered, unless my knowledge of gc in general is
> outdated.
Your knowledge of free/alloc is wrong. They don't guarantee real time
behavior. Nor do they guarantee memory allocations.
I'm beginning to think your programming experience is limited.
>>> I haven't been using *foreach* for quite some time, I use *for* all
>>> the time. Which is just because I am lazy.
>>
>> You make my case for me. You write in a subset of Perl that excludes
>> "foreach". Is that the "absolute beginner" or the "beginner" subet?
>> Or maybe it's a subset that doesn't depend on the skill level of the
>> programmer.
>
> "The foreach keyword is just a synonym for the for keyword, so you can
> just use foreach and for interchangeably, whichever you think is more
> readable in a given situation" (Programming Perl, 3rd edition, p118)
You didn't bother refuting the point that you've created a subset of
Perl which never uses "foreach".
>>>> A good programmer will compare the toolset to others he's familiar
>>>> with,
>>> which only can be done when he/she knows both (almost) equally well.
>>
>> Nope. A quick survey of a toolset is all that's needed to make a first
>> approximation as to it's quality - to someone who's familiar with
>> enough toolsets, anyway.
> Weird: I am going study Python for at least one year. Unless you call
> that a quick survey :-D.
That's enough time to become proficient in a language. Which isn't
required if all you want to do is decide if it's well-designed.
>> A good understanding of toolset design allows you to point out flaws
>> in a toolset without becoming intimately familiar with it. For
>> instance, mutliple nearly identical ways to express the same construct
>> is always a flaw in a toolset. Which has been the point I've been
>> making the whole time.
> So a hammer is a bad tool, since one can use a scewdriver...
I didn't say a word about bad tools.
> I always wondered why an artist, like for example a painter, has so many
> nearly identical tools...
Because they do different things with them. while and if are nearly
identical tools - they both have a keyword, a boolean and a block of
code. But they do different things.
Axel
> Nobody ever changed their mind as a result of a 20-thread endless
> reply-fest. As usual, the posters aren't about to admit anything, and none
> of the bystanders are reading any more.
Well I am reading... always interested to learn.
Axel
JZ
the following:
$conn->Execute('UPDATED foo SET bar=? WHERE id=?', array("foo'bar",
123));
John Bokma
> John Bokma <jo...@castleamber.com> writes:
>
>> Mike Meyer wrote:
>>
>>> John Bokma <jo...@castleamber.com> writes:
>>>> You already showed code like:
>>> Actually, I never showed you this code.
>> hence *like*, and yes you did, in a footnote.
>
> Yes, but *I* didn't say like, because I wanted to point out that you
> had purposely uglified it.
your footnote:
"
*) I still remember seeing FORTRAN programmers writing ALGOL-W
conditionals as:
if not condition then
else
begin
code
end
"
mine purposely uglified version:
"
if condition then
nothing
else
something
"
> If you want to program in a normal language, I recommend
> COBOL. Natural languages have a different purpose than programming
> languages, which are designed to communicate algorithms clearly and
> concisely. In that domain, it's just bloat.
I, and I am sure I am not alone, consider unless not just bloat. To me
it serves a purpose: "communicate algorithms clearly" :-)
>>> What you created was a list. Not in Python or Perl, but in English.
>> I doubt if any Perl programmer in the given context would have any
>> problem with it, but lets drop it.
>
> No, let's not. It's a perfect example of why having multiple ways to
> do things is a bad idea.
Ok, again:
"
> 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 )
"
I skip over your "grep is wrong, should be map", and "split is also
wrong":
The most funniest reply I ever read:
"
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)])
"
I mean, that last part is extremely weird, I mean, in your original
question you use ; to separate each question: how does Python parse
that? Really Mike, give it up: you gave a few problems, I answered a
few, everyone could have seen that I separated each solution with a
comma, (almost each keyword is a dead giveaway since they match the word
in your original question). And you are suddenly saying that the way I
decided to write my answer says something about Perl? How much rope do
you need?
Moreover, in your reply you clearly showed that you mixed up map and
grep. Those are quite fundemental building blocks in perl, it's like
mixing up an array with a hash.
>>> Oh, I understood it.
>> Sure, is that why you talked about a tuple? But, lets drop it.
>
> No, I talked about a tuple to point out that doing it right made
> something a machine could parse properly, with no thought at all.
So you have been assimilated by the borg then? And do you think one
can't write a parser that is able to correctly parse my reply? I give
you a hint:
if a comma is followed by a keyword (bareword), it's a new statement.
etc is a no-op statement. Or should my answer be pure Perl? Is your
group of problems pure python? Perl?
> Trying to argue that I'm wrong because I'm wrong about Perl's behavior
> being bad would be a lot more effective if you pointed out where the
> descriptions of bad behavior were incorrect.
If you can't distinguish map from grep, have problems with split (and
maybe even white space), and have parsing problems (e.g. see a Perl list
where there is none), it's going to be a bit hard, don't you think?
>> real time guaranteed memory allocation/deallocation (which might be
>> fixed by now in Java)
>
> That's an implementation feature, not a language feature.
*sigh*
> That's an
> implementation feature, not a language feature. I might also note that
> you're wrong about alloc/free, in that you don't get real time
> guaranteed memory allocation/deallocation with it, either.
That depends on the platform, of course.
[ memory allocation and freeing bugs ]
> I'd say you've never done anything but trivial
For someone who claims to maintain perl code but mixes up grep and map,
and seems to have a hard time at understanding Perl in general, this is
quite a bold statement, to say the least.
> Righ - you once again avoid the real issue.
The real issue seems to be your *lack* of Perl skills.
>> I have no idea if this has changed recently. The last thing I read
>> about it is that there are 4 kinds of garbage collection one can
>> select in Sun's implementation.
>
> If you had enough experience with jvm's, you'd know that Sun's wasn't
> the only one out ther.
If your English reading skills where sufficient enough, you would have
been able to understand from my use of the word implementation that I am
aware of this. You want me to spell it out in Perl? Oh, no wait... >:->
>>> A good programmer won't immediately abandon either
>>> Java or garbage collection. They'd check out other implementations
>>> of the jvm to see if one of those has a better garbage collector.
>> Uhm, people often pick Java because of write once, run everywhere. So
>> that is not always, or even rarely an option.
>
> Switching jvm's doesn't mean you switch away from Java. It means you
> switch the implementation of the jvm that Java is running on. "Run
> anywhere" has nothing to do with this.
Maybe do some research into which jvm's are available for which
platforms, and also the problems some people have run into because "Run
anywhere" is not that easy even if there is a jvm "anywhere". But again,
maybe this all has recently changed.
>> I didn't say better, what I meant: there are situations real time
>> free/alloc is prefered, unless my knowledge of gc in general is
>> outdated.
>
> Your knowledge of free/alloc is wrong. They don't guarantee real time
> behavior. Nor do they guarantee memory allocations.
Weird, I have worked on enough platforms where both are the case, if you
know what you are doing. Maybe that's the difference ;-)
> I'm beginning to think your programming experience is limited.
Coming from a Perl "maintainer" that mixes up map and grep, that's quite
a bold statement. Even if you are right (which you are not), I doubt you
are qualified to make such a statement.
[ for is a synonym for foreach ]
> You didn't bother refuting the point that you've created a subset of
> Perl which never uses "foreach".
And you think that someone who *did* bother to learn Perl has a problem
with reading my for's? Is slowed down? Has to stop, think, read up the
documentation, is confused, etc?
I recommend to buy Learning Perl. I am sure that a skilled programmer,
as you claim to be, can finish reading it in 3 hours. Re-read it again,
and make some notes.
>> Weird: I am going study Python for at least one year. Unless you call
>> that a quick survey :-D.
>
> That's enough time to become proficient in a language. Which isn't
> required if all you want to do is decide if it's well-designed.
Let's just say that I define "proficient in a language" different.
>>> A good understanding of toolset design allows you to point out flaws
>>> in a toolset without becoming intimately familiar with it. For
>>> instance, mutliple nearly identical ways to express the same
>>> construct is always a flaw in a toolset. Which has been the point
>>> I've been making the whole time.
>> So a hammer is a bad tool, since one can use a scewdriver...
>
> I didn't say a word about bad tools.
Ok, flawed.
>> I always wondered why an artist, like for example a painter, has so
>> many nearly identical tools...
>
> Because they do different things with them.
Yup.
Alan Little
> John Bokma wrote:
> > 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).
Inserts are indeed not needed, if you really don't want to allow them.
The web app user connects to a schema that has no direct write
privileges on anything. Instead it has execute permissions on stored
procedures in another schema that do the writes. In Oracle, at any
rate, the stored procedure then runs with the privileges of the schema
it is in, but the calling user doesn't need or get those privileges.
Over the top in many cases, but it's an extra layer of defence if you
want it.
> >
> >
> >>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.
Wasn't suggesting that for a moment.
> >
> Correct. If a thing can't go wrong, it won't.
>
> In security several levels of defense are better than just one, so
> database authorization and SQL injection removal should be considered
> complimentary techniques of a "belt and braces" (US: "belt and
> suspenders") approach.
>
> regards
> Steve
I completely agree of course. Do both.
Christos TZOTZIOY
<dev...@joreybump.com> might have written:
+1 QOTW
--
TZOTZIOY, I speak England very best.
"Be strict when sending and tolerant when receiving." (from RFC1958)
I really should keep that in mind when talking with people, actually...