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

Home Posts Topics Members FAQ

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

Python or PHP?

Lad
Is anyone capable of providing Python advantages over PHP if there are
any?
Cheers,
L.

Jul 19 '05
68 5754
John Bokma wrote:
Alan Little wrote:

Steve Holden <st***@holdenweb.com> wrote:

Your statement then becomes

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

which is clearly not such a good idea.


I'm sure Steve is very well aware of this and was just providing a
simple and obvious example, nevertheless it might be worth pointing
out that anyody who connects their web application to their database
as a user that has DROP TABLE privileges, would clearly be in need of
a lot more help on basic security concepts than just advice on
choosing a programming language.

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

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.

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
--
Steve Holden +1 703 861 4237 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/

Jul 19 '05 #51
Steve Holden wrote:
John Bokma wrote:
Alan Little wrote:

Steve Holden <st***@holdenweb.com> wrote:
Your statement then becomes

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

which is clearly not such a good idea.

I'm sure Steve is very well aware of this and was just providing a
simple and obvious example, nevertheless it might be worth pointing
out that anyody who connects their web application to their database
as a user that has DROP TABLE privileges, would clearly be in need of
a lot more help on basic security concepts than just advice on
choosing a programming language.

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

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.

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.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Jul 19 '05 #52
John Bokma <jo**@castleamber.com> writes:
Mike Meyer wrote:
John Bokma <po********@castleamber.com> writes:
Mike Meyer wrote:
[ snip ]
do you really think that for / foreach and things like if / unless
bloat a language processor? I think you take your "pure programming
lanuage" way to far, and really don't understand your choice of
Python in your crusade.
I don't think I take it to far. All my experience dealing with
languages that took the opposite tack (i.e. - Perl and Common LISP)
demonstrate that such things are a bad idea.


Funny, quite a lot of Perl programmers consider using unless instead of
if ! a good idea. And if a programmer is not able to grasp the meaning
of unless if he sees it the first time, he should be able to look it up.
And if a programmer says that it burdens his mental processes, or slows
him down, I hope I never have to work with him/her and/or maintain
his/her code.


Yeah - unless is a bad idea. If that were the only such problem in
Perl, it wouldn't be a problem. Unfortnately, it's a symptom of the
design philosphy of the language.
and increases the semantic load on
the programmer. The best the programmer can do, as you imply, is to
ignore the extraneous methods.
I am curious of a list of extraneous methods in Perl (more about the
size by the way)

Methods isn't a very good word choice on my part, as it has to many
meanings. But saying "extraneous ways to do it" is a bit wordy. I
already gave you one such list, covering just the syntactic elements
of the language.

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


Um - you commented on it.
A poorly skilled programmer has to puzzle about a lot of more things.
Or you think list comprehension (sp?) and all the tricks with it are
clear? or the and or trick? I just had a glance on Python, but what
probably to you is one clear path isn't clear to me yet. And I doubt
that can all be blamed on unpure new Python.

Correct - newbies have to puzzle about a lot of things. A good
language design won't add to that set of things without a good
reason. Adding features because you can is adding things to puzzle
about without a good reason.

I doubt that features have been added to Perl just because. Even ones
that look like it, unless for example, have an excellent use, it makes
the code more readable.


Then why do most Perl programmers consider unless "! a good idea"? No,
things were added to Perl so there would be more than one way to do
them - which is even *worse* than adding them without a good reason.
No, one I blew. One you still got wrong.
Which one?


Faling to put in the parens that would have distinguished the argument
lists from the list of operators.


*sigh* you gave a list of problems, I replied by putting all answers on
one line, with () around them, and commas between them. I was not
constructing a tuple, or a list in Perl


Right. You were constructing something for humans to read - and
managed to construct something that was a PITA to read. If you'd made
the oher choice, it wouldn't have been a PITA to read.
Actually, it's not clear the grep was right either. The return value
of grep (and map) isn't always the right thing.

If you want to have a list of results and you assign it to a scalar, you
are doing the wrong thing.


And what if you do something with it other than assign it to a
variable?

You're right - the assignment is doing something wrong. A good
language would catch things at that point and let the programmer know
about it, so you get notified of the bug at the location of the
bug. Python doesn't do this any better, though.
But the bottom line is: I gave you answers to all, except one, of your
problems, you think my set of answers is a kind of Perl list, you
thought the grep was plainly wrong, and I guess you are not comfortable
with split.
I thought your answer was a kind of list, but the syntax you chose
made it completely unclear where each item ended, because you
overloaded the "," character to seperate arguments to functions in the
list as well as to separate items in the list. Choosing the other
option would have grouped the arguments, and made things clear. And
yes, I consider the Perl split atrocious.
And this gives me the feeling that you either haven't been using Perl
for over 4 years, or was never got beyond the absolute beginner level.
In the latter case I can imagine that you are overwhelmed by Perl. As
would one by any language.
I'll admit it's been a while since I did anything other than
debugging. I haven't had much call to do the things that Perl is
really good at (simple re-heavy scripts), so I haven't done much
development in it.

You may be overwhelmed by any language. I'm not. The only one that
ever overwhelmed me was Common LISP. It looks like Perl 6 would, if I
ever bothered to learn it - because it's going to be bigger than
Common LISP.

> If I could have a peek at the Perl code you maintained I could tell
> you (often by just seeing 3-5 lines) the status of the programmer
> who wrote it :-)
So you'd either say you were wrong, or that my second contention was
right. Either one would be a bad side effect of TMTOWTDI.
I am right, and you are wrong ;-)

In which case, I'm right in claiming that having more than one way to
do things fragments the community - which is *still* a bad thing for
the people writing the language.

It fragments it in a way every programming community is fragmented:
absoluut beginner, beginner, junior, senior, guru.


It also fragments along subsets of the language, which is the bad thing.
ARM assembly, told you ;-)


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


In a pure language such things are in the library.


So, where's the ARM assemblly library that includes dictionaries?
Easier, sure. But does it turn beginners in rock solid programmers?

It means they never make errors like using free'd memory, or failing
to free allocated memory. So in that since, yes, they are rock solid.

LOL, but they will make other mistakes. Otherwise, I am really curious,
can you show a publication that shows that the number of bugs /
application is much smaller when a garbage collection language is used,
and one that does bounds checking?


Of course they'll make other mistakes. No programmer is perfect. I
already pointed out the LISP study on garbage collection. Bounds
checking doesn't prevent mistakes, it just makes them easier to find
by causing an error report at the point the bug occured, instead of at
some point in the future.
So they looked close at one aspect of the language. But you think
that 10k lines of, say Java, has less bugs then 10k lines of C?

Nah. Then again, counting lines of code is a silly thing to do. You
think 10K lines of C does as much as 10K lines of Java?

Depends of course, but rephrase: we take 10 programs of C, 10 of Java,
each which are equal (except in the number of bugs). You think Java has
less?


If they have the same functionality, then yes, I think the java will
have fewer bugs, because it will have fewer lines of code.
The crucial
question isn't how many bugs you get per line of code, it's how many
bugs you get to achieve a given functionality. You can improve this
number by cutting down the number of bugs per line of code, or by
cutting down the number of lines of code needed to acheive a given
functionality. Modern programming environments clearly improve the
latter.

