My grandparents - sometime in the '80s - had an early-model cordless phone. It was a lovely object: the ivory-colored plastic handset was a smooth curve, with no sharp edges. Being able to talk on the phone from the backyard was magic! It had just enough range that my grandmother could carry on a conversation throughout her daily circumnavigation of the house to turn on the sprinklers.
Sometime after they got it, so did their next-door neighbors (not necessarily the same model: they weren't - irony! - on speaking terms), and then sometimes you'd pick up the handset and find yourself eavesdropping on both sides of the neighbor's phone call. Fortunately, the manufacturer had anticipated this: there was a three-position frequency-selection switch on the side. (I can't remember if the base station hopped to whatever you set on the handset, or if you had to set it manually on the base, too.) That worked fine for a while, we used frequency #2, the neighbors used... one of the others, until (I assume - we never heard anyone else's calls) a further-away neighbor or two also got a cordless phone, and the next-door folks had to frequency hop.
They put up with that for a while, and then sadly reverted to corded phones until more-advanced cordless tech became available.
Most common symptoms of PFO are described in the article: "migraine headaches, or have altitude sickness at 5,000 feet instead of 10,000 feet, or find yourself panting while doing a slow jog, no matter how often you train."
Also should be noted that there are much many other subtle syndromes that can lead to sudden cardiac death, many are detected accidentally when testing something else (going to the ER because of a car accident)
There's no math formula to detect how and when each of us will die one day.
My personal opinion is that either no symfony and no pux should exist.
There's no need to reinvent frameworks in PHP as PHP is the framework already.
There's no need to reinvent templating in PHP as PHP is the templating already.
If you require different productivity from a language just don't stick on PHP and make the right choice by using the most appropriate language for you. There's plenty out there.
PHP is great, it rocks and is very fast when used in the right way.
If you're building a web application in PHP, then symfony is a huge improvement over naked php files or rolling your own bootstrapped system. Right out of the box it addresses concerns of security, user management, routing, persistence, and myriads of the other basic needs of a web system. Packages for many common components are already built, meaning you can get sophisticated functionality working quickly. It is modular enough that you can include only the components you need.
The built-in templating language, twig, actually provides a number of benefits over bare PHP templating. It addresses security concerns, has a concise and clean syntax, and compiles down to optimised PHP template code, minimising the performance hit.
If you are suggesting that PHP shouldn't be used for web applications, and should only be used for basic templating, I would be interested to know what you consider to be an "appropriate language".
Look at the php.net website source code. Another example could be the Wordpress source code. It's not handsome code, but it just works.
Things like fat (either slim) frameworks should be memory resident (java or similar), not reloaded from scratch at each web request, it just won't never perform on big sites.
Alternatively, if you need to deal with bigger applications, or massive traffic, you can build some kind of backend memory resident application (c, c++, java, go...) and delegate the hard work to it by using a lightweight rpc protocol (see messagepack, thrift, protobuf), and leave PHP alone to do the job it's born for.
Also, the choice to adopt a framework is serious stuff, it firstly should be well designed and maintained, then it should suit exactly your needs and more importantly you should not just use it, but learn conventions and write your code by sticking on them or else all your code will result in a bad mess.
Honest question: while I know that's true (I was using APC, now using Zend Opcode or whatever the replacement in PHP 5.5 is whose name escapes me at the moment), it seems to me that there's still going to be a performance penalty incurred. The PHP may be all compiled to bytecode at that point and the bytecode may be 100% memory resident, but you're running through all the initialization routines for the framework on each and every page hit.
"Pure" PHP is a pretty fast language when benchmarked, but PHP frameworks tend to benchmark poorly, and I've always assumed that the overhead incurred by PHP's execution model is the culprit -- essentially, PHP was written with assumptions about How Dynamic Web Sites Work that made sense in the late '90s but really suck when every request is hitting a front controller and being dispatched through a router. Is this not the case?
Yes you can use APC, opcache or XCache to load php bytecode in runtime. but you are still calling php functions/methods or creating a lot of objects in runtime. that's the overhead.
Too many people are losing sight of the power of 'pure' PHP and jumping on the framework wagon unnecessarily. That doesn't surprise me, as frameworks provide structure and rules to a language that is very messy.
Sounds to me like the classic apples and oranges comparison.
In my opinion Javascript's evolution has become a requirement more than just a story of success. It was the de facto standard language for browsers but with big lacks of performances. Browsers vendors worked to improve it and everything was only a natural consequence of the evolution of the World Wide Web.
Perl's history is completely different. Perl has always worked behind the scenes, and still does it greatly. It has a stable, rock solid, very performant and widely spread runtime.
Let's just call things with their names and use them for the purpose they are born and everything will look less confusing.
More than else, always remember: You can write FORTRAN in any Language.
