PHP is not a good tool for quickly getting a minimum viable product. Despite its flaws it is a good weapon for fighting 'the last war' - that is to say, it makes it quick and easy to make what are essentially the CGI pages of 1996 - but if you're doing anything more complex than that (for instance interacting in any way with a database), and I would suggest that even relatively non-technical people looking to use computing technology for a business are in Anno 2012, there are many better systems available which do not expose the novice or intermediate programmer to nearly so many pitfalls.
An important thing to remember about PHP is that it really isn't stuck in 1996: When we say PHP you need to think WordPress, or Drupal, or CakePHP or Symfony, since that's what one actually uses nowadays. Novices are steered away from code that pipes SQL injections directly to the database, and toward one of these frameworks, which does the heavy lifting for you so that you don't need to reinvent the wheel.
For years I consoled myself by calling myself a "Drupal developer". I'm not a PHP developer; if I weren't using Drupal I wouldn't touch the language with a ten-foot pole.
But I agree that basic PHP is optimized for the style of web development that dates back to 1996: Server-side rendering of HTML templates. (More powerful PHP - the underpinnings of the PHP frameworks, the stuff one gets in the latest versions like objects and namespaces and closures - basically turns the language into the equivalent of every other scripting language, though obviously much more inconsistent; there's no great reason to choose any of that over Python or Ruby except that it degrades gracefully to PHP, which may actually be very important, but only so long as what you're building looks superficially like a server-side-rendered HTML template from 1996.)
One reason why I'm spilling 10,000 words on PHP is that I've been working with it for five years now, but I'm having trouble getting excited by its future. It has a long future, because 1996-style web sites are not going anywhere: WordPress.com has a zillion users and Drupal is taking over the enterprise and, well, Facebook. But one eventually gets tired of living in 1996. And PHP is useless for client-side-rendered "HTML 5" views, or mobile app client development, and its advantages as a templating language become moot if your server-side code is just an API coughing out JSON objects RESTfully. No newb can figure out that stuff today - even wizards can't agree on the proper semantics of REST, for example - and if ever we do develop a framework for designing RESTful APIs that's as easy for novice programmers to pick up as PHP is for 1996-style templating, I'm betting that framework won't be built in PHP.
I actually find php well suited to client-side rendering. Implementing a web service in php is pretty easy. The only thing i use php for is building json-rpc and soap services using zend framework's service classes, wrapping around zend framework's database classes. The app itself is all javascript.
True, and if this is all your server-side needs to be, while there's not much reason to prefer PHP for this above anything else, there's also no reason not to just keep on cruising with PHP.
My experience running PHP cloud services suggests that, operationally, PHP is a dream. It's the least problematic layer of the LAMP stack, at least once you've learned what the words "APC cache" mean.
What would you recommend as a starting language to build a MVP? The extent of my experience is html/css, manipulating wordpress php files, and a weekend hacking together a couple of learning projects (a PHP blogging platform and a "rank this list of items by number of upvotes/this number" website).
Given my past experience I was planning to use PHP as it is the only language I have any experience with and while the functionality I'm shooting for is totally different, I don't envision it being any more difficult to code than the blogging platform. I will be interacting with a database.
Are the other options as easy to pick up as PHP? Is it as easy to google for help?
I'd say that using Ruby with Sinatra is really easy to pick up - the documentation of Ruby itself is great and Sinatra is also documented really well, not that i think it's particularly complicated. Use an easy template-engine or stick with the default (erb) and (at least for the beginning) the sqlite-gem.
Of course, that was my impression given my prior knowledge, which of course influenced my start with that environment. But i found it to be great almost instantly.
I'm not surprised. A big advantage of PHP's database layer is that it doesn't reinvent the SQL wheel.
[set Greenspun Cynicism Level to MEDIUM HOT]
Other platforms wrap up SQL to the extent that you are encouraged to pretend it does not exist. This is an irreplaceable killer feature if you are trying to encourage new programmers to design things that will eventually prove difficult for them to optimize, or are trying to drum up membership in the NoSQL-silver-bullet-of-the-month club, but in the end what was good for 1996 is still pretty good for 2012: Pull the data from the database using classic SQL from the 1970s, loop through the result set, paste each row into the template, and ship it out to Apache.
PHP does this transparently, which makes it relatively easy to figure out what is going on. Of course, what is going on may be "the novice PHP programmer is staring directly at the SQL but still cannot optimize it", but hey, at least now you can see the problem.
There are also modern libraries for a plethora of other RDBMS and NoSQL systems (I think PHP is even going to support mongodb natively soon i.e. no third party client library required).
I've done quite a bit of PHP development, a lot of more advanced stuff (Earlier in this topic I linked to a PHP Daemon library of mine on Github).
But PHP has either missing or NOTORIOUSLY inferior Memcached/Redis/Mongo/Cassandra/HBase/Riak/etc clients. They get the job done, but they underperform, say, Python or Java versions in benchmarks and introduce far more bugs and quirks than I've experienced in other languages.
This has actually been a positive thing, because when you're using these data stores/queues/etc at scale and you need bulletproof client libraries, you naturally are led to a SOA. You end up with Python/Erlang/Clojure/Java services that interact with the datastore, that you consume from PHP using Thrift et al.
But being so bad that it pushes you into building a better architecture is kinda a preverse benefit
I haven't used a PHP nosql client library at serious scale so I will bow to your better experience (although in the case of Redis clients, some links would be nice as I wasn't aware that the two major PHP clients had any performance/reliability problems - I'm very surprised that https://github.com/nicolasff/phpredis under performs given it's a C extension).
Having said all of that, if you are building a site that uses NoSQL and needs to scale to millions of simultaneous hits you'd be insane not to develop it with SOA in mind. Using just PHP (or any other single language) wouldn't make sense.
I may have been making that up re: redis, honestly. It's guilty by association in my mind, but I've used redis in PHP a lot without any first hand problems.
But Memcached, certainly (and even doubly so for the `Memcache` extension that ill-informed developers install instead of the better `Memcached`), and the others listed, either are slower/etc or just don't exist.
Fair enough, I'm sure you're right with some of the other lesser used libraries e.g. Riak. It's probably fair to say it takes PHP longer in general to get a good client library than say Python. Not sure about Ruby.
Please, the PHP industry is stuck on Wordpress and CodeIgniter which are amateur software.
Yes, you can enjoy these wonderful modern tools for PHP at home meanwhile you suffer with old-tier libraries at work because everyone refuses to move forward.
