Hacker News new | ask | show | jobs
by olleicua 4915 days ago
How is that a fairly strong statement? Here's a much stronger one: PHP is terrible at being a general purpose language. General purpose language doesn't mean you can do things that aren't web dev in it. General purpose means that it is designed to be useful in any application. You know like Ruby, Python, or Perl. General purpose doesn't mean that those things are possible (because I agree that they are possible in PHP); it means that it is a good tool for any job. PHP isn't just an inferior tool for non web dev projects though, it's also barely better if at all for web dev. LEARN RUBY!
3 comments

I use PHP often for non-web things all the time… I write shell utilities all the time in PHP because it just makes sense: a simple interpreted language, with full access to my app's configuration, database access, dead simple file IO…

The one-liner's are quite nice too… Just today at work I needed to come up with a base64 encoded json string from a data set in an ini file to pass into my Java app via stdin. It was something like:

    php -r 'echo base64_encode(json_encode(parse_ini_file("app.ini")));' | java -classpath Foo.jar com.example.foo.App 
So… yeah. I don't think it's fair to say that "PHP is terrible at being a general purpose language". You just haven't done enough of it yet to appreciate it.
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.

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

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

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

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

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.
exactly right. PHP is like the justin bieber of programming languages.