Python or PHP?

[Steve Holden]

Leif K-Brooks skrev:

But Python's DB-API (the standard way to connect to an SQL database
from Python) makes escaping SQL strings automatic. You can do this:

cursor.execute('UPDATE foo SET bar=%s WHERE id=%s', ["foo'bar", 123])

So. I've been writing SQL queries in Python like this, using PostgreSQL
and psycopg:

cursor.execute("select * from foo where bar=%s" % baz)

Is that wrong, and how should I have been supposed to know that this is
bad syntax? No doc I have seen actually has told me so.

It's *wrong* for some value of "wrong" - it does potentially introduce a
SQL injection vulnerability into your code.

Suppose I provide as input into the baz variable

1; drop table foo

Your statement then becomes

select * from foo where bar=1; drop table foo

which is clearly not such a good idea. More sophisticated attackes are
possible, but this gives you the idea.

regards
Steve

 

[Mike Meyer]

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.

You think? Please read perldoc -f grep (and map).

I did, and could have sworn that grep modifed the list in place. Mia
culpa.

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.

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?

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 you don't even come close :-D.

No, one I blew. One you still got wrong.

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.

"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.

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.

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.

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.

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 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.

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.

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.

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.

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.

Right - Perl makes writing ugly, slow code easy. Python makes it
hard. I think this makes python the superior language.

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.

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).

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.

Nonsense.

I make that claim based on experiene maintaing both Perl and Python
code. What basis do you have for calling it nonsense.

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.

You can not borrow only a lot. Where is the rest coming from?
sh.

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.

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 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> 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]

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.

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.

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.

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?

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.

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 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.

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.

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?

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?

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?

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?

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.

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?

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?

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.

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

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.

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.

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]

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.

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.

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.

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.

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.

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.

ARM assembly, told you ;-)

That's not a coverage. Unless ARM assembly includes garbage
collection, dictionaries and similar things.

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.

Trust me: they *have to be* released.

Then the interface is badly designed.

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.

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.

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 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?

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.

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.

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 use either for or while.

You never use the Perl foreach loop? That doesn't sound like a skilled
Perl programmer to me.

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.

Nope, the programmer does that.

No, the programme writes the ugly code. Perl makes it easy.

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.

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.

Yup, to pick a tool out of a organized toolbox. Which is fine if that's
the only job involved. Programming, or as I see it, is not about picking
tools out of a box, but combining them.

Right. A good language will have an obvious tool for each part of the
combination, so you don't spend time worrying about picking the right
tools - the right choices are obvious. A bad language will have more
than one tool for many parts of the combination, so you wind up
wasting time on which of n interchangable tools is the right one
instead of actually solving the problem at hand.

<mike

 

[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]

[ snip ]

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.

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.

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.

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.

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.

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.

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?

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?

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.

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.

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?

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.

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?

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?

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?

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".

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> 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]

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:




True. But how does it stop someone who uses inserts? (I exclude the case
inserts are not needed).




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.

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

 

[John Bokma]

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.

Yup, would say different, I normally set up the privileges before I even
start to program.

 

[Mike Meyer]

[ snip ]

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.

I must have missed it, since I didn't see it.

Um - you commented on it.

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.

*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.

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.

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.

In a pure language such things are in the library.

So, where's the ARM assemblly library that includes dictionaries?

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

<mike

 

[John Bokma]

John Bokma <[email protected]> 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.

Then why do most Perl programmers consider unless "! a good idea"?

Reread the last part of the last sentence you quoted above.

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.

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.

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.

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.

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.

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?

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...

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.

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?

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?

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.

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...

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.

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.

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]

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]

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]

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.

Yup.

zzzzzzzzzzzzzz-ly y'r - steve

 

[John Bokma]

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.

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]

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

Reread the last part of the last sentence you quoted above.

I can't - in being argumentative, you neglected to include it.

*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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

<mike