Hacker News Reader

Comment by encoderer | Hacker News Reader

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.

View on HN

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

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 don't think that's what the parent was saying at all. They were just providing an on-topic anecdote.

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

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.

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

Reply on news.ycombinator.com