[Firehed]

Why is it a crappy tool for non web stuff? It has an absurdly large set of included tools and having all of that in one place is really handy.

More concretely- what's an easy non-web task that Ruby (as you suggest learning) is great at that PHP can't handle just as easily? Not trolling here, I'm genuinely curious.

[eropple]

I find the guy to whom you're replying to be obnoxious, but he's not wrong about it being poor for CLI stuff. Loads of stuff non-obviously behaves differently in a web context versus a CLI context (and while it's documented, you still have to know about it). It doesn't have good stream processing facilities. It, as mentioned, requires a php.ini and requires you to think about that when you're writing scripts in it.

It can be done. It is not something I would recommend under almost any circumstances. (But, then, I wouldn't recommend Ruby for any-any circumstances, so...)

[Firehed]

The only real differences from running PHP/CLI that come to mind are:

* PHP_SAPI is defined to 'cli' (as compared to 'fastcgi' or similar)

* $_GET/$_POST are empty, and $_SERVER is missing the HTTP_XXX variables (duh)

* By default, there's no max execution time

I dunno, it works perfectly fine for me. It's certainly easier to read and write than shell, and I genuinely can't think of a time that an ini directive had any effect on what I was doing - unless you count the presence or lack thereof of an extension, but everyone knows that PHP's extension handling is pretty crappy.

I guess it all depends on what you're trying to do. I agree that stream handling is a little rough, although that has little bearing on what I tend to do (YMMV).

At the end of a day, it's a tool, and I have tasks that need to be done. That tool either is or isn't capable of accomplishing those tasks, and based on my own abilities it may or may not be faster than using other tools (contrary to popular opinion, I find Ruby extremely painful to work with, and avoid it at all costs; if it works for other people, good for them!)

This could be a case of "when all you have is a hammer...", but maybe I just happen to have two nails: http://www.codinghorror.com/.a/6a0120a85dcdae970b017742d249d... ;)

/edit: typo

[saraid216]

> More concretely- what's an easy non-web task that Ruby (as you suggest learning) is great at that PHP can't handle just as easily? Not trolling here, I'm genuinely curious.

Is there a decent analog for Nokogiri? I stopped paying attention to PHP 6 years ago so I don't know, but a friend of mine needed to do some webscraping today and learned Ruby and then built his script in 5 minutes.

I checked the IRC timestamps between his "it's done installing" and his "hey, look what it outputted". It was seriously 5 minutes. He then went on to do something a touch more complicated (scraping multiple pages and a trivial analysis/report of the results) and that couldn't have been more than another 30 minutes.

(ETA: I don't know if you'd consider webscraping to be non-web. I guess we could swap it out for a bunch of XML files since that's basically the same task.)

[dave1010uk]

PHP has cone a long way in 6 years. Here's a really good PHP web scraper that looks comparable to Nokogiri: https://github.com/fabpot/Goutte

[berkes]

Several reasons:

* The bindings for making anything GUI-ish lack. Horribly. I doubt there is one application like an editor written in PHP; that is actually used. * Its long-threads are ... lacking; You cannot write anything deamon-ish in PHP. * Memory management, as Ramus puts it, is not a concern "I just restart Apache". That makes it unusable for anything bigger then a small CLI-tool. * The Cli-libraries are decent, but far from things like Ruby's Thor.

You can write CLI-tools just fine, but "general purpose" is much more then "Managing Web-Content And Some CLI tools".

[KorvinSzanto]

Check out Phabricator, it has daemons that are very well managed and cli tools that are fully featured. Arguing that it's unusable for something large is just wrong. The way you manage memory in PHP is the same you way you manage it in any other language; you write /good/ code.