But are there now less bugs compared to a few years ago? Are, say, Java
programs in general more bug free?


No, because programs do more things than they did a few years ago.
And I am sure that you fixed enough bugs in the same *real* programs
that were in no way related to this. I have fixed enough bugs in
Perl, Java, etc, to know that "life will find a way", so to speak.

We both agree you're always going to have bugs. I think that
programming languages designed to eliminate whole classes of bugs are
good thing, because bugs are a bad thing. You seem to argue that
because we can't elimnate all bugs, we shouldn't eliminate any. That's
simply silly.

Nope, I got the impression from you that Python restricts programmers,
so they make less mistakes. They can't make mistakes of "whole classes",
but that doesn't mean they are suddenly good programmers.


Python doesn't restrict programmers. Python is one of the *least*
restrictive languages I know. It eliminates certain classes of bugs by
providing well-designed facilities in lieue of older facilities, but
that's not a restriction. And that's not a unique to Python,
either. Most modern languages share those facilities.
If I considered garbage collection bad, I would say so. But like airbags
doesn't improve the driving skills of someone, so doesn't all kind of
restrictions turn bad programmers suddenly in good programmers.
You keep harping on restrictions. Garbage collection isn't a
restriction. It's a feature. It replaces the explicit alloc/free found
in older languages. Since good language design calls for one way to do
things, you lose the older, more bug-prone facility. After all, it now
contributes nothing to the language. No restriction at all.

As I said before, I hate restrictions. Restrictions hamper
programmers.
Moreover, good programmers rarely need to be restricted. But I don't see
garbage collection as an anti-memory-leak restriction (which it can't be
in all cases) but as a time saver.
I think garbage collection is a time saver as well. It saves me time
hunting bugs caused by incorrect usage of the facilities it
replaced. It may save a little time in not having to write explicit
deallocation instructions, but that's trivial.
What makes you think there are isolated communities?

Let's see. LISP - some of the communities were MacLISP, InterLISP,
Zeta LISP, and Standard LISP. There are certainly others I
forgot. Perl - they don't have names, they just show up in the code I
have to maintain.

But is that because there are separate communities, or because there are
different skill levels? Moreover, I hope that "have to maintain" was
"had to maintain (some time ago)", because your Perl skills are more
than lacking.


No, unfortunately I still have to maintain Perl code.

Ok, so it's only the skill level of the programmers that's the cause
of the changes. So why does the language offer bad choices to the
programmers? That's as silly as a language having garbage collection
and alloc/free. Good programmers won't use the latter. Bad ones will,
just because it's there.
How long haven't you been in touch with Perl?

Oh, are you claiming that PERL ships with HTML and XML parsers, SMTP
clients and web servers in the standard library?

Which Perl? ActiveState Perl does indeed come with HTML, and XML
parsers, SMTP, etc, clients. Web server(s), I have no idea, haven't
needed a Perl webserver, I doubt it comes with AS Perl.


Sure, anyone can bundle whatever they want up as a distribution, but
that doesn't mean those things are part of the base library. The
original contention which caused your reaction was that Python came
with a larger base library than Perl does. It seems that this claim is
still true even if you use the ActiveState distribution of Perl.
That's odd - all the
packages I see seem to want to install those things from CPAN.

Is there such a centralized place for libraries for Python?


Unfortunately, no. PyPI is the one linked to from the web site. It
doesn't have CPAN's auto-install capabilities
I use either for or while.

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

I already stated you have little Perl experience. Now I have to change
that to *extremely* little Perl experience.
So it seems I am right: the overwhelming effect of "many ways" is mainly
seen by absolute beginners, who are able to make up many ways, even if
there is just one or two :-D.


Are you afraid to answer the question? Do you or do you not use the
"foreach" loop in perl? Until you do, I can't know why my asking that
question makes you call my perl experience into question.

Is it because only an idiot would never use the foreach loop? I
agree. Which is why I find your claim not to use it ludicruous.

Is it because only an idiot would use the foreach loop? If so, please
back that up by telling me what's wrong with the foreach loop.
How did you measure this? And which distribution of Perl are you
talking about?


By looking at the functionality installed programs used from third
parties (i.e. - CPAN in recent version) vs. what they used from the
standard library. And in Perl 4 and 5.

Perl 4? Even Perl 5 is almost 11 years old. Which version of Perl 5 are
you talking about?


Yup - I was using Perl back when it was at version 3. The currently
installed Perl is 5.8.5.
Right - Perl makes writing ugly,
Nope, the programmer does that.

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

So, and who is to blame? Would you trust a programmer who can only write
code in a certain way because he is restricted by the langauge to do so?


Which would you trust more - a programmer who had to unlearn all his
bad habits, or one who never had the chance to develop them?
And do you really think his/her code would be better compared to a
skilled programmer?


No, I don't think it would be better. I don't think it would be as
good. I never claimed any of those things - I claimed that code
written in a TOOWTDI language is more maintainable than code written
in a TMTOWTDI language.
And I think that there is the main problem in your whole story. You
think this is a quest for superiority. It isn't.

What? You're not trying to find the superior tool for the application
domain? Then what *are* you doing?

Programming, in a skilled way. There is no ultimate superior tool. Why
do you think I am learning Python? Because I found the holy grail? Or
that I just want another way to do things?


Of course there's no holy grail, just as there's no silver
bullet. However, languages can be compared as to their suitability for
an application domain, and I try to chose the superior language for
each application domain. At one point, I did a lot of work in
application domains for which Perl was a good choice. That simply
isn't true any more.
But if this all bothers you *this* much, I am afraid that the problem
is really behind the keyboard :-)

No, what bothers me *this* much is that every time I have to maintain
a Perl program, I have to learn somebody else's subset/idioms/etc of
the language. "All this" is the cause of that.

No. If this was crossposted in a Perl group, by now quite a lot of
people would have pointed you out, probably in a less nice way, that
your Perl skills are of a person who hasn't even gone beyond the first
few chapters of "Learning Perl".


Oh, bullshit. I admit my perl skills are rusty - that comes from
having found a language that is superior to it across a large
collection of problem domains. I never read "Learning Perl". It didnt'
exist when I learned Perl.

Even if it is true, the point still stands - Perl programs are less
maintainable than Python programs. I maintain that the difference in
philosphy on the number of ways to do things is a cause for that.
Yup, to pick a tool out of a organized toolbox. Which is fine if
that's the only job involved. Programming, or as I see it, is not
about picking tools out of a box, but combining them.


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


And a bad programmer will go at great length explaining how bad the
tools are, because he has to learn them :-D


A good programmer will compare the toolset to others he's familiar
with, and choose the toolset that is best for the jobs he does. An
evangelical programmer will then spend a lot of effort explaining why
one toolset is better than another.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jul 19 '05 #53
Mike Meyer wrote:
John Bokma <jo**@castleamber.com> writes:
[ unless ]
Yeah - unless is a bad idea.
LOL, because you don't like it? You already showed code like:

if condition then
nothing
else
something

