Python or PHP?

[John Bokma]

Mike Meyer wrote:

> John Bokma <postmaster at castleamber.com> writes:
> 
>> Mike Meyer wrote:
>>> John Bokma <postmaster at castleamber.com> writes:
>>>> Mike Meyer wrote:
>>>>> Depends on the problem. If it's one of the things for which Python
>>>>> has an obvious solution (sort a list; split a string on
>>>>> whitespace; pull select list elements based on a criteria of some
>>>>> kind; search a file for lines with a given word in them; etc.)
>>>>> you'd get back the same answer from almost all of them.
>>>> And what makes you doubt it would be different with Perl? :-D
>>> Perl's "There's more than one way to do it" attitude.
>> There's doesn't mean that you have to use or know them all. I think 
>> every language here and there more ways to do something. And at a 
>> broader scope, e.g. a simple algorithm, it doesn't matter that much 
>> anymore.
> 
> Except that, as I said elsewhere, that having more than one way to do
> it bloats the language processor

do you really think that for / foreach and things like if / unless bloat 
a language processor? I think you take your "pure programming lanuage" 
way to far, and really don't understand your choice of Python in your 
crusade.

> and increases the semantic load on
> the programmer. The best the programmer can do, as you imply, is to
> ignore the extraneous methods.

I am curious of a list of extraneous methods in Perl (more about the 
size by the way)

> Then the poor programmer has to puzzle
> over them every time they show up in someone else's code.

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

>>> 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,
> 
>> First of all, who cares? Not the programmer.
> 
> Of course the programmer doesn't care. They jyust have to deal with it
> for the rather short development period. The *maintainer* cares,
> though - as they have to deal with it for the life of the program.

You keep confusing me: are you talking about the programmer who designs 
/ maintains the parser? I guess yes. I talk about the programmers who 
use the language. 

>> But I doubt if you are  correct; why is 
>> OP PARAMETER, LIST
>> a PITA to parse, and
>> OP( PARAMETER, LIST )
>> not? I would even say that the former is easier to parse, since there
>> is no need for checking the ( and ) (and matching them).
> 
> Look at the *context*. You wrote
> 
> word word, word word, word, word word, word, word.

Yes, since it where several examples on one line. You gave several 
problems. The etc. was a kind of give away.

>>> N.B.: split(' ', $astring) is wrong as well. In this case, Perl
>>> doesn't provide the right tool for the job; you have to build it
>>> from parts.
>> You either misread your own problem specifications, or you should
>> read perldoc -f split (near the end, it starts with "As a special
>> case," ) 
> 
> No, I missed the wart hiding under the "special case". How, pray tell,
> do you do the equivalent of Python's string.split(' ') in Perl?

split /PATTERN/,EXPR (from perldoc -f split), so:
      ^^^^^^^^^

split / /, $string

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

Which one?

>> Same could be said of floating point numbers, or complex numbers, or 
>> lists, dictionaries, etc. etc.
> 
> Right. And for each of those, there are languages that don't have them
> as a built in type.

True, perl has no built in complex numbers.

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

>> Quite some people have been "tweaking" CGI scripts
>> Quite some people "know" PHP, and hence consider themselves Perl 
>> programmers.
> 
> Quite right. Neither is in the set of Perl things I maintain.

Does that matter? What matters is what are the skills and background of 
the Perl programmer who wrote the code you maintain.

>>> part of the grammar of the language, and are a recent addition. It's
>>> not clear how Python should evolve with them added to the language.
>> More fat: so I would say: learn to live with it. I only see
>> advantages. If you want a minimal set of operations, I recommend
>> programming ARM assembly, and don't go beyond ARM3 :-D.
> 
> You could also say more bloat. It's not a good thing. I don't want a
> minimal set of operations; I want an orthogonal 1-1 coverage of
> operations.

ARM assembly, told you ;-)

> That's will account for the least bloat in the processor,
> the least load on the programmer, and the least bad code.

ARM, maybe even ARM2. And the last thing depends on you.

>> seconds. Moreover, garbage collection gives newbies the impression
>> that everything is handled automatically, and hence, they forget that
>> other resources are less unforgiven, and *have to be* released.
> 
> Other resources are less forgivving only if they are badly
> designed.

Sure, a resource outside of your program that has certain limits is 
badly designed. Yup, a database for example.

> That means they *should* be released, but not *have to be*
> released.

Trust me: they *have to be* released.

> Consider the file type in Python. It'll be closed after
> you're through with it, guaranteed. However, garbage collection isn't
> triggered by running out of file descriptors, so you *should* close
> them.

Or otherwise?

>> A beginner will find a way. A nice example is garbage collection, 
>> beginners think they don't have to think. And then suddenly things
>> pop up like: memory leaking, how are circular references handled, and
>> oops, suddenly things like weak references are needed. Add, things
>> like threading, and shared resources, resources that are limited in
>> one way or another and I doubt programming has become easier, or less
>> error prone.
> 
> Having dealt with memory leaks in C (and other such languages) for a
> decade, I'd say programming is *much* easier than it would be if you
> didn't have some form of garbage collection.

Easier, sure. But does it turn beginners in rock solid programmers?

