While the technology is pretty immature at the moment, due to its under-use no doubt, saying that PHP is never the tool for a desktop application is pretty inane. While the primary developmental lifecycle is geared towards web development (who's arguing that?), there's nothing really pervasive preventing people from using it for desktop apps. Given the recent focus towards closing memory leaks internally and the control of the (new, iirc) garbage collector, I wouldn't say it's a bad idea, resource speaking, to write in PHP (certainly no worse than Java). There's sound support, GTK support, CUPS support, Windows COM / printing support, so the support for the APIs is certainly there (and where it's not, there's ways around it, like with the java extension). Just because you have a hammer that's only been used for nailing particle board doesn't mean it's not suited for hammering into plywood! The only issue I see with PHP is the relative difficulty of making "stand-alone" applications that are bundled with a statically compiled PHP executable, but that shouldn't be too hard to overcome, with a little bit of time and creativity. On Tue, Jun 9, 2009 at 9:28 PM, Michael <michael@xxxxxxxxxxxxxxx> wrote: > Robert Cummings wrote: > >> >> >> Michael wrote: >> >>> Paul M Foster wrote: >>> >>>> On Mon, Jun 08, 2009 at 09:30:18AM -0700, Kyle Terry wrote: >>>> >>>> <snip> >>>> >>>> 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? >>>> >>>> Paul >>>> >>>> >>> >>> 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... >>> >> >> Citation? >> > see the history of php development and use > > >> 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. > > >> 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*. >>> >> >> Why? >> > 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 > >> >> 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. >>> >> >> 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. > >> >> Cheers, >> Rob. >> > > 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. > > 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. > > Use the tools designed for the job. > > Michael > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
