Fourjays, on 28 November 2012 - 11:49, said:
One thing I think is important to consider if you are new to web programming is that PHP errors are very clear - it pretty much tells you what is wrong.
Assuming it bothers to throw an error at all, instead of just trundling on ruining things in the background. Assuming you have the right combination of compile flags, ini_set, display_errors error_checking and whatever other magic is needed you still tend to get a terse one line "missing ; on line x" (the semicolon missing is actually 300 lines prior) and then the last few lines of parser state puked into your ouput stream (or a line in a log that nobody reads). You don't get stack traces or vm state info.The kinds of errors raised are inconsistent too: what's a warning? what counts as fatal? what's just a notice? what errors silently?
You might be able to get things setup nicely on a local environment but deployment tools for PHP are primitive at best. How do you handle dependencies and version miss-match? With phython the standard is virtualenv, with ruby you've got gemfile. With PHP you're rolling your own solution because there isn't a standard method: It's a bag of hurt.
Then there are questions of REPLs, debuggers, and instrumenting. What's the standard php equivalent to tg-admin shell or rails console? Given the way python apps run (typically as a service that gets reverse-proxied to) it's trivial to get your application running as an interactive shell. PHP gives you php -a but that's almost worse than nothing: it creates a bunch of work to make it even remotely useful.
PHPs test libraries are wanting in the best of times and it's not really a community standard practice so libraries or frameworks typically aren't tested at all. With python you find a pretty long history of testing and very solid standard tools like pyunit. A proper test suite makes finding and fixing errors and preventing regressions something you can actually aspire to.