Author says, "the developers of these new tools deserve some serious recognition for the work they are doing" and then totally fails to mention them!
So now we've again been suckered into the 'PHP good' vs 'PHP bad' non-debate.
-Take away PHP and the internet would break. The vast majority of websites are either written in PHP or have a PHP back end.
-The LAMP/LNMP stack is by far one of the most deployed web server configuration.
-PHP is extremely well documented and it's been around so long that it's easy to find solutions on the web.
PHP is the Model T of web languages: people love to laugh at it because it's old and ugly but it nearly single-handedly revolutionized the landscape. I for one applaud any efforts to revive and improve this language.
I can agree that PHP is documented. That it is well documented however is something I'm very much willing to argue against.
PHP has string-operations documented to be "binary-safe" without ever saying what that is supposed to mean, if it's good (it's not), if it's bad (yes, yes, yes it is) and why you should have an opinion on that at all. Nothing about that. "Binary-safe" is not defined anywhere. It just "notes" that all these operations which should operate on text is "binary-safe". And "safe" makes it sound like a good feature, right?
Documentation like this is probably written by people who have no idea what a character encoding is and thinks that being able to strpos() on raw byte-data is a "cool feature", without understanding that text and it's encoded representation are two very different things.
Basically, the documentation is written by people lacking any deep understanding of the subject they are covering, and they pass their confusion on to whoever may be unfortunate enough to stumble upon it.
So... Is bad documentation better than no documentation? I don't know. Maybe? Still: PHP documentation, good or bad, represents the blind leading the blind.
If you want "extremely well documented", head over to MSDN and check the .net docs. It's systematic, it's consistent and it's thorough. It's written by people who understand the difference between Unicode, UTF8, text and bytes. Or whatever else the subject you are reading about covers.
But people peddling in PHP wouldn't know that, because they wouldn't want to go too far outside their comfort-zones, and hey, they definitely wouldn't want to look at anything done by Microsoft.
The very small percentage of php developers who have ever had to deal with binary data probably had their hands burnt enough to figure out what binary safe was. While I'm not arguing that documentation should have vague references, its not that hard of a tradeoff between just mentioning something that should be explained over pages, as opposed to not having it there at all.
Plus, the comments section makes it very useful to have examples and clarifications. Its not as bad as you make it out to be.
I'm used to dealing with perl 5, which has quirks of it's own, but at least their documented (a little too much sometimes). I learn a lot about many things by reading the perl docs.
Here's "Gory details of parsing quoted constructs" (no that I have read it..)
http://perldoc.perl.org/perlop.html#Gory-details-of-parsing-...
But, sticking with it, it's comes down to there being a huge market in parts and service. Something like all taxis in the US still being Ford Ts, with very little forecast of change.
I agree with the first part. But when the rest of the world has moved on to '56 Chevy Bel-Airs, does anyone really want a "revived and improved" Model T?
PHP as a language isn't great, since it has been around the block in a volatile environment (the web) and shows lack of foresight in language design.
However, PHP is experiencing a renascence with modular components, frameworks and tools utilizing established design patterns, and an overall boost in contribution and collaboration in the open-source community, in large part thanks to Github.
PHP is not dead, and vibrant communities around Symfony and Doctrine are pushing it forward considerably.
In my opinion, large applications can and have been built primarily on PHP while leveraging other languages and tools for their strengths.
But the benefits of starting a new project in PHP are few: All of the original benefits (mainly low barrier to entry) are eradicated, and that leaves PHP to compete directly, as a full development environment, not as the only easy way to get code on the web, with a myriad of other languages that can, almost objectively, be thought of as better. Again, a bit like Java.
From my experience in the 90s, most of the early adopters of PHP were more smitten with included PHP code in otherwise static HTML files. It was SSI++
There's much to be said for backwards compatibility, and PHP does that really well; but there's also much to be said for a new generation built with the mistakes of the past in mind.
I actually really like PHP despite its flaws. It gives the programmer easy, deep control over HTTP output, it's easy to install on new servers, it's easy to deploy (no compilation, just rsync everything!), it has decent built-in templating (if you can learn the quirks), it's OSS, it has rich libraries, rich documentation, and a rich community. But it's also deeply flawed and it deserves a break from the past.
My ideal sort of web language would be something with C# syntax and libraries but with PHP-style OSS-ness, simplicity in output and compilation, and expressiveness in HTML. That would be nice!
I've yet to see a better one in any language - it has things like Unix-like pipe chaining of filters, user defined functions, and intelligent caching built in.
I reduced the number of lines in one codebase I worked on by 70% through use of Smarty.
Bolting a template engine on top of that makes no sense whatsoever.
Though I don't like having to use the Smarty psuedo-language, I do like the organization of code that it provides.
Maybe that seems perverse, but you have stuff like Node.js in existence that oddly enough solves some problems quite nicely, so maybe it works for PHP guys. I'll never see the appeal compared to other languages though.
edit: That being said, the final result looks kind of horrible to me.
Now we've actually moved everything to the client side using Ember and Handlebars templates. JS doesn't have any built-in templating like PHP (which is basically just a template engine), so Handlebars makes it really useful to write up HTML code blocks that get variable insertion and data-binding on the client side.
> include variable insertion (<?=$var?>)
But what's really amazing is when you combine Hiccup with Enlive[3]. Enlive can give you a headache when you first start working with it, but then there's an almost magical "aha!" moment, and not long after that you'll never want to look back. By "combine" I mean using Hiccup and metadata from your db (or whatever) to generate empty, logic-less views and then using Enlive to bind in your data.
Combine those steps with your own macros and HOFs, look for some choice places to memoize function calls, and now you're cooking with gas.
[1] https://github.com/weavejester/hiccup
And seriously, check Symfony 2 out.
One of the worst flaws of php is that it makes it easy to mix up code and the view, which is ok if you're writing a single page, and terribly dangerous if you're writing anything more complex.
I've experienced this myself writing templates for things like phpbb (thankfully not something I do frequently) - every time the forum updates, the templates have to be patched again - they even have a weird patching system to try to work around the issue with code in views.
A better template language would actually limit the amount you can do in your view files to the bare minimum - something like mustache comes to mind. If you want to keep the views maintainable, easy to swap out, and easy to add alternatives to like json or XML as well as HTML, the aim should be to reduce the lines in your codebase by putting the filters, caching and logic around your views in helpers rather than inside your views.
class FakeFooBar(FooBar):
def my_method(self, *args):
self.last_my_method_args = args
return self.result
class TestFooBar(TestCase):
def test_my_method(self):
foobar = FakeFooBar()
foobar.result = 42
self.assertEquals(
foobar.use_my_method('hello world'), 'forty two')
self.assertEquals(
foobar.last_my_method_args, ['hello world'])
Actually, it's not even that verbose compared to mox :)
Defining mocks manually is my preferred method. I find things like Phake and Mockery to be a little too opaque and hard to debug when you get subtle problems. I think they also add to the learning curve when getting new devs up to speed.
IMO one reason a lot of PHP devs avoid the manual method of defining mocks is just laziness.
I kind of view the native PHP development server as getting featural parity with Rails and Django. But it seems like that's a major gripe for developers who are averse to working with Apache or Nginx for being too complex.
I'm very excited for traits as a feature. This is when we get into real language features other, more prestigious or "hot" web development languages actually have that PHP lacks. These result in true architectural deficiencies requiring annoying hacks to accommodate.
In the end, PHP itself benefits most from expanding its capacities as a logical formalism. Tools are great, but they're also a lot less easier to get right.
I wrote a post on this: http://news.ycombinator.com/item?id=4606961