unless IMNSHO improves readability.
I doubt that features have been added to Perl just because. Even ones
that look like it, unless for example, have an excellent use, it
makes the code more readable.


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


Reread the last part of the last sentence you quoted above.
*sigh* you gave a list of problems, I replied by putting all answers
on one line, with () around them, and commas between them. I was not
constructing a tuple, or a list in Perl


Right. You were constructing something for humans to read - and
managed to construct something that was a PITA to read. If you'd made
the oher choice, it wouldn't have been a PITA to read.


*sigh*, you asked several *stand alone* problems, from the context of
your question especially *you* should have been able to grasp that I
wasn't creating some silly list. The etc was a giveaway.
Actually, it's not clear the grep was right either. The return value
of grep (and map) isn't always the right thing.

If you want to have a list of results and you assign it to a scalar,
you are doing the wrong thing.


And what if you do something with it other than assign it to a
variable?


Depends on what you are going to do with it. If you give it to something
that turns the context into scalar, you get the number of items, but
either that is what you want, or you make a mistake.
But the bottom line is: I gave you answers to all, except one, of
your problems, you think my set of answers is a kind of Perl list,
you thought the grep was plainly wrong, and I guess you are not
comfortable with split.


I thought your answer was a kind of list, but the syntax you chose
made it completely unclear where each item ended, because you
overloaded the "," character to seperate arguments to functions in the
list as well as to separate items in the list.


You claimed to have some experience with perl, so I was *hoping* that
you at least were able to understand sort, split, and grep are perl
keywords. I mean, as a joke, I even almost translated your examples
literaly e.g.

sort a list sort @alist

split a string on white space split ' ', $astring

pull select list elements based grep criteria, @list
on some criteria of some kind
Choosing the other
option would have grouped the arguments, and made things clear.
I doubt it, you are just looking everywhere for a point, there is none.
Your Perl skills are doubtfull to say the least. And yet you think you
can say how badly it is designed, and so many things are wrong with it.

To me you appear like a parrot, just repeating what you read somewhere,
or heard somewhere.
And this gives me the feeling that you either haven't been using Perl
for over 4 years, or was never got beyond the absolute beginner
level. In the latter case I can imagine that you are overwhelmed by
Perl. As would one by any language.


I'll admit it's been a while since I did anything other than
debugging. I haven't had much call to do the things that Perl is
really good at (simple re-heavy scripts), so I haven't done much
development in it.


Amazing, how can you debug if you know next to nothing of it?
You may be overwhelmed by any language. I'm not.
Sure, LOL. You are so overwhelmed with Perl that you even lack the basic
skills, but yet nag about it a lot.
In a pure language such things are in the library.


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


I don't have access to a small one I wrote ages ago. But I am sure there
are enough people who can provide you with one, or otherwise, as a
skilled programmer, you would be able to write one in a day or less.
already pointed out the LISP study on garbage collection. Bounds
checking doesn't prevent mistakes, it just makes them easier to find
by causing an error report at the point the bug occured, instead of at
some point in the future.
So it prevents a mistake from poping up in production code. That's
enough for me.
If I considered garbage collection bad, I would say so. But like
airbags doesn't improve the driving skills of someone, so doesn't all
kind of restrictions turn bad programmers suddenly in good
programmers.


You keep harping on restrictions. Garbage collection isn't a
restriction. It's a feature.


