Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What makes me sad is that people will defend this horrible language to the death, regardless of how many problems there are with it. I don't get it; we know how bad PHP is, so why do people fight so hard?

Oh, and to demonstrate: "PHP has no native Unicode type, no native Unicode handling, and cannot treat Unicode strings as strings." This true statement, composed of three observations about deficiencies in the language, gets me flamed every time I mention it. Why?



> "PHP has no native Unicode type, no native Unicode handling, and cannot treat Unicode strings as strings." ... gets me flamed every time I mention it. Why?

perhaps because statement of of fact (``PHP has pluggable Unicode support'') beats wrong statement of oppinion (``PHP is bad because has no support for it''). It's borderline trolling to insist PHP does not, when people have been using it successfully in production for years now.

http://pl2.php.net/manual/en/book.mbstring.php in case your google is broken.


I knew you were going to point out mbstring. I am talking about an actual Unicode string type. I am talking about using regular string functions on Unicode strings without caring whether or not they contain characters not in ASCII or Latin-1. I expect you'll next talk about how the function overloading "feature" is the correct thing to do, and you'll conveniently ignore how the documentation recommends against it and warns of undefined behavior.

Here's a fun question: How do you strtok(), implode(), or explode() mbstrings?


For background:

- I've seen the Python (2.x) way (separate `unicode' and `str' type and no way to set own conversion defaults per whole process -_-') and found it unwieldy. Lotsa boilerplate to keep around I/O.

- I've seen the GNU way (messy pile depending on LC_* environment vars and files in /usr/, with hierarchy of precedence) and disliked it.

- I've seen the Plan 9 way (char * / char[] for UTF-8 and Rune * / Rune[] for UTF-32) and it fits me. I see and use (non-PHP) software built on that, works reliably. I'm happy :)

implode() and explode() work with UTF-8. I hope you know the techicalities of why -- UTF-8's been designed that way and the functions take complete string as the glue/separator. No idea about about UTF-7, -16 or -32 (nor the April Fool's -18 and -36); guess some of those would break terribly. I don't care at this moment. My sites run polish, english, russian and in near future czech language based on UTF-8.

Your point is just strtok(). You are right. I lost. PHP lost. Have a nice day -- and kudos for bringing up that cool function :-)

EDIT: now that I think about it, it seems I've abused explode() for that job -- the output array, with empty strings removed, is equivalent of calling strtok() repeatedly till it returns FALSE. Seems a bit brute-force-ish.

AS for that warning against, and undefined behavior, I'll assume you're refering to the following passage:

  It is not recommended to use the function overloading option in the per-directory context, because it's not confirmed yet to be stable enough in a production environment and may lead to undefined behaviour.
Reading comprehension: don't re-configure it per directory (in this case, of your project, not whole server). Having that minded, you get reliable site.


Are you serious? You can't figure out why this is?

Seems logical to me. These defenders are presumably professional PHP developers. They're presumably supporting their families by coding PHP. The more widely-spread the language is, the more it's used for new projects, the more lucrative and interesting their work will be.

And here you are, making a fuss, and many of these people may know ONLY PHP. And you're trying to argue that their most valuable skill should be put on the trash heap.

That's why THEY fight so hard: They're feeding themselves with the language.

Now, why do YOU fight so hard against them?


I fight against technologies I perceive as bad choices in an attempt to convince younger developers with less of an experience base that they should pick up something else that will give them the same or better capabilities for much less pain. My contribution to the community, as it were, as I have in turn benefited in my career from such signposting.

You can carve out a decent subset of PHP, but there's this painful and dangerous beginning and middle part where you're still learning this subset and in the meantime you're writing grossly insecure code. Perl has much the same problem. There are no languages I know where you are immediately writing brilliant code, but there's certainly ones you can learn faster, cut down the danger period, and also have many of the worst dangers ameliorated by much better design decisions at the API and language level. (How much of PHP and all similar languages would have been better if only the default interpolation HTML escaped everything and you had to especially ask for direct interpolation, instead of the other way around?)


And you know, none of that offends me. But to act incredulous that professionals who have spent thousands of hours mastering a skillset might actually defend it publicly seems naive.


The implication is that anyone who has spent thousands of hours mastering PHP should be well aware of its bad points, and can only contend that its "good enough for the job".


It's bad, but it's also very, very good.


What aspect of PHP is "very very good"? Genuinely curious to know.


It's bad for language purists, but it's very, very good for getting stuff done fast, easy and good-enough.

See Facebook etc.

A lot of programmers don't believe that a shoddy language (in terms of language design) can be effective, but it is.

I also happen to think that PHP scales really, really well the range that most sites need (say, from 1 to 50 servers). In that range, PHP is almost never the bottleneck.


> "very good for getting stuff done fast, easy and good-enough"

You're saying PHP facilitates a faster development process than most other popular web development platforms? This was probably true, ten years ago.

Today, we have several platforms that facilitates a fast development process without the language weaknesses and inconsistencies that PHP is burdened with.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: