PHP Sucks???
Marious Barrier
http://www.bitstorm.org/edwin/en/php/
I did not want to discuss it right now, so... can people please tell me
what you think and what info there is wrong?
Greetings.
The Natural Philosopher
I see nothing wrong, except the assumption that that makes PHP a bad
LANGUAGE.
A slightly inefficient run time environment perhaps.
Jerry Stuckle
Old, out of date and full of inaccuracies.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
Erwin Moller
Some info is correct, some is wrong, and some was true when the article
was written (6 years ago) but not anymore.
But to conclude PHP sucks because of the arguments presented is really
idiotic.
I'll comment on a few:
1. Bad recursion
Jeez. I have NEVER EVER needed recursion in my whole life.
The famous example is directorystructure reading, another thing I never
needed, since I never designed a system that doesn't know what is where
in a directory structure.
I know how to use recursion out of curiosity, not because it is so
useful in every day programming.
To name that as number 1 isn't very impressing.
2. Many PHP-modules are not thread safe
I think that was a valid critic in those days.
I didn't use Apache2 multi threaded in those days either, so no pain.
3. PHP is crippled for commercial reasons
True as far as I know. But as mentioned in the article: there are
solutions. And personally I never had problems with PHP's performance,
most performance bottlenecks I encounter are database related.
4. No namespaces
True in 2004, but solved now.
5. Non-standard date format characters
Who cares? Use strftime() if you want that behaviour: it is standard in
PHP. These kind of arguments make no sense... He just needed 10 I guess.
6. Confusing licenses
Maybe he should read them better if he cares so much?
7. Inconsequent function naming convention
Well, that is a valid observation. I am used to it now, but I remember
it irritated me too at one point.
8. Magic quotes hell
That is only a hell for newbies.
9. Framework seldom used
Totally bullshit argument. He is saying PHP sucks because many of its
developers don't use a framework.
That is like saying a car sucks because many of it's drivers don't wear
a safetybelt. The author's logic skills are not top notch.
10. No Unicode
Well, that is true, but PHP can easily handle unicode. mb_* functions
exists for a long time.
So, in conclusion: Mainly poor observations, a few outdated comments,
and two or so good (wellknown) points.
I am not impressed and will happily code on in PHP. ;-)
Regards,
Erwin Moller
>
> Greetings.
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
Marious Barrier
But...
On 07/05/2010 04:00 PM, Erwin Moller wrote:
> 7. Inconsequent function naming convention
> Well, that is a valid observation. I am used to it now, but I remember
> it irritated me too at one point.
What is this about? I really have no idea what that point did mean.
The Natural Philosopher
> In article <4c3239d1$0$22945$e4fe...@news.xs4all.nl>,
> Erwin Moller
>
>> Marious Barrier schreef:
>> > In a chat someone gave me this link.-
>> > > http://www.bitstorm.org/edwin/en/php/
>> > > I did not want to discuss it right now, so... can people please
>> tell me > what you think and what info there is wrong?
>>
>> Some info is correct, some is wrong, and some was true when the
>> article was written (6 years ago) but not anymore.
>>
>> But to conclude PHP sucks because of the arguments presented is really
>> idiotic.
>> I'll comment on a few:
>> 1. Bad recursion
>> Jeez. I have NEVER EVER needed recursion in my whole life.
>> The famous example is directorystructure reading, another thing I
>> never needed, since I never designed a system that doesn't know what
>> is where in a directory structure.
>
> things) to look down a directory structure to see which files there are
> of a certain kind and then build an internal structure based on that. I
> do this when the app starts up in case the user dicked with things
> before the app started (like, moved files around by hand).
>
For that, I have a database.
Erwin Moller
Hi Marious,
> Thanks Erwin, excelent reply and I see I agree with you in most points.
thanks.
>
> But...
>
> On 07/05/2010 04:00 PM, Erwin Moller wrote:
>> 7. Inconsequent function naming convention
>> Well, that is a valid observation. I am used to it now, but I remember
>> it irritated me too at one point.
>
>
> What is this about? I really have no idea what that point did mean.
From the article:
------------------------------------------------------------------------
7. Inconsequent function naming convention
Some function names consist of more than one word. There are three
conventions for combining these words:
1. Glued together: getnumberoffiles
2. Separated with underscores: get_number_of_files
3. Camel case: getNumberOfFiles
Most Languages choose one of these variants. PHP uses all of them.
For example, it you want to convert special characters to HTML entities,
you use the function htmlentities (Words glued together). If you want to
do the opposite, you use its little brother function html_entity_decode.
For some reason the words are now separated by underscores. Why is this
bad? You know there is a function named strpad. Or was it str_pad? Every
time you have to look up what the notation is or wait for an error to
occur. Functions are case insensitive, so for PHP there is no difference
between rawurldecode and RawUrlDecode. This is bad too, because both are
used and because they look different, they will confuse the reader.
------------------------------------------------------------------------
I think that is quite clear.
The critique is simple: PHP developers should have sticked to one way of
glueing words together.
None is 'better' than the other, it is matter of taste.
But using all variants is plainly confusing (and unneeded).
His critique "Functions are case insensitive" also makes sense for me.
htmlspecialchars()
HTMLSPECIALCHARS()
htmlSpecialChars()
hTmLsPeCialcHARs()
is all fine for PHP.
I think this is a matter of taste, but I also dislike that
'flexibility'. Maybe I am a strick guy (I did mainly Java before PHP),
but I like my function names case sensitive.
I also prefer Camel case (htmlSpecialChars) over Fantasy case (eg
hTmLsPeCialcHARs).
Well, who doesn't? ;-).
I hope that clarifies it a little better.
Regards,
Erwin Moller
Thomas Mlynarczyk
> 4. No namespaces
> True in 2004, but solved now.
I wouldn't call that "solved". The way namespaces are currently
implemented in PHP 5.3 does not bring any advantage over prefixing all
my classes with a -- hopefully unique -- identifier. I must include the
namespace declaration in each an every file hoping that I will never
have to change it later. And there is absolutely no guarantee that no
one else will happen to use the same namespace identifier for their own
library which I might happen to use. I would want to be able to do
something like "include 'libA.php' as A" and be able to access the class
Foo defined in that file as A\Foo -- in Python I can do something
similar. Thus, unless I have completely misunderstood something about
namespaces in PHP, they do not solve the problem they're supposed to solve.
> 8. Magic quotes hell
> That is only a hell for newbies.
Yes, an experienced programmer knows how to deal with magic quotes:
Check if they're enabled and if so, remove them. The point is, that I
should not need to have to do this stupid extra work! It is insane to
escape input data -- especially since PHP cannot yet know at that point
how the data will be used and what -- if any -- escaping might be
required. If I'm not mistaken, this "feature" was introduced to protect
newbies from shooting themselves in the foot via SQL injection. And now
you say that it is "a hell for newbies"! Thankfully, magic quotes are
about to be removed from PHP.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
Michael Fesser
>[...]
>But to conclude PHP sucks because of the arguments presented is really
>idiotic.
>I'll comment on a few:
>1. Bad recursion
>Jeez. I have NEVER EVER needed recursion in my whole life.
It's a valuable tool.
>The famous example is directorystructure reading, another thing I never
>needed, since I never designed a system that doesn't know what is where
>in a directory structure.
I often traverse directory structures of arbitrary depth, be it my class
directory (I use an autoloader, which has to know where each class is
stored), picture galleries or directories for downloadable files. In all
these cases there can be (and are) subdirectories, which obviously I
can't hard-wire. So I let my scripts traverse through the directory tree
to see what's there, and doing this recursively is the most elegant and
easiest way here.
Then there are many algorithms, which can be implemented much more
efficient and shorter by using recursion. I'm not talking about the
classic examples like factorial function, Fibonacci or Quicksort, but
for example creating a nested menu bar from data stored in a database or
a sitemap structure.
>I know how to use recursion out of curiosity, not because it is so
>useful in every day programming.
It _is_ useful. Maybe not every day, but every second day. Of course you
can also do it all the iterative way, but properly used recursion can
keep the code really short and much more readable.
Just my 2 cents.
Micha
Marious Barrier
> I hope that clarifies it a little better.
Yep, good info thanks.
Anyway I think this does not make PHP a bad language... One just get
used to it.
The Natural Philosopher
horses for courses. I don't personally think much of PHP, but it does
the jobs I use it for reasonably well, and its popular and well supported.
C is still my favourite language, because I never really found anything
it couldn't do. And it was faster to write than assembler.
Except a call table., I think it should be possible, but I never
figgered the syntax ;-)