4 ms·

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 o

by pilif 17y ago

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

encoderer 17y ago
Down, boy. Inferior? I never said it was inferior. Seems you're arguing against somebody, but not me.
- pilif 17y ago
  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.
  - encoderer 17y ago
    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.
shaddi 17y ago
I don't think that's what the parent was saying at all. They were just providing an on-topic anecdote.
oscardelben 17y ago
"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.
- pilif 17y ago
  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.
Zarathu 17y ago
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.

by pilif 17y ago

encoderer 17y ago

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

pilif 17y ago
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.
- encoderer 17y ago
  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.

shaddi 17y ago

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

oscardelben 17y ago

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

pilif 17y ago
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.

Zarathu 17y ago

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.