About a year ago I was ready to jump ship on PHP. Then someone introduced me to Composer, Symfony 2 and Doctrine 2. I fell in love with PHP again, not because of the language but because of the tools. Its now clear to me that the language doesn't really matter that much, it's the tooling around the language that makes the difference.
Agreed. One thing to consider is how the features and performance of a language shape the tools. The tools can be great, but to some degree you're riding a long distance skateboard with a generator on the back...
Edit: This comment comes off as me making fun of PHP, when I simply meant to say that tools can make something effective but what underlies an effective work environment can still be crap. I don't think PHP is "crap," but at a certain level of complexity its easier to get the "average developer" to be effective using another set of tools.
Dmitry is the man who originally wrote eaccelerator, Zend caught wind of him and hired him! Then he worked on opcache and has done some amazing things in getting the Zend Engine and PHP itself flying. He's a very smart cookie.
His good sense is obvious by the way he stopped going down the JIT route and zeroed in on the bigger performance drain, memory allocation, instead. The smart programmer knows how to write a JIT; the wise programmer knows how to not write a JIT.
JIT is probably coming too, just with current way the engine built it turns out it is very hard to do JIT that makes any real-life impact. One can get magnificent benchmarks, but once you hit real-life apps, you get very low improvement. Thus a more attainable goal was chosen, but JIT may come back yet.
> We still do new projects in PHP and we couldn't be happier.
I concur, especially when frameworks like Symfony exist. Reading all this smack talk about PHP on HN is so alien considering how thriving the PHP community actually is.
Nobody mentions how much or little the PHP community thrives. People point out how bad PHP compares against other languages. The fact that you enjoy using PHP and that you can create great products with it does not imply that it has no flaws.
Many have been where you are now, and then moved on to other languages to never ever look back. From what I've seen, the reverse is much less common.
> Nobody mentions how much or little the PHP community thrives. People point out how bad PHP compares against other languages.
I don't actually think that faults in a language matter that much if the people using it are competent. Both Javascript and Perl come close to PHP in terms of negative traits, yet a lot of good software was written with both. The same can be said about PHP, the only difference is that people on HN have very little idea about what contemporary PHP (language and software) looks like.
There are many good PHP web frameworks out there today, yes. These don't somehow erase PHP's core flaws as a language though.
You can make a new project in Symfony or Laravel, sure, but you'll get that same niceness plus way more goodies if you use a popular Python or Ruby framework.
The single biggest everyday-use thing I miss with PHP is keyword arguments. With PHP the only real equivalent is passing an array of arguments and then checking if each possible key exists, and that's just way clunkier.
image_urls = ['illos/' + x['url'] for x in images]
And, closures in Python -- and to be fair, just about any language that isn't PHP -- close over variables in the scope they're defined automatically, without having to use PHP's strange "use ($a, $b, $c)" construct. Yes, that's a small thing, but PHP's way is a little bonkers.
This builds a function via composition: first lookup 'url' then prepend with 'illos/'. This function is then mapped over the array.
Unfortunately relies on a bunch of functions which PHP doesn't include. Unfortunately PHP's stdlib concentrates on incredibly-single-purpose functions for, eg. string manipulation, while ignoring general programming constructs. Also, most of the really useful parts of the language aren't available as functions, for no real reason. In any case, we can define these things ourself like this:
// Function composition
function compose($f, $g) {
return function() use ($f, $g) {
return $f(call_user_func_array($g, func_get_args()));
};
}
// String concatenation. Unfortunately we can't write "concat = papply('implode', '')"
function concat() {
return implode('', func_get_args());
}
// Array subscript. I'd prefer to do this the other way around and write an
// argument-flipping function, but that's unnecessary for this example
function lookup($x, $y) {
return $y[$x];
}
// Partial application
function papply() {
$args = func_get_args();
return function() use ($args) {
return call_user_func_array('call_user_func',
array_merge($args, func_get_args()));
};
}
Not as concise, but I'd postulate easier to read for people not familiar with list comprehensions.
In PHP 5.5+ there may be another way, but we're stuck with 5.3 in production for most clients, so I'm not up to speed.
> And, closures in Python -- and to be fair, just about any language that isn't PHP -- close over variables in the scope they're defined automatically, without having to use PHP's strange "use ($a, $b, $c)" construct.
Mmm, the debate of explicit or implicit scope? Explicit at least gets round those strange errors (hello Javascript) where you think you're referencing one thing... and actually referencing something else.
JavaScript is a horrible language. The fact that a lot of good software is written in JavaScript because there is no good alternative in the browser does not make it any less a horrible language.
The problem with PHP is that it is a horrible language and there are plenty of better options in its niche. Those two factors combine to make PHP a nonstarter for programmers who are familiar with the other options.
I dispute that there is any good software written in Perl.
> I dispute that there is any good software written in Perl.
Do you even Linux? Have you ever installed anything? If you pay attention you will notice that lots of the libraries you are using for everything are written in Perl.
> Many have been where you are now, and then moved on to other languages to never ever look back. From what I've seen, the reverse is much less common.
I really doubt that. In my experience there haven't been a single time when someone attacking PHP actually knew something about it that wasn't outdated by at least 5 years.
It's funny how difficult it is for people like you to grasp that the language and its ecosystem evolves every day, much faster than other languages. Just look at what you just said. How can someone have been where I am right now? They used a time machine? Or you are assuming that the language stopped evolving at some point, or never evolved at all in the first place?
I've probably written about 20x as much code in my life for fun, than I did to make money.
Guess I'm not a "real world people".
Though that ratio changes a bit closer to 3:1 looking at only PHP code I ever wrote. The "for fun" element was good times though, my first steps in server side programming :)
Something needs to pay the bills. If a PHP project takes longer to complete (I'm not saying it does), is harder to maintain, etc than an equivalent project written in another language, then you will simply be less productive in PHP.
This is the case for any language. No matter how much you enjoy something, if a design choice you made (like choosing PHP, or Perl, or C++) means that you spend more of your time on the project, you've made a mistake. The purpose of a language is to remove as much of the incidental complexity of the project as possible, leaving only the (more enjoyable) intrinsic complexity.
It's a mature, well designed and cleanly written piece of software that is very modular. It also has a great documentation and knowledgeable community around it.
Other PHP frameworks lack some or most of these features: some are either very opinionated and rigid (Yii, Cake) huge and sparsely documented (Zend 2) or just old and approaching abandonment (Codeigniter, Kohana).
Symfony can be overwhelming for a newbie, but that's because web development is becoming a bigger field every day. There is so much to learn, and Symfony will teach you all kinds of best practices and other things that are not framework-specific at all. To learn Symfony is to learn web development done right.
Laravel is basically a wrapper around Symfony, to make it simpler and easier. A newbie might prefer to use that, but at some point after feeling comfortable with the basics like MVC, ORM, etc. you will definitely want to move to the more professional Symfony.
Yup, Laravel is a great starter framework. Like jafaku said, it uses a lot of Symfony components under the hood so it will be familiar territory if you decide to try out Symfony one day.
Be sure to check out Jeffrey Way's Laracasts, it's a really good site offering tutorials mostly for newbies.
I really like Yii. In my opinion it is exceptionally well designed and offers so much functionality.
The Yii programmers designed it with performance in mind. I can understand that you find it opinionated, but in my opinions the pros outweigh the cons.
I liked Yii too, until I had to switch to Laravel for a new client. While Laravel is missing a few features baked in, like generators and admin tools, 95% of Laravel is way better designed and documented than Yii.
The only worthwhile point I still see in favor of Yii is its ORM can generate fewer, albeit more complicated, queries when eagerly loading nested objects. (OTOH, I encountered some ugly pagination bugs last summer when doing that...)
>It's a mature, well designed and cleanly written piece of software //
Just went to the Symfony site for my first time, to have a look. OK, I'll install it ... requires use of Alpha software (Composer) to install? Also, they tell you to pipe that script straight through PHP - don't appear to be any sha hash sums given or anything. Doesn't seem terribly mature and well-designed so far.
How do you generate 211 pages per second on Wordpress to begin with? My server does page generation for my own custom-built blog in ~15ms, but takes a whopping three seconds for a single Wordpress page. I know it's somewhat offtopic and it's about the relative results, but what hardware is this?
My Linode VPS spits out WordPress pages in 33.811ms (via ApacheBench, concurrency=10 for a couple hundred requests). I don't use any kind of content/page cache. There's no reason WordPress would be 200 times slower than your custom blog -- WordPress isn't some kind of complex software. It's a handful of very small PHP classes that choose a theme file based on the URL, include it, run a database query to select some posts, wrap the result rows in objects, and pass them to the theme to spit out. I've had hundreds of concurrent visitors on my blog without registering any load. If your site is taking 3 seconds to return a page, there's something wrong and it's not the choice of blog platform.
I meant a clean wordpress install. No themes, no plugins, just a basic install. Three seconds. My own blog does about 3 mysql queries and manages that in 8ms at best (usually 22ms at worst; typical seems to be around 15ms). The most limiting factor for Wordpress was cpu speed.
Yeah, WordPress can get slow pretty quick, but a naked install should be pretty snappy. The codebase itself is pretty small (~50kLOC) but the DB queries can get ugly depending on the plugins installed. Naked WP on GoDaddy or similary crap shared hosting site can be slow, but certainly not on a VPS.
Mostly CPU usage would jump to 100%, it's not mysql or RAM shortage. I know an Intel atom isn't much, but it ought to do better than this, especially compared to custom software.
Could just be your hosting. For example, with Media Temple (years ago) I found it often took 7+ seconds just to redirect www to non-www, up to 12 seconds. Pingdom is a good tool to see where you're getting stuck http://tools.pingdom.com/fpt/ Another common problem, your MySQL database could be overloaded (especially with shared hosting) and more caching won't necessarily solve the problem.
If it's my hosting (which was an eee pc btw) then why does my self-written blog load in 15ms? But yeah on shared hosting with more cpu power, wordpress performed much better.
I meant raw page generation times. With caching it was much quicker of course. I assume the PHP benchmarks are also non-cached, else you're just benchmarking the caching method.
Yea, opcache "caches" the compiled PHP code. So the first "page generation" might take ages, because PHP has to load all the .php files and compile them. But an opcache will _keep_ the compiled versions around, so the next time you need to execute the .php files, it can skip the (very expensive) step of compiling them again.
This makes PHP much, much faster. The only time the files are recompiled are if you restart your webserver, or if you modify the .php files.
I'm not talking about static html generation, that's another thing all together.
This is not a WP issue. It's most likely a bad plugin or theme. You can use something like P3 (Plugin Performance Profiler) to see where the issue is. It could also be a misconfigured system. WP requests should never take 3 sec.
You really can't judge it based on that hardware. Of course it runs slower then your "custom" blog... it is probably orders of magnitude more complex.
Also you haven't mentioned what platform you are using. I don't know if those netbooks run linux or windows, but if you are trying to host this on a desktop version of windows with something like Xampp it is really incomparable as well.
Refactoring Wordpress will make it even faster. Look at the difference between Drupal and Wordpress. It's amazing Wordpress is still used for big sites while a ton of recourses could be saved.
I don't think it's fair to say that Drupal is faster than Wordpress by just looking at the req/sec.
According to https://wiki.php.net/phpng, they benchmarked against Wordpress 3.6 (the current version is 3.9). I couldn't find anything about the Drupal benchmark, but it could be a simple "Hello world" for all we know.
Drupal is pretty slow if you disable the default caching, and sometimes even with the caching (depends on modules loaded) - part of the problem is Drupal's table bloat. I swear a naked install has 100+ tables (and with a few plugins and a few fields enabled, has 250+ tables - so you end up with tens and hundreds of queries per page load).
Drupal's big two issues are bootstrapping drupal, because all those module hooks stack up quick, and the sometimes large amount of queries run to generate a page. Drupal 8 has gotten better about not loading half of the world when a blog post is loaded, but 7 is just a wall of functions.
You seem to be mistakenly thinking that more tables by definition always == more queries. That isn't the case. A bunch of those tables rarely get queried.
I really don't understand people's aversion to database tables. I have a join, the world is ending! Pay attention to your indexes and 9 times out of 10 everything will be fine. For that 1 other time, there's Varnish.
As far as Wordpress, in my experience the number of db queries is really a bigger problem than the PHP processing. A factory-default install with no plugins runs 30 queries on every home page load. With a fancy theme and a few plugins it can be over 100 queries per page! A caching plugin is pretty much essential for any Wordpress site.
Agreed. I ran a benchmark against CodeIgniter on a test box recently and was suprised that a single query app performance went from around ~20k req/s with raw PHP (no framework) to around ~3k req/s with CI and thought that was bad for a framework. I didn't realize Wordpress performance was so much worse especially given its popularity.
Most Wordpress sites use a caching plugin like WP Super Cache or Varnish-type setup if they get decent traffic though.
You should check out the framework benchmarks. Raw php is competitive with other web dev platforms performance-wise, but the major php frameworks slow it down by an order of magnitude. I blame the PSR / on-demand class loading java-style architecture which was adopted by all the frameworks. They've copied a java architecture into a platform that doesn't have java's performance characteristics.
In my own benchmarks i've noticed all that class loading and instantiation slows things way down, even with an opcache. I find that a namespaced procedural / functional architecture performs much better, but no PHP framework works that way.
I won't disagree with you that CI is outdated, but it was originally created to work around the limitations of PHP4 and early versions of 5.x. Looking back in hindsight, it may seem "badly designed", but that would be taking it out of context.
Also, CI out performs Symfony in the web framework benchmarks: http://www.techempower.com/benchmarks/. I certainly would never equate Symfony to "real speed".
You really think those guys know how to configure for production a hundred frameworks? If you base your decisions on those benchmarks, you are gonna have a bad time.
I'm sure their benchmarks are more than adequate. In either case, if your barometer for what makes a good PHP framework is based on performance, you certainly wouldn't be choosing Symfony. If anything you'd go for for HHVM or Phalcon.
That makes no sense whatsoever. Symfony2 is fast as hell. If you don't think so, you simply don't know how to properly configure it for production. There isn't much real speed you can gain from using weird things like Phalcon, unless you don't know the first thing about caching. In fact, not having all the caching mechanisms that Symfony2 gives you will probably slow down your application, even if your code is written in C.
You realize that those benchmarks are all open source and they encourage patches from anyone if they can demonstrate it benches better?
So instead of just saying their Symfony benchmarks are bad, submit a pull request to fix whatever you think is wrong so they can get more accurate benchmarks next time.
Also their tests are run without caching for a reason. It's not a test of the language/framework if they just use whatever language to generate a static/cached file and serve it with nginx.
Really? I'm supposed to go and work for free for them, just to prove your wrong? No thanks.
> Also their tests are run without caching for a reason. It's not a test of the language/framework if they just use whatever language to generate a static/cached file and serve it with nginx.
Haha lol, so the tests are explicitly meaningless. I guess I'm done here then.
Lots of these themes include 3 menus. And Wordpress menus are notoriously query heavy. That's why a lot of sites have caching—not because the page is large, but because the menus take so long to load.
Not sure what this has to do with the topic at hand, but since you derailed the conversation let me tell you that I run several WordPress sites with a few dozen million visits a month without much trouble.
While it indeed is marked as 5.7-dev, which is because it is forked from master branch which is always marked next minor version from current release one (5.6), it is very likely that it would be next major version. The changes in this refactoring are extensive and deep, and more are probably to follow. Pretty much every extension will need to be ported. This is what major versions are for.
Good news, any idea which version this will be included in? I know PHP 5.6 is already in beta, so I'd assume this'll be PHP 5.7, but this is really good news. We have some sites that are just begging for an actual 10-30% increase in speed.
Irrelevant how? I doubt BlueHost, HostGator, Dreamhost, etc, and on and on will have implemented HHVM as their core PHP offering by then. Most web hosts still have PHP 5.3 installed, and even the PHP 5.4 I've used on Media Temple's servers is out of date.
But at the rate PHP's release cycle has accelerated (remember that 5.3 dates from 2009...) it's entirely likely that the trend will continue. And more hosts are offering up-to-date PHP versions as an option.
In 2 years, HHVM will perform so much faster than PHP 6 and Hack will offer so many added benefits that even the shared hosting guys will switch to it as it will make them serve more sites with the same hardware plus developers will push to have Hack in place anyway.
That's not how it normally works with those kinds of re-implementations.
Heck, Python 3 hasn't even replaced Python 2 -- and people will dump PHP for Hack? A language which doesn't even have a community at the moment, it's 99% Facebook people.
Python 3 is a different story! As you mention below outliers, let's not use them, please! GNU/Linux OS does not depend on PHP like it depends on Python.
For what it's worth, I agree with you. Don't know why the downvotes are coming - it's very clear to see that FB is going to be better for PHP than Zend.
I'm not sure why you guys ganged up to downvote on something obvious - PHP is loosing grounds to HHVM already. I'm considering it for all my PHP projects already - it's easy to install and most PHP frameworks are well-supported already (http://hhvm.com/frameworks/). I can imagine HHVM having integration within Nginx a la HttpLuaModule, which uses LuaJIT and would eliminate going the FastCGI route.
>I'm not sure why you guys ganged up to downvote on something obvious - PHP is loosing grounds to HHVM already.
Perhaps because some on HN are computer scientists, so to convince them it takes actual numbers and not some anecdotal evidence of what you personally use.
Judging from all available data sources, you are an outlier.
HHVM doesn't have that large a community (mostly FB people), is not installed in the overwhelming majority of hosts, still has compatibility issues, has few posts about it, there are very few mentions of companies using it, and, for what it is, has been largerly ignored in the whole PHP community (forums, etc).
>Perhaps because some on HN are computer scientists, so to convince them it takes actual numbers and not some anecdotal evidence of what you personally use.
And then goes on to say:
>HHVM doesn't have that large a community (mostly FB people), is not installed in the overwhelming majority of hosts, still has compatibility issues, has few posts about it, there are very few mentions of companies using it, and, for what it is, has been largerly ignored in the whole PHP community (forums, etc).
The difference is that I gave objective and easily checkable statements.
References? I referred to specific items (hosts supporting it: just check the top 10 shared hosting providers), mentions of companies using it (how many have you seen on HN?), compatibility issues (those are documented on the project page), etc.
All of those are references to data sources you can actually check.
I'm not going to crunch the numbers for you, but unlike the parent, you don't have to take my word for it.
Pointing to the data themselves is actually more scientific than the "references to data", if by that you mean some websites and news sources feeding you with ready made data points ("20% of developers are thinking of adopting HHVM, we know, we asked 100 of our pals").
I have nearly 30 years of professional experience and my intuition is pretty reliable. If HHVM wasn't what runs the largest PHP app in the world, things would have been much different. Hack brings many language people that Zend for one reason or another didn't not deliver all these years.
>I have nearly 30 years of professional experience and my intuition is pretty reliable
Any other examples of it panning correctly?
In any case, let's check back in 2 years. I doubt Hack/HHVM will have more than 20% adoption even then. Criteria:
Number of hosting providers supporting it.
Number of posts on HN from startups using it.
Number of relevant community (forum and blog posts, contributors etc)
Number of new projects written for it (GitHub)
Number of new books appearing for it.
Rank in the Tiobe programming language index.
Blue whale is the largest mammal on the planet, but that doesn't mean eating nothing but krill is a good idea for every mammal. Everybody has different needs and different capabilities, so "Facebook does it" and "everybody does it" are quite different.
While technically your statement is true - HHVM had zero ground some time ago and standard PHP had 100% ground, and now HHVM has some ground (which is witnessed by your use of it) so PHP has less than 100% - the substance of it - implying that HHVM is somehow fast on its way to replace PHP - does not match observed reality. Extraordinary claims require extraordinary proof, and so far none was provided. It is great to see this project gaining acceptance, but let's not get ahead of the facts and claim something that does not exist yet.
Nobody cares about today; everybody cares about tomorrow. If you've closely monitored the developments around HHVM and applied knowledge from past experience with successfully managed projects, you'd have zero doubt that HHVM has all components of being widely successful. It will never reach 100%, but for larger projects, it will be preferred just like many go thru the trouble of implementing Nginx + PHP-FPM vs stock Apache + mod_php.
a) it's run developed by a company whose policy is "move fast and break things". I have seen the result of this mantra first hand in their fucking terrible Facebook "api" where something breaks every time anyone anywhere in the world farts.
b) the number and nature of incompatibilities are too vast.
c) their intention is pretty clear with "hack" - they want a php-like language but not php. That's fine they can do that but I won't use it.
The mantra is changing (as of this f8). There's nothing wrong with evolving PHP or any language. Being stalled for so long gave other languages a chance to steal from its pie, but there are signs (like with phpng) that things are changing. Java was stubborn enough not to evolve for so long, but even they learned already. Everybody is doing rapid release cycles now and that's not a bad thing. Things that don't evolve die - at least this is the perception. And developers today have a different mindset compared to 10-20 years ago.
Just have to chime in here. As someone who works with the Facebook API on a nearly daily basis, it has come a LONG way in the past year or so. When I first started with it 3-4 years ago it was an absolute nightmare. It is actually quite consistent now and they are doing a much better job of documenting / addressing bugs.
When HHVM & Hack can easily replace the 10 years of legacy php/html/js soup code and bastardized ZF1 implementations without downtime or extensive developer resources I'll believe it. Unfortunately most non-technical companies only care about performance when it's obviously costing them money (i.e., the servers are crashing.)
Looks like it will be 5.7 which is great! Just tested against our codebase, and it builds very quickly (maybe 15-20% increase in speed in unit tests) so very impressed!
PHP 6 was really about unicode support. It will actually create even confusion among veterans. Also, those PHP 6 books are really aimed at beginners.
In addition, skipping a version number also creates confusion. If they were going to go this route, they should have done it a long time ago (around 2010-2011).
This sounds like a nice improvement to PHP performance. Are there any parts of the language that will have to change for this enhancement? I expect that that changes will be minimal, if any are needed.
From what I can see there shouldn't be any userland breaks unless it's very obscure.
In the internals all of the zend_hash apis have been updated so it may have an effect on some extensions, though the core extensions can all be updated.
Love the work, but honestly by the time PHP 5.7 is ready for mainstream (with extension support mysqli, memcache, mongo), Facebook HHVM will be the defacto standard. FB has a huge head start and can throw nearly unlimited money and engineering hours at the problem. Seems like a losing battle, but perhaps I am wrong.
PHP's success is the result of PHP being available at even the tiniest webhost. I don't see that happen for FaceBook HHVM, though. FaceBook HHVM performance results will spur on Zend's efforts in making the PHP engine faster, though.
No one ever says that the different python implementations are fighting a losing battle. People generally seem to say that having multiple implementations is good for the language.
Not likely. HHVM is Facebook's private implementation and it would require a lot of time for it to be anywhere near wide acceptance, let alone "de facto standard".
>>> an throw nearly unlimited money and engineering hours at the problem
They can, but they won't. Because it already works for them, so the amount of resources they are willing to commit to something that no longer gives any upside to them will be limited.
>>> Seems like a losing battle, but perhaps I am wrong.
There's no battle and this is not a zero sum game. HHVM will have its market and standard PHP engine will have its market.
It is good to hear that they even managed to refactor their code, even if you don't look at the performance benefits.
Now, I hope that their next major upgrade will be a complete API overhaul, though it means making the existing thousands of themes and plugins incompatible.
It makes a big difference if your site isn't just for displaying static HTML content - for example, a WordPress-powered community where users log in to your site.
We still do new projects in PHP and we couldn't be happier.