It's also a restriction. Why do you think in Java one can call the gc
explicitly?
Moreover, good programmers rarely need to be restricted. But I don't
see garbage collection as an anti-memory-leak restriction (which it
can't be in all cases) but as a time saver.


I think garbage collection is a time saver as well. It saves me time
hunting bugs caused by incorrect usage of the facilities it
replaced. It may save a little time in not having to write explicit
deallocation instructions, but that's trivial.


In my case it saves time the other way around, I consider correct usage
trivial, but the typing all the time...
But is that because there are separate communities, or because there
are different skill levels? Moreover, I hope that "have to maintain"
was "had to maintain (some time ago)", because your Perl skills are
more than lacking.


No, unfortunately I still have to maintain Perl code.


Then I seriously would recommend you to take a few days to read, and re-
read Learning Perl. Not as a joke, but to save yourself a lot of time.
Make notes the second pass.
Ok, so it's only the skill level of the programmers that's the cause
of the changes. So why does the language offer bad choices to the
programmers?
Who are "the programmers" to you? And what is a bad choice?
That's as silly as a language having garbage collection
and alloc/free. Good programmers won't use the latter.
Good programmers in your opinion. A really good programmer would use
alloc/free, if garbage collection works as it does with Java, in those
cases it's better.
Which Perl? ActiveState Perl does indeed come with HTML, and XML
parsers, SMTP, etc, clients. Web server(s), I have no idea, haven't
needed a Perl webserver, I doubt it comes with AS Perl.


Sure, anyone can bundle whatever they want up as a distribution, but
that doesn't mean those things are part of the base library. The
original contention which caused your reaction was that Python came
with a larger base library than Perl does. It seems that this claim is
still true even if you use the ActiveState distribution of Perl.


I have no idea. Which modules do you miss in Perl that come with Python?
That's odd - all the
packages I see seem to want to install those things from CPAN.

Is there such a centralized place for libraries for Python?


Unfortunately, no. PyPI is the one linked to from the web site. It
doesn't have CPAN's auto-install capabilities


So instead of the ability to install a Perl module with just a few lines
of typing, one has to eh... what? Use google? Ask around?
So it seems I am right: the overwhelming effect of "many ways" is
mainly seen by absolute beginners, who are able to make up many ways,
even if there is just one or two :-D.


Are you afraid to answer the question? Do you or do you not use the
"foreach" loop in perl? Until you do, I can't know why my asking that
question makes you call my perl experience into question.


I haven't been using *foreach* for quite some time, I use *for* all the
time. Which is just because I am lazy.
Perl 4? Even Perl 5 is almost 11 years old. Which version of Perl 5
are you talking about?


Yup - I was using Perl back when it was at version 3. The currently
installed Perl is 5.8.5.


You used Perl 3!?? LOL! For what? To write poetry? I mean, if you used
version 3, and you still make extremely basic mistakes...
> Right - Perl makes writing ugly,
Nope, the programmer does that.
No, the programme writes the ugly code. Perl makes it easy.

So, and who is to blame? Would you trust a programmer who can only
write code in a certain way because he is restricted by the langauge
to do so?


Which would you trust more - a programmer who had to unlearn all his
bad habits, or one who never had the chance to develop them?


Neither, and think about that for some time.
No. If this was crossposted in a Perl group, by now quite a lot of
people would have pointed you out, probably in a less nice way, that
your Perl skills are of a person who hasn't even gone beyond the
first few chapters of "Learning Perl".


Oh, bullshit. I admit my perl skills are rusty - that comes from
having found a language that is superior to it across a large
collection of problem domains. I never read "Learning Perl". It didnt'
exist when I learned Perl.


So you got stuck with Perl 3 somehow?
Even if it is true, the point still stands - Perl programs are less
maintainable than Python programs. I maintain that the difference in
philosphy on the number of ways to do things is a cause for that.
But to me, you don't sound qualified to make that statement, your Perl
skills are, well, rusty.
And a bad programmer will go at great length explaining how bad the
tools are, because he has to learn them :-D


A good programmer will compare the toolset to others he's familiar
with,


which only can be done when he/she knows both (almost) equally well.
and choose the toolset that is best for the jobs he does. An
evangelical programmer will then spend a lot of effort explaining why
one toolset is better than another.


without a good understanding of the other toolset, yup.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Jul 19 '05 #54
On Mon, 25 Apr 2005 23:26:56 +0000, John Bokma wrote:
Mike Meyer wrote:
John Bokma <jo**@castleamber.com> writes:


Nobody ever changed their mind as a result of a 20-thread endless
reply-fest. As usual, the posters aren't about to admit anything, and none
of the bystanders are reading any more.
Jul 19 '05 #55
"Lad" <py****@hope.cz> wrote in news:1114254894.512656.297040
@l41g2000cwc.googlegroups.com:
Is anyone capable of providing Python advantages over PHP if there are
any?


As you learn Python, you will find that your PHP code will improve,
possibly becoming more and more concise until it disappears completely.

Jul 19 '05 #56
Jeremy Bowers wrote:
On Mon, 25 Apr 2005 23:26:56 +0000, John Bokma wrote:

Mike Meyer wrote:

John Bokma <jo**@castleamber.com> writes:

Nobody ever changed their mind as a result of a 20-thread endless
reply-fest. As usual, the posters aren't about to admit anything, and none
of the bystanders are reading any more.


Yup.

zzzzzzzzzzzzzz-ly y'r - steve
--
Steve Holden +1 703 861 4237 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/

Jul 19 '05 #57
Jeremy Bowers wrote:
On Mon, 25 Apr 2005 23:26:56 +0000, John Bokma wrote:
Mike Meyer wrote:
John Bokma <jo**@castleamber.com> writes:


Nobody ever changed their mind as a result of a 20-thread endless
reply-fest. As usual, the posters aren't about to admit anything, and
none of the bystanders are reading any more.


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 MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Jul 19 '05 #58
Steve Holden wrote:
Yup.


Even aol in this group...

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Jul 19 '05 #59
John Bokma <jo**@castleamber.com> writes:
Mike Meyer wrote:
John Bokma <jo**@castleamber.com> writes: [ unless ]
Yeah - unless is a bad idea.

LOL, because you don't like it?


Oh, come on. You say something, I agree with it, so you remove your
original comment so you can argue with me? You're just being
argumentative. Surely you can do better than that. But I'll humor you.
You already showed code like:
Actually, I never showed you this code. You went out of your way to
make it uglier than it was.
if condition then
nothing
else
something
unless IMNSHO improves readability.
Anyone can create bogus use cases to show how some random construct
can improve readability. If you show the construct to a *good*
programmer and they come up with a rewrite that doesn't need the
construct, then the construct is a bad idea.

In this case, the good rewrite invokes the well-known logical operator
"not":

if not condition then
something
I doubt that features have been added to Perl just because. Even ones
that look like it, unless for example, have an excellent use, it
makes the code more readable.

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

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


I can't - in being argumentative, you neglected to include it.
*sigh* you gave a list of problems, I replied by putting all answers
on one line, with () around them, and commas between them. I was not
constructing a tuple, or a list in Perl

Right. You were constructing something for humans to read - and
managed to construct something that was a PITA to read. If you'd made
the oher choice, it wouldn't have been a PITA to read.

*sigh*, you asked several *stand alone* problems, from the context of
your question especially *you* should have been able to grasp that I
wasn't creating some silly list. The etc was a giveaway.


Um, I suggest you brust up on your English skills. What you created
was a list. Not in Python or Perl, but in English. It turned out to be
a silly list because a syntactic element of the items in the list was
identical to a syntactic element in the list, with nothing to set it
off.
But the bottom line is: I gave you answers to all, except one, of
your problems, you think my set of answers is a kind of Perl list,
you thought the grep was plainly wrong, and I guess you are not
comfortable with split.


I thought your answer was a kind of list, but the syntax you chose
made it completely unclear where each item ended, because you
overloaded the "," character to seperate arguments to functions in the
list as well as to separate items in the list.


You claimed to have some experience with perl, so I was *hoping* that
you at least were able to understand sort, split, and grep are perl
keywords. I mean, as a joke, I even almost translated your examples
literaly e.g.


Oh, I understood it. It just took more work than it would have if
you'd done it the other way. Ok, so you were making a joke. I'll get
around to laughing at it eventually.
Choosing the other
option would have grouped the arguments, and made things clear.

I doubt it, you are just looking everywhere for a point, there is none.
Your Perl skills are doubtfull to say the least. And yet you think you
can say how badly it is designed, and so many things are wrong with it.


If you look, you'll find the example where I chose the right
option. That will put your doubts at rest.

And so far, I've only said *two* things were wrong with Perl. One is
that it provides more than one way to do things - which point you've
made for me by arguing about how you did/didn't choose the right one
in an example. I also said that it's failure to flag assigning the
output of map/grep (there's that multiple choices thing again) to a
scalar when you wanted a list was bad. You haven't argued that I was
wrong about Perl in either case.
To me you appear like a parrot, just repeating what you read somewhere,
or heard somewhere.


Nah, I seldom listen to what other people have to say about Perl - at
least since I stopped developing in it. I did read "The seven deadly
sins" page, but have mostly forgotten that.
And this gives me the feeling that you either haven't been using Perl
for over 4 years, or was never got beyond the absolute beginner
level. In the latter case I can imagine that you are overwhelmed by
Perl. As would one by any language.

I'll admit it's been a while since I did anything other than
debugging. I haven't had much call to do the things that Perl is
really good at (simple re-heavy scripts), so I haven't done much
development in it.

Amazing, how can you debug if you know next to nothing of it?


So either your assessment of my skills is *way* off, or I'm an
*amazing* programmer.
You may be overwhelmed by any language. I'm not.

Sure, LOL. You are so overwhelmed with Perl that you even lack the basic
skills, but yet nag about it a lot.


At this point, I'm *underwhelmed* with Perl. And let's see - less than
one conversation a year for the past nine years. Yeah, that's nagging
about it a lot. I'd say both your assessments were equally accurate.
In a pure language such things are in the library.

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

I don't have access to a small one I wrote ages ago. But I am sure there
are enough people who can provide you with one, or otherwise, as a
skilled programmer, you would be able to write one in a day or less.


In other words, I have to write in a dialect of the language. As I'm
sure you're aware by now, that's a sign of bad language design. No
thanks.
You keep harping on restrictions. Garbage collection isn't a
restriction. It's a feature.

It's also a restriction. Why do you think in Java one can call the gc
explicitly?


If it's a restriction, there must be something it restricts you from
doing. Care to tell me exactly what garbage collection keeps you from
doing?
Moreover, good programmers rarely need to be restricted. But I don't
see garbage collection as an anti-memory-leak restriction (which it
can't be in all cases) but as a time saver.

I think garbage collection is a time saver as well. It saves me time
hunting bugs caused by incorrect usage of the facilities it
replaced. It may save a little time in not having to write explicit
deallocation instructions, but that's trivial.

In my case it saves time the other way around, I consider correct usage
trivial, but the typing all the time...


I guess you haven't had to chase many bugs related to missing free's
(though those have gotten easier to find with modern free/alloc tools)
or a reference through a free'd pointer. I can type free(mem) an awful
lot of times in the time it takes to read through the stack trace from
the first crash related to one of those bugs.
Ok, so it's only the skill level of the programmers that's the cause
of the changes. So why does the language offer bad choices to the
programmers?

Who are "the programmers" to you? And what is a bad choice?


The programmers in this case are the people who write code in the
language under discussion. A bad choice is the one that skilled coders
don't make. TOOWTDI makes the right choice obvious to even the least
skilled programmers, and makes wrong choices painful. TMTOWTDI makes
wrong choices - or ugly code - easy. Which is one of the reasons that
multiple nearly identical constructs is a bad design.
That's as silly as a language having garbage collection
and alloc/free. Good programmers won't use the latter.

Good programmers in your opinion. A really good programmer would use
alloc/free, if garbage collection works as it does with Java, in those
cases it's better.


So the jvm implementations you're familiar with have really bad
garbage collectors. A good programmer won't immediately abandon either
Java or garbage collection. They'd check out other implementations of
the jvm to see if one of those has a better garbage collector. Failing
that, they'd check out other languages to see if one of them might
have a garbage collector that will perform adequately to the problem
at hand - assuming such is politically feasible. After that, they'd
begin to consider alternatives to garbage collection. Explicit
alloc/free is one possibility. A stack-based allocation scheme is
another. There are probably others as well. You can't simply tag one
as "better" without knowing what the problem domain is.
Which Perl? ActiveState Perl does indeed come with HTML, and XML
parsers, SMTP, etc, clients. Web server(s), I have no idea, haven't
needed a Perl webserver, I doubt it comes with AS Perl.

Sure, anyone can bundle whatever they want up as a distribution, but
that doesn't mean those things are part of the base library. The
original contention which caused your reaction was that Python came
with a larger base library than Perl does. It seems that this claim is
still true even if you use the ActiveState distribution of Perl.

I have no idea. Which modules do you miss in Perl that come with Python?


I already pointed out some modules that come with Python that Perl (as
installed by my system packaging system) doesn't come with. A quick
check shows that it still doesn't come with mail-handling modules -
parsing mailboxes, parsing mail messages, and sending mail via smtp. I
tend to use those on a regular basis. I'm sure I can find them in CPAN
if I really need them, though.
That's odd - all the
packages I see seem to want to install those things from CPAN.
Is there such a centralized place for libraries for Python?

Unfortunately, no. PyPI is the one linked to from the web site. It
doesn't have CPAN's auto-install capabilities

So instead of the ability to install a Perl module with just a few lines
of typing, one has to eh... what? Use google? Ask around?


Personally, I check PyPI, and a few other sites. Google helps at
times. If all else fails, I ask on c.l.python.
So it seems I am right: the overwhelming effect of "many ways" is
mainly seen by absolute beginners, who are able to make up many ways,
even if there is just one or two :-D.

Are you afraid to answer the question? Do you or do you not use the
"foreach" loop in perl? Until you do, I can't know why my asking that
question makes you call my perl experience into question.

I haven't been using *foreach* for quite some time, I use *for* all the
time. Which is just because I am lazy.


You make my case for me. You write in a subset of Perl that excludes
"foreach". Is that the "absolute beginner" or the "beginner" subet?
Or maybe it's a subset that doesn't depend on the skill level of the
programmer.
Perl 4? Even Perl 5 is almost 11 years old. Which version of Perl 5
are you talking about?

Yup - I was using Perl back when it was at version 3. The currently
installed Perl is 5.8.5.

You used Perl 3!?? LOL! For what? To write poetry? I mean, if you used
version 3, and you still make extremely basic mistakes...


No, I wrote systems adminstration utilities in Perl 3. I wrote web
application in Perl 4. I just maintain Perl 5. Your "basic mistakes"
was forgetting the warts on strip. BFD.
>> Right - Perl makes writing ugly,
> Nope, the programmer does that.
No, the programme writes the ugly code. Perl makes it easy.
So, and who is to blame? Would you trust a programmer who can only
write code in a certain way because he is restricted by the langauge
to do so?

Which would you trust more - a programmer who had to unlearn all his
bad habits, or one who never had the chance to develop them?

Neither, and think about that for some time.


So you write all your code yourself, and don't avail yourself of Perls
best feature - CPAN?
No. If this was crossposted in a Perl group, by now quite a lot of
people would have pointed you out, probably in a less nice way, that
your Perl skills are of a person who hasn't even gone beyond the
first few chapters of "Learning Perl".

Oh, bullshit. I admit my perl skills are rusty - that comes from
having found a language that is superior to it across a large
collection of problem domains. I never read "Learning Perl". It didnt'
exist when I learned Perl.

So you got stuck with Perl 3 somehow?


I got stuck with the latest version of Perl that was available. It was
a major improvement over shell scripts. That's not saying a lot, even
today - and shell scripting has improved since then.
Even if it is true, the point still stands - Perl programs are less
maintainable than Python programs. I maintain that the difference in
philosphy on the number of ways to do things is a cause for that.

But to me, you don't sound qualified to make that statement, your Perl
skills are, well, rusty.


Ok, ask in both groups. See how many people you find that maintain
both who feel that each is better. I'm positive you'll find the
majority who do both find Python programs more maintainable.
And a bad programmer will go at great length explaining how bad the
tools are, because he has to learn them :-D

A good programmer will compare the toolset to others he's familiar
with,

which only can be done when he/she knows both (almost) equally well.


Nope. A quick survey of a toolset is all that's needed to make a first
approximation as to it's quality - to someone who's familiar with
enough toolsets, anyway.
and choose the toolset that is best for the jobs he does. An
evangelical programmer will then spend a lot of effort explaining why
one toolset is better than another.

without a good understanding of the other toolset, yup.


A good understanding of toolset design allows you to point out flaws
in a toolset without becoming intimately familiar with it. For
instance, mutliple nearly identical ways to express the same construct
is always a flaw in a toolset. Which has been the point I've been
making the whole time.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jul 19 '05 #60
Jeremy Bowers <je**@jerf.org> writes:
On Mon, 25 Apr 2005 23:26:56 +0000, John Bokma wrote:
Mike Meyer wrote:
John Bokma <jo**@castleamber.com> writes:


Nobody ever changed their mind as a result of a 20-thread endless
reply-fest. As usual, the posters aren't about to admit anything, and none
of the bystanders are reading any more.


Yeah, but I'm having fun. What's the point of usenet, if it's not fun?

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jul 19 '05 #61
Mike Meyer wrote:
John Bokma <jo**@castleamber.com> writes:
You already showed code like:


Actually, I never showed you this code.


hence *like*, and yes you did, in a footnote.
In this case, the good rewrite invokes the well-known logical operator
"not":

if not condition then
something
unless condition then
something

Weird, we use constructions like that in normal language all the time,
and when we program it's suddenly bloat?
it makes the code more readable.
Then why do most Perl programmers consider unless "! a good idea"?

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


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


*sigh* in your obsession to call me argumentative, your skipped over it:
"it makes the code more readable"
wasn't creating some silly list. The etc was a giveaway.


Um, I suggest you brust up on your English skills.

^^^^^
What you created was a list. Not in Python or Perl, but in English.
I doubt if any Perl programmer in the given context would have any
problem with it, but lets drop it.
Oh, I understood it.
Sure, is that why you talked about a tuple? But, lets drop it.
And so far, I've only said *two* things were wrong with Perl. One is
that it provides more than one way to do things - which point you've
made for me by arguing about how you did/didn't choose the right one
in an example.
If you think I gave a wrong example, give the right one. The only reason
for an argument was your lack of knowledge about split and map, which
only tells something about you, not Perl.
I also said that it's failure to flag assigning the
output of map/grep (there's that multiple choices thing again)
There is that lack of understanding again: map and grep are two
different things. I can't help if you consider map/grep a *choice*
to a
scalar when you wanted a list was bad. You haven't argued that I was
wrong about Perl in either case.
*sigh* if you want a list, you assign it to something that can handle a
list. If you assing a list to a scalar, you get the count. So if you
want to select items out of a list on a criteria, you use grep in a list
context, if you want to count the items, guess...
Amazing, how can you debug if you know next to nothing of it?


So either your assessment of my skills is *way* off, or I'm an
*amazing* programmer.


If you consider map/grep a multiple choice, what do you think?
(rethorical question).
It's also a restriction. Why do you think in Java one can call the gc
explicitly?


If it's a restriction, there must be something it restricts you from
doing. Care to tell me exactly what garbage collection keeps you from
doing?


real time guaranteed memory allocation/deallocation (which might be
fixed by now in Java)
In my case it saves time the other way around, I consider correct
usage trivial, but the typing all the time...


I guess you haven't had to chase many bugs related to missing free's


In my own code? I can't remember. In code written by other people: in
the cases they forget to free memory they did so many other things wrong
that I sincerly hope they have found other work by now.
skilled programmers, and makes wrong choices painful. TMTOWTDI makes
wrong choices - or ugly code - easy.
Especially if one keeps mixing up map and grep :-D
Which is one of the reasons that
multiple nearly identical constructs is a bad design.
Worse is when self proclaimed perl programmers call map and grep
identical constructs...
So the jvm implementations you're familiar with have really bad
garbage collectors.
I have no idea if this has changed recently. The last thing I read about
it is that there are 4 kinds of garbage collection one can select in
Sun's implementation.
A good programmer won't immediately abandon either
Java or garbage collection. They'd check out other implementations of
the jvm to see if one of those has a better garbage collector.
Uhm, people often pick Java because of write once, run everywhere. So
that is not always, or even rarely an option.
another. There are probably others as well. You can't simply tag one
as "better" without knowing what the problem domain is.
I didn't say better, what I meant: there are situations real time
free/alloc is prefered, unless my knowledge of gc in general is
outdated.
I haven't been using *foreach* for quite some time, I use *for* all
the time. Which is just because I am lazy.


You make my case for me. You write in a subset of Perl that excludes
"foreach". Is that the "absolute beginner" or the "beginner" subet?
Or maybe it's a subset that doesn't depend on the skill level of the
programmer.


"The foreach keyword is just a synonym for the for keyword, so you can
just use foreach and for interchangeably, whichever you think is more
readable in a given situation" (Programming Perl, 3rd edition, p118)
You used Perl 3!?? LOL! For what? To write poetry? I mean, if you
used version 3, and you still make extremely basic mistakes...


No, I wrote systems adminstration utilities in Perl 3. I wrote web
application in Perl 4. I just maintain Perl 5. Your "basic mistakes"
was forgetting the warts on strip. BFD.


The BFD was calling map / grep a *choice*. I am not sure about for and
foreach, it could be that you call for $item ( @list ) a foreach loop,
which I hope. Otherwise, if you really thought there where two
*different* loop ops (as you wrote) then there is another BFD to add.
Which would you trust more - a programmer who had to unlearn all his
bad habits, or one who never had the chance to develop them?

Neither, and think about that for some time.


So you write all your code yourself,


Ok, let me rephrase that: think about that for a long time.
So you got stuck with Perl 3 somehow?


I got stuck with the latest version of Perl that was available. It was
a major improvement over shell scripts. That's not saying a lot, even
today - and shell scripting has improved since then.


Perl 1.0?
Even if it is true, the point still stands - Perl programs are less
maintainable than Python programs. I maintain that the difference in
philosphy on the number of ways to do things is a cause for that.

But to me, you don't sound qualified to make that statement, your
Perl skills are, well, rusty.


Ok, ask in both groups. See how many people you find that maintain
both who feel that each is better. I'm positive you'll find the
majority who do both find Python programs more maintainable.


I just did (asking). And hope to be able to answer your question in a
year or so. Oh, and I want to add to your latter sentence: code written
by programmers who didn't learn Perl in 3 hours by downloading and
editing CGI scripts.
A good programmer will compare the toolset to others he's familiar
with,

which only can be done when he/she knows both (almost) equally well.


Nope. A quick survey of a toolset is all that's needed to make a first
approximation as to it's quality - to someone who's familiar with
enough toolsets, anyway.


Weird: I am going study Python for at least one year. Unless you call
that a quick survey :-D.
A good understanding of toolset design allows you to point out flaws
in a toolset without becoming intimately familiar with it. For
instance, mutliple nearly identical ways to express the same construct
is always a flaw in a toolset. Which has been the point I've been
making the whole time.


So a hammer is a bad tool, since one can use a scewdriver...

I always wondered why an artist, like for example a painter, has so many
nearly identical tools...

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Jul 19 '05 #62
Mike Meyer wrote:
Yeah, but I'm having fun. What's the point of usenet, if it's not fun?


:-D. I am always amazed how people now the opinion of "the bystanders", I
mean, are they having secret polls I am not aware of?

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Jul 19 '05 #63
John Bokma <jo**@castleamber.com> writes:
Mike Meyer wrote:
John Bokma <jo**@castleamber.com> writes:
You already showed code like: Actually, I never showed you this code.

hence *like*, and yes you did, in a footnote.


Yes, but *I* didn't say like, because I wanted to point out that you
had purposely uglified it.
In this case, the good rewrite invokes the well-known logical operator
"not":

if not condition then
something


unless condition then
something

Weird, we use constructions like that in normal language all the time,
and when we program it's suddenly bloat?


If you want to program in a normal language, I recommend
COBOL. Natural languages have a different purpose than programming
languages, which are designed to communicate algorithms clearly and
concisely. In that domain, it's just bloat.
> it makes the code more readable.
Then why do most Perl programmers consider unless "! a good idea"?
Reread the last part of the last sentence you quoted above.

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

*sigh* in your obsession to call me argumentative, your skipped over it:
"it makes the code more readable"


Let's get the facts straight here. I may have skipped over it the
first time, but I didn't call you argumentative then. It wasn't until
you argumentative until after you deleted it that I said you were
argumentative.
What you created was a list. Not in Python or Perl, but in English.

I doubt if any Perl programmer in the given context would have any
problem with it, but lets drop it.


No, let's not. It's a perfect example of why having multiple ways to
do things is a bad idea.
Oh, I understood it.

Sure, is that why you talked about a tuple? But, lets drop it.


No, I talked about a tuple to point out that doing it right made
something a machine could parse properly, with no thought at all.
And so far, I've only said *two* things were wrong with Perl. One is
that it provides more than one way to do things - which point you've
made for me by arguing about how you did/didn't choose the right one
in an example.

If you think I gave a wrong example, give the right one. The only reason
for an argument was your lack of knowledge about split and map, which
only tells something about you, not Perl.


I already gave the right one. The one with the optional parens put
back in.
to a
scalar when you wanted a list was bad. You haven't argued that I was
wrong about Perl in either case.

*sigh* if you want a list, you assign it to something that can handle a
list. If you assing a list to a scalar, you get the count. So if you
want to select items out of a list on a criteria, you use grep in a list
context, if you want to count the items, guess...


You still haven't argued that I'm wrong about Perl. You're arguing
about whether or not a behavior is bad, not the behavior.

Trying to argue that I'm wrong because I'm wrong about Perl's behavior
being bad would be a lot more effective if you pointed out where the
descriptions of bad behavior were incorrect.
It's also a restriction. Why do you think in Java one can call the gc
explicitly?

If it's a restriction, there must be something it restricts you from
doing. Care to tell me exactly what garbage collection keeps you from
doing?

real time guaranteed memory allocation/deallocation (which might be
fixed by now in Java)


That's an implementation feature, not a language feature. That's an
implementation feature, not a language feature. I might also note that
you're wrong about alloc/free, in that you don't get real time
guaranteed memory allocation/deallocation with it, either.

Care to try again?
In my case it saves time the other way around, I consider correct
usage trivial, but the typing all the time...

I guess you haven't had to chase many bugs related to missing free's

In my own code? I can't remember. In code written by other people: in
the cases they forget to free memory they did so many other things wrong
that I sincerly hope they have found other work by now.


I'd say you've never done anything but trivial
skilled programmers, and makes wrong choices painful. TMTOWTDI makes
wrong choices - or ugly code - easy.

Especially if one keeps mixing up map and grep :-D


Righ - you once again avoid the real issue.
So the jvm implementations you're familiar with have really bad
garbage collectors.

I have no idea if this has changed recently. The last thing I read about
it is that there are 4 kinds of garbage collection one can select in
Sun's implementation.


If you had enough experience with jvm's, you'd know that Sun's wasn't
the only one out ther.
A good programmer won't immediately abandon either
Java or garbage collection. They'd check out other implementations of
the jvm to see if one of those has a better garbage collector.

Uhm, people often pick Java because of write once, run everywhere. So
that is not always, or even rarely an option.


Switching jvm's doesn't mean you switch away from Java. It means you
switch the implementation of the jvm that Java is running on. "Run
anywhere" has nothing to do with this.
another. There are probably others as well. You can't simply tag one
as "better" without knowing what the problem domain is.

I didn't say better, what I meant: there are situations real time
free/alloc is prefered, unless my knowledge of gc in general is
outdated.


Your knowledge of free/alloc is wrong. They don't guarantee real time
behavior. Nor do they guarantee memory allocations.

I'm beginning to think your programming experience is limited.
I haven't been using *foreach* for quite some time, I use *for* all
the time. Which is just because I am lazy.


You make my case for me. You write in a subset of Perl that excludes
"foreach". Is that the "absolute beginner" or the "beginner" subet?
Or maybe it's a subset that doesn't depend on the skill level of the
programmer.


"The foreach keyword is just a synonym for the for keyword, so you can
just use foreach and for interchangeably, whichever you think is more
readable in a given situation" (Programming Perl, 3rd edition, p118)


You didn't bother refuting the point that you've created a subset of
Perl which never uses "foreach".
A good programmer will compare the toolset to others he's familiar
with,
which only can be done when he/she knows both (almost) equally well.


Nope. A quick survey of a toolset is all that's needed to make a first
approximation as to it's quality - to someone who's familiar with
enough toolsets, anyway.

Weird: I am going study Python for at least one year. Unless you call
that a quick survey :-D.


That's enough time to become proficient in a language. Which isn't
required if all you want to do is decide if it's well-designed.
A good understanding of toolset design allows you to point out flaws
in a toolset without becoming intimately familiar with it. For
instance, mutliple nearly identical ways to express the same construct
is always a flaw in a toolset. Which has been the point I've been
making the whole time.

So a hammer is a bad tool, since one can use a scewdriver...


I didn't say a word about bad tools.
I always wondered why an artist, like for example a painter, has so many
nearly identical tools...


Because they do different things with them. while and if are nearly
identical tools - they both have a keyword, a boolean and a block of
code. But they do different things.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jul 19 '05 #64
Jeremy Bowers <je**@jerf.org> wrote:
Nobody ever changed their mind as a result of a 20-thread endless
reply-fest. As usual, the posters aren't about to admit anything, and none
of the bystanders are reading any more.


Well I am reading... always interested to learn.

Axel


Jul 19 '05 #65
JZ
PHP can do the same. For ADOdb (excelent database wrapper)it can be as
the following:

$conn->Execute('UPDATED foo SET bar=? WHERE id=?', array("foo'bar",
123));

Jul 19 '05 #66
Mike Meyer wrote:
John Bokma <jo**@castleamber.com> writes:
Mike Meyer wrote:
John Bokma <jo**@castleamber.com> writes:
You already showed code like:
Actually, I never showed you this code. hence *like*, and yes you did, in a footnote.


Yes, but *I* didn't say like, because I wanted to point out that you
had purposely uglified it.


your footnote:
"
*) I still remember seeing FORTRAN programmers writing ALGOL-W
conditionals as:

if not condition then
else
begin
code
end
"

mine purposely uglified version:

"
if condition then
nothing
else
something
"
If you want to program in a normal language, I recommend
COBOL. Natural languages have a different purpose than programming
languages, which are designed to communicate algorithms clearly and
concisely. In that domain, it's just bloat.
I, and I am sure I am not alone, consider unless not just bloat. To me
it serves a purpose: "communicate algorithms clearly" :-)
What you created was a list. Not in Python or Perl, but in English.

I doubt if any Perl programmer in the given context would have any
problem with it, but lets drop it.


No, let's not. It's a perfect example of why having multiple ways to
do things is a bad idea.


Ok, again:

" an obvious solution (sort a list; split a string on whitespace; pull
select list elements based on a criteria of some kind; search a file
for lines with a given word in them; etc.) you'd get back the same
answer from almost all of them.
And what makes you doubt it would be different with Perl? :-D

( sort @alist, split ' ', $astring, grep criteria, @list, etc )
"

I skip over your "grep is wrong, should be map", and "split is also
wrong":

The most funniest reply I ever read:

"
You also chose the wrong way to do things globally, by leaving off the
optional parens on the function invocations. That makes the list a
PITA to parse, in that you have to know the number of arguments to
each function in order to parse the list you provided.

Consider the python version:

(alist.sort(), astring.split(), [x for x in alist if criteria
(x)])
"

I mean, that last part is extremely weird, I mean, in your original
question you use ; to separate each question: how does Python parse
that? Really Mike, give it up: you gave a few problems, I answered a
few, everyone could have seen that I separated each solution with a
comma, (almost each keyword is a dead giveaway since they match the word
in your original question). And you are suddenly saying that the way I
decided to write my answer says something about Perl? How much rope do
you need?

Moreover, in your reply you clearly showed that you mixed up map and
grep. Those are quite fundemental building blocks in perl, it's like
mixing up an array with a hash.
Oh, I understood it.

Sure, is that why you talked about a tuple? But, lets drop it.


No, I talked about a tuple to point out that doing it right made
something a machine could parse properly, with no thought at all.


So you have been assimilated by the borg then? And do you think one
can't write a parser that is able to correctly parse my reply? I give
you a hint:

if a comma is followed by a keyword (bareword), it's a new statement.
etc is a no-op statement. Or should my answer be pure Perl? Is your
group of problems pure python? Perl?
Trying to argue that I'm wrong because I'm wrong about Perl's behavior
being bad would be a lot more effective if you pointed out where the
descriptions of bad behavior were incorrect.
If you can't distinguish map from grep, have problems with split (and
maybe even white space), and have parsing problems (e.g. see a Perl list
where there is none), it's going to be a bit hard, don't you think?
real time guaranteed memory allocation/deallocation (which might be
fixed by now in Java)


That's an implementation feature, not a language feature.


*sigh*
That's an
implementation feature, not a language feature. I might also note that
you're wrong about alloc/free, in that you don't get real time
guaranteed memory allocation/deallocation with it, either.
That depends on the platform, of course.

[ memory allocation and freeing bugs ] I'd say you've never done anything but trivial
For someone who claims to maintain perl code but mixes up grep and map,
and seems to have a hard time at understanding Perl in general, this is
quite a bold statement, to say the least.
Righ - you once again avoid the real issue.
The real issue seems to be your *lack* of Perl skills.
I have no idea if this has changed recently. The last thing I read
about it is that there are 4 kinds of garbage collection one can
select in Sun's implementation.


If you had enough experience with jvm's, you'd know that Sun's wasn't
the only one out ther.


If your English reading skills where sufficient enough, you would have
been able to understand from my use of the word implementation that I am
aware of this. You want me to spell it out in Perl? Oh, no wait... >:->
A good programmer won't immediately abandon either
Java or garbage collection. They'd check out other implementations
of the jvm to see if one of those has a better garbage collector.

Uhm, people often pick Java because of write once, run everywhere. So
that is not always, or even rarely an option.


Switching jvm's doesn't mean you switch away from Java. It means you
switch the implementation of the jvm that Java is running on. "Run
anywhere" has nothing to do with this.


