14 Apr, 2010, David Haley wrote in the 41st comment:
Votes: 0
Scandum's somewhat oddball comment aside, there is really nothing "wrong" with PHP from a functional perspective or in terms of it not being sufficiently expressive. There are many reasons why one might not choose it, as people have discussed, but hey, whatever, if you're just playing around then have fun. Now, if you think you are going to actually use your code seriously later on, you might want to consider something else. If the question is, "should I use PHP for my codebase?" the answer is a question: "Well, what are you planning on doing with your codebase?"
14 Apr, 2010, quixadhal wrote in the 42nd comment:
Votes: 0
The question I would have is more regarding the long-term memory use of a php process. While you *CAN* write anything you like in php, I've never heard of it being used for processes that run for days or weeks at a time. Web pages get created and destroyed pretty quickly, as do web server child processes, so any memory leaks in the interpreter would likely go unnoticed. Has anyone tried running a php console process and having it stick around for a few weeks to see if it's stable and doesn't leak like an old MS-DOS TSR?
The question I would have is more regarding the long-term memory use of a php process. While you *CAN* write anything you like in php, I've never heard of it being used for processes that run for days or weeks at a time. Web pages get created and destroyed pretty quickly, as do web server child processes, so any memory leaks in the interpreter would likely go unnoticed. Has anyone tried running a php console process and having it stick around for a few weeks to see if it's stable and doesn't leak like an old MS-DOS TSR?
I guess you'd have to ask the creator of Phudbase?
Apparently an additional reason for "why not" is because the PHP License is incompatible with the GPL. This is a little unusual. It may not be fine for many people.
Although this likely wouldn't effect too many people.
15 Apr, 2010, quixadhal wrote in the 45th comment:
Votes: 0
I don't consider the Gee Pee elL to be a good license for… well… anything really. To me, it's a bit like flag waving. It looks nice, it feels patriotic that you're supporting "freedom", but in the end it causes problems because it just doesn't play nice with anything NOT GPL'd.
Here's another reason PHP might be a bit of a challenge:
Fatal error: Maximum execution time of 300 seconds exceeded in /home/foo/public_html/bar/plog-includes/lib/exifer1_7/exif.php on line 722
PHP is kindof in bed with web server technology. The user hosting the game might also be using php for their web server, and having to keep totally separate PHP installations so the server's php.ini file doesn't have restrictions that only make sense in the context of a web server, might be difficult.
I don't consider the Gee Pee elL to be a good license for… well… anything really. To me, it's a bit like flag waving. It looks nice, it feels patriotic that you're supporting "freedom", but in the end it causes problems because it just doesn't play nice with anything NOT GPL'd.
The point is that the PHP license is incompatible with GPL'd code. I.e. they can't be combined. Regardless of how you feel about GPL, this puts a fly in the ointment of anyone with qualms about violating the GPL with code they perhaps would like to combine with the PHP license. If someone just plans on never using GPL'd code then I guess it wouldn't matter.
15 Apr, 2010, Asylumius wrote in the 47th comment:
I don't consider the Gee Pee elL to be a good license for… well… anything really. To me, it's a bit like flag waving. It looks nice, it feels patriotic that you're supporting "freedom", but in the end it causes problems because it just doesn't play nice with anything NOT GPL'd.
Here's another reason PHP might be a bit of a challenge:
Fatal error: Maximum execution time of 300 seconds exceeded in /home/foo/public_html/bar/plog-includes/lib/exifer1_7/exif.php on line 722
PHP is kindof in bed with web server technology. The user hosting the game might also be using php for their web server, and having to keep totally separate PHP installations so the server's php.ini file doesn't have restrictions that only make sense in the context of a web server, might be difficult.
While that's true, it probably does make it more bother than it's worth, you can change those configuration settings with a function call, as well as load most of them from a file. We have PHP scripts at work that run for hours before finishing.
Well for most of the reasons listed here, I have decided to migrate to Stackless. It's a far far better language for this application. I didn't want to go to through it because Stackless IO is a… terrible terrible word… but I was able to code it up and now I can program all the fun parts.
Though I do miss PHP strings.
16 Apr, 2010, David Haley wrote in the 49th comment:
Votes: 0
What do PHP strings do for you that Python strings don't? (I haven't used PHP for non-trivial applications in a while so I don't remember if they have some cool feature) (And I'm assuming that you mean Stackless Python, so basically you're using Python)
What do PHP strings do for you that Python strings don't? (I haven't used PHP for non-trivial applications in a while so I don't remember if they have some cool feature) (And I'm assuming that you mean Stackless Python, so basically you're using Python)
I doubt he's talking about ability, as both do pretty much the same things. I'm guessing it has more to do with the library familiarity, or quirks of specific functions.
I did, in fact, speak to soon. I thought immutability would be a problem, but it turns out, I have been able to rewrite nearly 90% of my codebase in about 30% of the lines using Python, and much more beautifully. And the string handling was one of the places where I turned 15-25 line functions into 2 liners… I was impressed.