I was writing code not long ago to determine if a given day is a holiday. I didn't want to use a database of dates that would have to be updated in the future. I was breezing along with the variable-date holidays like Thanksgiving, and then I came to Easter.

Turns out, it's slightly complex. It has to do with moon cycles.

After wigging out a little about this task, an afterthought that should've been easy, I googled for the specific formula so I could begin to express it in code. (I had already done a 20, 30 minute search for an existing PHP Class to handle all dates and was unsuccessful.)

What I found next nearly blew my mind. http://php.net/manual/en/function.easter-date.php

This at once delighted and disgusted me. A perfect example of the utility AND horror of PHP's large standard library.

so because PHP, a language designed to make building web applications easier, disgusts you because it has a built-in function that facilitates a task which is often needed in web applications?

And you think this is inferior to other languages where you would have to write that yourself or pick one of dozens of unofficial implementations with bugs unknown to you?

One could blame PHP for not having namespaces, but certainly not for providing official implementations for often-used pieces of functionality (though in case of easter_date? How many functions with different functionality do you come up with that you would like to give the same name?)

(edit: I'm not trying to troll here. OP has said he was "disgusted" by the presence of easter_date and from that I was inferring that he would prefer PHP not to have easter_date, thus my assertion of PHP being "inferior" to other languages that lack easter_date. By no means did I want to sound rude just a bit cynical maybe. I apologize for that.)

I don't think that's what the parent was saying at all. They were just providing an on-topic anecdote.

Down, boy.

Inferior? I never said it was inferior. Seems you're arguing against somebody, but not me.

well. I inferred "inferior" from the fact that you were "disgusted" (your word) by the presence of an easter_date function. I assumed that you would not be disgusted about other languages that don't provide the function.

If one is disgusted by one thing and not by another, it's IMHO save to assume that the non-disgusting one is superior to the disgusting one.

If I have misunderstood you, I apologize.

Here's the disgusting part.

I'm far more fluent in PHP than your average PHP developer. Where I work we face real problems of scale and use PHP effectively.

And even with all this, after years of developing in PHP (among other languages), I happen to just stumble across random functions.

In a structured library (like, say, .Net) I'd know to look in a specific place for a certain type of functionality, and if it's supported it's going to be there.

There is absolutely no benefit to a large corpus of functions being included in the language core like that. All of your arguments--about officially sanctioned solutions with known quality control--would be satisfied just as well by an official, structured library shipped alongside, but not inside, the language core.

I'd be disgusted too, if Ruby (my current language of choice) contained a bunch of completely random methods/functions in the core.

I think including things like that in the core is particularly poor practice.

"unofficial implementations with bugs unknown to you"

I think it's not much secure to rely on php core for security. If you want security you add tests, even php core developers are humans.

I wasn't specifically talking about security bugs, but bug is bug, so this applies anyways: Where do you think it's more likely a bug is found and fixed: In one of dozens of unofficial implementations or in the one official implementation?

"bloat" is not always bad (well. bloat is. but a big library isn't necessarily what I'd call bloated).

If you want to talk about bad parts in PHP, I could name a ton, but a huge base library isn't one of them.

Bad parts are:

- too much focus in backwards compatibility. A py3k like cut between php 4 and 5 would have done wonders and would not have made the adoption much slower (which was still very slow despite the more or less given backwards compatibility).

- wordy, inflexible syntax

- trying too hard to be like java while not being like java.

- inconsistencies in the base library (parameter order)

- very, very WTFy type conversion (IMHO the worst part of PHP)

But having a big base library is not what I would ever be disgusted with.

That is what I love about PHP... Always making my life easier.

I would recommend direly against using the gettext extension and _() because these imply setlocale and setlocale, when called from a PHP script has some side effects: For one, it changes the locale per process. Now I know that PHP isn't totally thread save (actually it is - the extensions - like gettext grin are the problem), but imagine apache in a threaded MPM and setlocale being called from different scripts.

Then, setlocale() alters how certain library functions work. *printf() for example uses the number formatting settings of the current locale. If the libraries you are using are not aware of locale settings, they might fail in interesting ways once you set the locale to something that uses, say, a comma as the decimal separator.

And last but not least, if you change your language file, you will have to restart the web server which generally isn't needed with PHP otherwise.

Wordpress has actually reimplemented portions of gettext so it works with the .mo files, but it doesn't alter the locale of the web server process.

And for regional formatting of numbers and dates, we got the intl extension with 5.3 which does just that, also not interfering with the web server process, other libraries and PHP itself.

To be honest, the only time I've seen glob() used was with an outsourced code bomb that was written to delete all the code if a get variable (think it was delete_everything) was passed, presumably in case we didn't pay up.

We paid, and surprisingly didn't choose to ask for any more work from that particular coder ;)

I like the example of sys_getloadavg(), but am unsure if I'd ever use it...

Was the contractor from Kerbleckistanian? ;) http://thedailywtf.com/Articles/Maybe-I-Needing-Later.aspx

Dear god, is this a common occurrence?

Agreed on sys_getloadavg(), by the time you get to PHP much of the overhead of serving the connection has already been incurred.

It's also a poor way to decide whether to stop serving pages. Depending on circumstances, it's possible for request handling to be still reasonable or completely wedged for same load numbers. The number is also dependent on the configuration of the machine so moving to a box with, say, more cores might make whatever magic constant threshold you put in your code even wronger.

I'm embarrassed to admit I thought _() was specific to Wordpress. Great to know its not.

metaphone() is a great tip too. I've only used soundex() in MySQL, will be interesting to see how they compare.

don't use the built-in _(). See my comment below.

I've use quite a few of those but:

sys_getloadavg()

Is a new one for me. And actually really awesome because I can integrate it into a current project!!

You probably shouldn't - see my comment below.

nah, I saw that - it's not my intended use :) (I want it for rudimentary load monitoring)

You mean at the top?

Heh, yeah they threads got moved around. The point was, the technique suggested in the original article is a bad idea.

Make sense... I was just looking at the bottom and couldn't find your answer :)

Wish I knew about debug_print_backtrace() earlier. It could've saved me so much time debugging other peoples scripts!

Never knew levenshtein was in there, just wrote my own function for it when I needed it.

Me either. Very nifty for searches in case the user typo'd something.

I also like date_sunset and date_sunrise.

$binary_cksum = md5( $data, true );

i guess the author should try step into 2004 and php5...