Maybe do some research into which jvm's are available for which
platforms, and also the problems some people have run into because "Run
anywhere" is not that easy even if there is a jvm "anywhere". But again,
maybe this all has recently changed.
I didn't say better, what I meant: there are situations real time
free/alloc is prefered, unless my knowledge of gc in general is
outdated.


Your knowledge of free/alloc is wrong. They don't guarantee real time
behavior. Nor do they guarantee memory allocations.


Weird, I have worked on enough platforms where both are the case, if you
know what you are doing. Maybe that's the difference ;-)
I'm beginning to think your programming experience is limited.
Coming from a Perl "maintainer" that mixes up map and grep, that's quite
a bold statement. Even if you are right (which you are not), I doubt you
are qualified to make such a statement.

[ for is a synonym for foreach ] You didn't bother refuting the point that you've created a subset of
Perl which never uses "foreach".


And you think that someone who *did* bother to learn Perl has a problem
with reading my for's? Is slowed down? Has to stop, think, read up the
documentation, is confused, etc?

I recommend to buy Learning Perl. I am sure that a skilled programmer,
as you claim to be, can finish reading it in 3 hours. Re-read it again,
and make some notes.
Weird: I am going study Python for at least one year. Unless you call
that a quick survey :-D.


That's enough time to become proficient in a language. Which isn't
required if all you want to do is decide if it's well-designed.


