Python or PHP?

[Mike Meyer]

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

 

[John Bokma]

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?

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"

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

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

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)

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.

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)

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.

So you write all your code yourself,

Ok, let me rephrase that: think about that for a long time.

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?

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.

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

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

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

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

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

 

[John Bokma]

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

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

 

[Mike Meyer]

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.

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.

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

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.

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.

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.

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

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

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

Righ - you once again avoid the real issue.

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.

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.

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.

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

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.

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

 

[Axel]

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

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

Axel

 

[JZ]

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

 

[John Bokma]

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"

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.

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?

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.

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

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.

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.

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.

I didn't say a word about bad tools.

Ok, flawed.

Because they do different things with them.

Yup.

 

[Alan Little]

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.

Wasn't suggesting that for a moment.

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

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

regards
Steve

I completely agree of course. Do both.

 

[Christos TZOTZIOY Georgiou]

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