The Lesser Known Contributors Who Are Trying To Make PHP Good Again
danielnill.comArticle title seems to imply there will be some info about the people who programmed these new features... instead there's a rehash of the new features and mention of a library or 2 that we could read about elsewhere.
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.
While I've bashed PHP as much next guy, these are the facts:
-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.
PHP is extremely well documented and it's been around so long that it's easy to find solutions on the web.
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.
@josteink, you don't really understand what good documentation is do you. A large amount of PHP documentation provides context in which you may effectively implement a piece of code by providing "sufficient" examples. A grenade I can almost guarantee you probably comes with documentation, but probably a warning which states when you pull the pin, it will blow up. PHP will not blow up the world, or blow your hands off. The documentation does not have to be "perfect". PHP has changed web development in many positive ways, by increasing what could be done via simplicity using what you might call poor documentation. It has sufficed enough that good developers found it sufficient to build large complex code-bases which they could both build on and make money from. Much of MSDN library is created from internal comment-style documentation automation(JavaDoc,PHPDoc, XML Comments). MSDN will often times lack easily readable code-samples, and provide enough context in which you may actually use a library. Just because you define a prototype with long naming conventions doesn't mean Joe schmuck has a clue. PHP examples are generally not obtuse, or obfuscated to newbies. It's the "I'm going to show you how to hunt fish" and nobody said it had to be pretty. MSDN has gotten better over the years, but there are still many areas in the many libraries hosted on there which don't have "even good enough" documentation to help you to the most basic things.
It doesn't hurt that Microsoft is able to hire the best engineering grads, pay them 100k, and convince them that writing documentation for .NET is a better deal than building some pseduo cool product somewhere else at half the pay.
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.
Agreed.. I like that they often have examples to get you started quickly, but a lot is simply left out. Especially the quirks, and php has a lot of them.
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-...
The documentation point is important - it's been used in so many projects that a lot of weird fringe cases occurring in only the most bizarre setups have been documented. There is a lot of value in that, and it takes time to build a similar body of knowledge for newer platforms.
I don't know enough to deeply critique the various web languages, but if PHP is the Model T, wouldn't it sound odd and backwards facing to talk about reviving and improving it?
The analogy breaks down quickly, because cars are mostly standalone, and can be replaced with little risk, while software is often complex and interconnected, so the benefit of a rewrite in a new language only rarely exceed the massive risks of abandoning your clunky but well-tested codebase.
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.
> 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 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?
Time to beat this dead horse again!
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.
A lot of good people are working on a lot of PHP that isn't going away, and obviously they are going to improve tooling and the language itself. There is a renaissance in terms of making PHP development sane and thus not something good people run away screaming from - a bit like Java.
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.
Very well put. I'm not a huge fan of php, but find this possibility of resurgence (particularly because I use the language for my day job) very interesting.
PHP was never good, but it abstracted away some basic web specifics -- as opposed to CGI/Perl that required you to care about protocol details such as starting output with two newlines -- and hit a sweet spot infrastructurewise -- dead easy to get started with, dead easy to get hosted for next to nothing -- that gave it enough traction to grow very quickly.
I'm not sure that was so much the attraction when PHP first started gaining traction given the existence of CGI.pm
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++
Those are all nice, but as a long-time PHP dev, the only way to make PHP truly better is to do a Python-style hard version bump. Rip off the band-aid, so to speak. Create an entirely new, consistent, object- or namespace-oriented standard library to replace the mess that exists now. The majority could just be wrappers for existing code, which is fine but just inconsistently named and parameterized. Then fix the terrible namespacing implementation, consolidate the jumble of operators (::, ->, ., +, etc.), add some syntactic sugar to objects (getters and setters?), add native Unicode support, and call it all PHP X or something.
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!
Everyone probably knows this, but PHP's Smarty template engine (http://www.smarty.net) is really awesome.
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.
PHP is itself a template engine.
Bolting a template engine on top of that makes no sense whatsoever.
There is one feature of Smarty that is worth having in my opinion, that is the template inheritance. Basically similar to .NET master pages, Rails layouts and I think Django is built the same way. Much cleaner rather than including header/footer files.
Though I don't like having to use the Smarty psuedo-language, I do like the organization of code that it provides.
PHP is not a HTML template engine. You have to run all your content through library functions to encode and prevent it from being interpreted as markup. That's essentially making your own half-baked template engine from scratch in PHP, and it would be just as easy in any sane language.
Seriously? PHP "was" a template engine. But that was before 1998 when no one knew what was a good idea or a bad idea when it came to building web apps.
I hate PHP and don't even want to talk about it but I did skim through the docs for Smarty. The rationale is that PHP sucks as a template engine, so why not create a new one and use PHP for the model-controller/whatever.
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.
Completely unrelated: I'm not easily offended. Right now I'm not offended at all, in case anyone would interpet this post to mean so. I'm all OK. Really.
But that said: I'm severely puzzled about your choice of HN username.
Breivik is a fairly common last name. There are actually 8 men in Norway who have Anders as their first name, and Breivik as their last name.[1]
[1] http://www.ssb.no/navn/sok.cgi?lang=n&fornavn=anders&...
It could just be his name, that coincide with the more famous one. It can happen.
I work on a legacy code base with pretty much everything in SMARTY templates (including CSS and JS files!) and it's really aweful. It may not be SMARTY's fault, but most of what's going on could be just as easily done with PHP code than with SMARTY tags, include variable insertion (<?=$var?>) and control logic (if ($var) : // endif;).
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.
No disable your short tags and any nontrivial template will become ugly as hell, unless you are on php 5.4+ which not many are.> include variable insertion (<?=$var?>)
I enjoy using Hiccup more than any template engine I've used previously. Before I met (Clojure and) Hiccup[1], I would have said the same regarding Coffeekup[2].
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
Nobody mentioned twig yet, so I will: http://twig.sensiolabs.org
And seriously, check Symfony 2 out.
I think that twig got its root in the django templating engine (which is python based), because of the resemblance. It's very good indeed. I'm not sure if the original had support for filters though.
Those features are a persuasive argument against smarty as a template language.
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.
@zdw, I actually think twig is nicer :) It's almost identical to jinja.
So does PHP not let you mock things by actually writing classes in the test file, like:
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 :)
It does; it's just not very common.
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.
When was PHP good in the past? (Honest question; I don't use PHP.)
When shared hosting was the norm. mod_php was much faster than CGI and a lot safer to use because usually processes in one virtual host did not affect processes in another unlike with mod_perl and the like.
Quite possibly never, but it was arguably the best web language in the early 2000s.
Perl fans would probably object strongly to that, but it is true that when PHP first caught on there really weren't any great choices.
The strong selling point of PHP for a long time was cheap hosting. Combine that with a fast learning curve and you're set.
Nowadays, it's not so clear cut price wise, but PHP took a strong advance in term of user base - look at the number of libraries, projects, and jobs (!) available in PHP, vs python or ruby.
good selling points, but those things never made it a good language, it was just convenient.
PHP followed a very uncommon path. Features were added as needed, in an incremental fashion. Nice syntax is never a huge problem, though that's probably most people complaint. That said, it isn't worse than its "contenders" in terms of feature set. You get a decent object system, lambdas (note that they'd been there for a long time, but it's more convenient now), a wide range of bindings. It's not pretty, but it does the job in many cases.
But, anyway, if you're really looking for a good language (something efficient, where you don't have to spend hours to spot a stupid bug), skip the dynamic ones altogether, and go for as much static analysis you can get.
Those examples aren't good differentiators between PHPUnit and Phake. And unfortunately, despite how goot Composer it, it just adds another package management system into the mix. GitHub has ended up being the best package manager PHP could really ask for.
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.
You shouldn't forget about PSR-0 / http://www.php-fig.org/
PSR-0 would be great, except for the use of mixed case filenames. The number of packages that have obviously only been tested on HFS+/other case-insensitive filesystems is staggering (or maybe I just have bad luck picking ones). The only logical reason I can see they didn't normalize and lowercase filenames is that the big boys had too much legacy cruft already broken.
To all the language bashers, can we all agree that a good developer beats a bad developer in any language?
I wrote a post on this: http://news.ycombinator.com/item?id=4606961
composer is great, I'd just like to add that the docs make the distinction that it's a dependency manager rather than a package manager.
Serious question: Do you know of successful/large web startups in the last two years that used PHP as their main language?
I would be interested in the answer to this also, but I am coming from the side of expecting lots probably are.
Iirc some startup hired rasmus lerdorf, the creator of php.
Again?