Let's just say that I define "proficient in a language" different.
A good understanding of toolset design allows you to point out flaws
in a toolset without becoming intimately familiar with it. For
instance, mutliple nearly identical ways to express the same
construct is always a flaw in a toolset. Which has been the point
I've been making the whole time.

So a hammer is a bad tool, since one can use a scewdriver...


I didn't say a word about bad tools.


Ok, flawed.
I always wondered why an artist, like for example a painter, has so
many nearly identical tools...


Because they do different things with them.


Yup.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
Jul 19 '05 #67
Steve Holden <st***@holdenweb.com> wrote in message news:<ma**************************************@pyt hon.org>...
John Bokma wrote:
Alan Little wrote:

Steve Holden <st***@holdenweb.com> wrote:
Your statement then becomes

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

which is clearly not such a good idea.

I'm sure Steve is very well aware of this and was just providing a
simple and obvious example, nevertheless it might be worth pointing
out that anyody who connects their web application to their database
as a user that has DROP TABLE privileges, would clearly be in need of
a lot more help on basic security concepts than just advice on
choosing a programming language.

True. But how does it stop someone who uses inserts? (I exclude the case
inserts are not needed).
Inserts are indeed not needed, if you really don't want to allow them.
The web app user connects to a schema that has no direct write
privileges on anything. Instead it has execute permissions on stored
procedures in another schema that do the writes. In Oracle, at any
rate, the stored procedure then runs with the privileges of the schema
it is in, but the calling user doesn't need or get those privileges.
Over the top in many cases, but it's an extra layer of defence if you
want it.