>> Has anyone ever did serious research to the number of bugs per 10k
>> lines for several programming languages?
> 
> Yeah. The LISP community did some research on garbage collection
> vs. explicit allocate/free a couple of decades ago. The explicit
> allocate/free methodology was found to be noticably more bug
> prone. Like I said, those date from a couple of decades ago, so I've
> lost the reference and google didn't turn anything up.

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?

>> I remember to have read that air bags makes people drive more
>> reckless. I am quite convinced the same holds for programming
>> languages. A language can't cover your behind, so to speak.
> 
> Could you provide examples of what kind of behavior you're talking
> about? What would be the analog of "driving more reckless" given that
> I've got a garbage collector?

I already gave that one: forgetting to release resources which are not 
unlimited.

> Of course, if you really believe that all the protections are a waste
> of language spec, you should be writing assembler.

Since programming languages have several more advantages then 
"protecting" and "guiding" and "limiting" programmers, why? 

>> potential bugs is often equal to something people *think* a beginner
>> is going to make.
> 
> Yes, but potential bugs even more often turn up in *real*
> programs. I've fixed enough bogus pointer/using free'd memory/memory
> leaks in C to know that.

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

>> and if they are not hermits, they choose the ones they see the most 
>> often used (unless it's Perl golf).
> 
> Which means they adopt to their subset of the community. Which means
> that supporting code from another community will in practice require
> learning a new programming language that happens to have a syntax they
> are familiar with.

What makes you think there are isolated communities?

>> blocks. Perl is like legos. What you want sounds a lot like legos
>> that can instead of round thingies to connect them uses triangles, so
>> there is only one way to stack them. Oh, and you want them dull grey.
> 
> Nope, I make heavy use of libraries. The Python standard library isn't
> exemplary, and it some cases provides overlapping functionality.

I haven't seen a library that doesn't :-D

> But
> it does try to avoid that. It also tries to come with "batteries
> included". You can get an aweful lot done in Python without ever going
> to third party libraries. With Perl, you wind up going to CPAN for a
> lot of things - which puts you back into TMTOWTDI land.

How long haven't you been in touch with Perl? 

> I want programming to be the professors route. I don't want to worry
> about which for loop to use - I want there to be just one for loop, so
> I take that one and *get on with solving the problem*. Having multiple
> for loops (or other TMTOWTDI things) bloats the language
> processor/library and increases the load on the programmer to no
> benefit.

I use either for or while. 

> True. The WWW was extant when I learned Python, so I could learn it by
> reading the documention on the web site, and looking through the
> library. Perl, on the other hand, I had to learn from the
> documentation that shipped with it, and the library that shipped with
> it. Come to think of it, Python has a larger library than Perl as
> well.

How did you measure this? And which distribution of Perl are you talking 
about?

>> Yes, most languages make it clumsy and frustrating. Perl is a rare 
>> exception.
> 
> Right - Perl makes writing ugly,

Nope, the programmer does that.

> slow code easy. Python makes it
> hard. I think this makes python the superior language.

And I think that there is the main problem in your whole story. You 
think this is a quest for superiority. It isn't.

>> what everything means and does by trial and error. As I already
>> wrote: the more than one way is more often the *combination* of well
>> known building blocks.
> 
> Now you're trying to change the story. But I know better. Perl
> provides multiple ways to do things at the syntactic level, and that's
> the root of the problem. There are two iterative loops.

for and foreach? 

> There are two conditional loops.

while and do while?

> There are two conditional execution statements, not

if and unless?

> counting the variants that conditionalize the execution of a single
> statement.

? :, and and or

( hmmm, and or trick ;-) )

> There are two different syntaxes for invoking builtin
> functions (though I don't think one of them works on user-defined
> functions; never tried it).

Uhm, you mean with and without () ? Yes, you can do that with user-
defined functions.

But if this all bothers you *this* much, I am afraid that the problem is 
really behind the keyboard :-)

>> But who writes this code? The language, or the programmer? A
>> programmer who writes ugly Perl code is suddenly going to be a
>> skilled Python programmer? Are you serious?
> 
> No, he's not going to be a skilled Python programmer. But you avoiding
> ugly code in Python doesn't take a skilled programmer.

Funny, I saw recently something I consider ugly code, written by someone 
I thought was a skilled programmer.

>>> After all, "You can write FORTRAN in any
>>> language(*)". If I have to maintain the code, I'd *much* prefer that
>>> the language make it hard to write ugly code, as I'm that much less
>>> likely to get ugly code to maintain.
>> Nonsense.
> 
> I make that claim based on experiene maintaing both Perl and Python
> code. What basis do you have for calling it nonsense.

If you are talking about maintaining your own code, maybe you are right. 
But I claim that it's nonense that code written by other people, with 
clearly different programming skills compared to the maintainer are a 
PITA, no matter what language is used.

>>> TMTOWTDI makes it easy to write
>>> ugly code. TOOWTDI makes it hard to write ugly code.
>> And the funny thing is: it shouldn't matter to a skilled programmer.
>> And an unskilled programmer will make up for the TOOWTDI restriction
>> in more ways than you and I can imagine.
> 
> I don't agree. It doesn't say "There's one obvious to the skilled
> programmer way to do it." It says "There's one obvious way to do it."

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.

-- 
John                               MexIT: http://johnbokma.com/mexit/
                           personal page:       http://johnbokma.com/
        Experienced programmer available:     http://castleamber.com/
            Happy Customers: http://castleamber.com/testimonials.html