Michael wrote:
Robert Cummings wrote:

Michael wrote:
Paul M Foster wrote:
On Mon, Jun 08, 2009 at 09:30:18AM -0700, Kyle Terry wrote:


I don't mean to be the thread spirit killer, but I think another language
would be better for this. Such as Python.

PHP desktop apps might be fun to hack around with, but I wouldn't use it for
a production application.

I've coded a bit in Python, and parts of it really annoy me. I much
prefer PHP, as it's more C-ish.

Why wouldn't you use PHP for production applications?


Why wouldnt you? Besides the design of PHP generally being completely against it? PHP is not designed to be run continuously in infinite-loop (while true) scenarios...

see the history of php development and use

Please explain the purpose of the php-cli binary?

it's threading support is poor and it's memory

What does threading support have to do with running something in an infinite loop? What if I don't need threads?

handing and library are geared almost exclusively towards web-programming.

I dunno, I've written amultitude of shell/cron scripts in PHP that leverage the codebase already written for the web application.
i wasnt arguing against cron-scripts, these are 'run-once' sort of things which php handles well. they dont run for minutes let alone hours.

I have daemons in PHP that have been running for months without stop. They are using the infinite-loop mechanism you purport to be not designed for continuous long-term use. I have an mplayer wrapper script that has been running for the past 3 months non-stop... it's purpose is to shuffle my kids shows, reload a play list when it changes, allow queueing of shows, handle random selection of shows based on tags and weighting, remember what episode in a series was last played and where the timestamp currently rests... all this without being shut down.

If you want to compile it, or use it in a .NET/Java context... fine (see phc, etc.). The language itself can handle it, but the standard implementation *shouldnt*.

for the reasons detailed in this post. using web-oriented php as a desktop programming language is a magnitude of dumb perhaps only eclipsed by the smarty programming language

Narrow mindedness won't earn you any brownie points from me.

In anycase other languages have much better support of desktop and network programming, entire libraries and communities have been developed around it. Preferably use Python/Java/etc. though C has its place.

There's always other languages... there's always another language better at doing something... so what? There was Perl before PHP, Perl was undoubtedly better than PHP for web applications at one point... yet I would argue that has changed... why? Because the naysayers were ignored.

As I've said before, ones place in the sun can't be identified if one never tries sitting in the sun. It's hard to grasp the proverbial brass ring if you never extend your reach.
There are good reasons why php isnt "in the sun" (ie. used for desktop programming), as i've listed. If you'd care to learn a few other languages the reasons would be immediately obvious, python can be learnt in a few days - try it.


The standard PHP execution model is geared almost exclusively towards web-used (though crons etc. are reasonable)... that is, to sit in/with a server and handle requests... to operate over, at maximum, "insane" lifespans of 30 seconds.

Please point me to this "standard"-- I would like to have a gander at it.

There are languages designed to be used for desktop programming, and for various tasks in general. The smart thing would be to use them. PHP may be a hammer, but every problem is not a nail.

Languages were designed to be programmed, what they are programmed to do is entirely up to the programmer.

Use the tools designed for the job.

Then how would we find new uses for the tools? Just because there's only one known use for a tool, doesn't exclude it for consideration for new uses. There's always serendipity too.

Application and Templating Framework for PHP

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to