J
John Bokma
Leif said:
my $sort = $cgi->param( "sort" );
my $query = "SELECT * FROM table WHERE id=? ORDER BY $sort";
my $sort = $cgi->param( "sort" );
my $query = "SELECT * FROM table WHERE id=? ORDER BY $sort";
L
Leif K-Brooks
John said:
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.
L
Leif Biberg Kristensen
Leif K-Brooks skrev:
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.
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.
P
Peter Ammon
Leif said:
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
D
Dennis Lee Bieber
The Python DB-API documents should have recommended against it
(or, at least, mentioned how they are designed to work...)
--
M
Mike Meyer
John Bokma said:
One of the stated conditions for more than one Perl position I've
looked at.
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"
Try programming in older Python for a while. You'll quit doubting it.
Nah, they aren't slow. They just have to worry about more things than
the Python developers.
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.
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.
The problem with using "the way you feel comfortable with" is that it
may not be comfortable for the maintainer - even if that's you six
months from now. My Perl evolved from very shell script like (lots of
backticks and passing around the full text of files) to one more
C-like as I used the language. That change was largely driven by
performance concerns as my understanding of the language grew.
<mike
L
Leif K-Brooks
Peter said:
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!
J
John Bokma
Leif said:
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).
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)
J
John Bokma
Peter said:
There is no almost in security.
J
John Bokma
Leif said:
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.
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?".
J
John Bokma
Mike said:
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 ;-)
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.
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.
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.
Why are those time critical parts not written in Python ;-)
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.
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.
I am sure you can do that with Python too.
Yup, in Perl one should program Perl, not bash, not C. Same for Python.
M
Mike Meyer
John Bokma said:
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.
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.
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.
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.
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.
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".
Of course not. The best you can do is provide one obvious way to do
things, and then hope most people find that.
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.
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
J
John Bokma
Mike said:
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
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
.And what makes you doubt it would be different with Perl? :-D
( sort @alist, split ' ', $astring, grep criteria, @list, etc )
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
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
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).
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.
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)
Beginners get lost anyway, experienced programmers don't need it
That was not what I wrote: I am sure one can program that way in Python
too.
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).
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
)
M
Mike Meyer
John Bokma said:
Perl's "There's more than one way to do it" attitude.
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.
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.
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.
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.
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.
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.
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 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.
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.
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
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.
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.
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.
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.
T
Tim Tyler
Mage said:
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.
B
Bruno Desthuilliers
Mage a écrit :
Keyboard !-)
Keyboard !-)
B
Bruno Desthuilliers
Lad a trollé :
Why don't you check by yourself ?
Why don't you check by yourself ?
R
Rocco Moretti
Roman said:
The irreverant would point you to
http://www.python.org/doc/Humor.html#vowels
*I* wouldn't consider doing anything like that said:
Yeah, as opposed to the completely unbiased opinions the OP expected to
find on comp.lang.PYTHON
J
John Bokma
Mike said:
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.
You think? Please read perldoc -f grep (and map).
If you guess extra ways, you make Perl more complicated than it is :-D.
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?
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)
( told you it was grep ;-) )
What makes you think a machine can not parse Perl? I didn't get a Larry
Wall with my version of Perl :-D
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 you don't even come close :-D.
Same could be said of floating point numbers, or complex numbers, or
lists, dictionaries, etc. etc.
"The programmer's skills are not the issue"
weird, I let the computer do that :-D.
[ skilled Perl programmers use similar or same idioms ]
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.
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.
As I said: the sugared versions of goto very likely solves all problems
that need (or "need") a goto.
I can only speak for Perl, and indeed, I never used a real goto.
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.
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.
potential bugs is often equal to something people *think* a beginner is
going to make.
and if they are not hermits, they choose the ones they see the most
often used (unless it's Perl golf).
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.
I wonder how much this has to do with how you learned Perl, and how you
learned Python.
But it doesn't mean that one can't do ;-)
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.
Yes, most languages make it clumsy and frustrating. Perl is a rare
exception.
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.
To you.
yup, the number of whitespace for example. Even python lets you free in
the number of spaces here and there ;-)
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
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?
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.
You can not borrow only a lot. Where is the rest coming from?
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.
In your opinion, which sounds quite restrictive.
[ new things ]
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 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.
I will stay tuned, since I want to add Python to my skill set.
V
Ville Vainio
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"...).
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"...).