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/
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
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.
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
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.
"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.
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/
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
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.
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.
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
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.
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
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));
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
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.
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... This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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...
|
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...
|
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)...
|
by: Defcon1945 |
last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
|
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....
|
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
|
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...
|
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...
| |