Fog Creek Software
Discussion Board

Joel's PHP bashing not fair

On  Joel claims that "PHP has almost complete ignorance of character encoding issues".

That's quite out of proportion, see:

Though native support is not yet ready, unicode multibyte support can be accessed via module.

On  it serves quite well for Esperanto, Chinese, Greek and many other languages.

Marek Moehling
Wednesday, April 21, 2004

No, his php bashing is quite fair. Php is a young language designed specifically for the web, and there's no reason why it shouldn't have had native Unicode support for years now.

Even Perl--which is now 15 years old--has native support for unicode in the form of UTF-8.

1 bowl. 100 percent.
Wednesday, April 21, 2004

If you need unicode support, then Joel's criticism is more than fair.  I personally solve the problem by being a language bigot, and if my eight bit character set can't handle your language, I'm not that worried.  That's not a good way to sell to an international market, but my market barely crosses US State lines, let alone international lines. 

Needing to internationalize your application would be a nice problem to have.  If that's your biggest worry you live a charmed life.

Clay Dowling
Wednesday, April 21, 2004

It's a pretty big problem if you are the sole developer for a dot-com carcass with offices in 10 countries.

Wednesday, April 21, 2004

Pretty well effed is how'd I'd describe that situation.  Hope they can all use a character set that encodes in 8 bits.

Clay Dowling
Wednesday, April 21, 2004

Tcl does a great job of dealing with encodings

David N. Welton
Wednesday, April 21, 2004

I had a working site *not* using UTF-8.

Everything was fine.

Then I wanted to use CityDesk to publish some areas of the content.

CityDesk 1 was good.

Then, they upgraded to 2.0 and I wanted some of the features.

Suddenly, it was publishing unicode text... and most of the pages I had had to be redone and the forum software posting system had to be made UTF-8 compliant. Since it was in PHP... damn, I spent quite a while fixing it all.

And then, forget about wordwrap functions etc using UTF-8 ! Especially when mixing with URLs.

So bashing PHP on that is fine, it's really lacking there !

Philippe Back
Thursday, April 22, 2004

So, to summarise, Philippe, you want to bach PHP because Citydesk broke your website? Uh, ok.

Thursday, April 22, 2004

How about PHP not having real arrays, and removing namespace support so's to ensure something like CPAN never forms for it?

Thursday, April 22, 2004

It's a bit unfair to expect all of that of a "Personal Home Page" script tool that mudballed into something beyond control.
Sometimes it seems a bit like someone took my lawnmower, piled on makeshift extentions to make it into a twoseater, some cardboard turned that into a van, and then using a resalvaged greenhouse frame overhaul designated it a truc.Now some people are lauching it with trebuchets and complaining it isn't landing all that well.

Just me (Sir to you)
Thursday, April 22, 2004

The information available at that link leads me to believe that PHP actually can handle multibyte characters transparently.  It's a well hidden fact, in light of the fact that the rest of the documentation pretty explicitly states that if you aren't using an 8 bit character set you're using the wrong tool.

I'm still not going out of my way to internationalize my applications, since I don't have an international market, but it's nice to see that it wouldn't take too much effort.

Clay Dowling
Thursday, April 22, 2004


> How about PHP not having real arrays
PHP's arrays have keys & values, they're multidimensional if needed and can be accessed via regex and countless functions (either predefined or written as needed), so what's not real about them? Of course there are languages with other (possibly superior) models, so what - PHP is not intended to be a C/C++ replacement, it's not about beeing the Schwarzenegger of languages, it's about getting things done.

> and removing namespace support
can be replaced by classes

> so's to ensure something like CPAN never forms for it?
There's a CPAN for PHP since a couple of years, it's called PEAR:

Marek Moehling
Thursday, April 22, 2004

PHP is an unnecessary evil. Perl with a proper templating language, such as Embperl, is just as easy to install. It will instantly be a) faster (Perl is twice as fast as PHP when I benchmark it, but please try it yourself), b) more secure (don't get me started on all the things PHP got wrong, such as escaping and global symbols -- compare that to the 'taint' mode of Perl) and c) access to the whole CPAN, an archive of objects (Perl has been proper OO for over five years, PHP will be ... someday) for accessing just about everything.

Jonas B.
Saturday, April 24, 2004

> Perl is twice as fast as PHP when I benchmark it, but please try it yourself
I did and can't report the same, besides neither your nor my results bear any statistical relevance;
publicized large scale testing don't give any clues for imparity, Google would not use PHP for their cms if it wasn't up to the task.

> don't get me started on all the things PHP got wrong, such as escaping and global symbols
> compare that to the 'taint' mode of Perl
Perl's got -t (and other nice features, I won't deny that), PHP got open_basedir, safe_mode and register_globals which can be turned 0/1 as safety requires, get/post data is escaped by default.

> access to the whole CPAN
this has been dealt with some lines ago

Repeating: it's not about being the Schwarzenegger of languages, it's about getting things done. Most scripters seem to have a tendency to blind flaming that doesn't benefit anyone.

Personally I prefer Perl, it's more elegant in a queer way and it's creators and gurus tend to be witty and humorous - it' often fun to deal with their material, this can't be said of most of the users...

Marek Moehling
Sunday, April 25, 2004

Joel Spolsky can bash whatever the f*ck he wants...because he's Joel Spolsky.

Tuesday, April 27, 2004

*  Recent Topics

*  Fog Creek Home