This goes back to the point somebody made earlier on in the thread -
many web applications can be implemented as fairly simple wrappers
around properly designed databases. "Properly designed" includes
giving some thought to table ownership and privileges.

One should stop SQL injection always, no matter if the database takes care
of it or not. There is no excuse (like, yeah, but I set up the privileges
right) for allowing SQL injection, ever.
Wasn't suggesting that for a moment.

Correct. If a thing can't go wrong, it won't.

In security several levels of defense are better than just one, so
database authorization and SQL injection removal should be considered
complimentary techniques of a "belt and braces" (US: "belt and
suspenders") approach.

regards
Steve


I completely agree of course. Do both.
Jul 19 '05 #68
On Tue, 26 Apr 2005 00:35:59 GMT, rumours say that Jorey Bump
<de*****@joreybump.com> might have written:
"Lad" <py****@hope.cz> wrote in news:1114254894.512656.297040
@l41g2000cwc.googlegroups.com:
Is anyone capable of providing Python advantages over PHP if there are
any?

As you learn Python, you will find that your PHP code will improve,
possibly becoming more and more concise until it disappears completely.


+1 QOTW
--
TZOTZIOY, I speak England very best.
"Be strict when sending and tolerant when receiving." (from RFC1958)
I really should keep that in mind when talking with people, actually...
Jul 19 '05 #69

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

Similar topics

0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

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

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