51–60 of 203 posts
I often wonder why a PHP killer hasn't yet been created. I don't mean a Ruby or another vastly different language. I mean a language similar in approach to PHP, but with the gotcha's removed, some order and consistency introduced into the API, and a few changes to the defaults. Open source, free, and on all major OS's.
check what PyPy did (or is doing with PHP).
I often wonder why a PHP killer hasn't yet been created. I don't mean a Ruby or another vastly different language. I mean a language similar in approach to PHP, but with the gotcha's removed, some order and consistency introduced into the API, and a few changes to the defaults. Open source, free, and on all major OS's.
check what PyPy did (or is doing with PHP).
All this is very true. Modern PHP is not the PHP of yesteryear. With Composer for dependancy management and sticking to the PSR's you can build very stable, testable, and modern applications that change minds about PHP.
PHP users need to keep it together and set a common base, a standard library with sane defaults.
Earlier quoted context omitted.
Make the "stdout == response body" an explicit option Why? It's a primary differentiating factor for PHP, and one of the cornerstones of its popularity. Given that it powers a non-trivial percentage of the web, from single page "hello world" sites up to multi billion dollar ecommerce sites, I'd say 'fixing' that one aspect is not something that needs to be. "== should work like ===". Why? If you want ===, use ===. Bu…
1: "Explicit option" means it's still possible, but shouldn't better practices be encouraged? Anything to push developers away from interleaving logic and templates 2: PHP, however, has types. == is wildly unpredictable
2. I wonder if reliance on == has ever caused any major security issues? I know there's some edge cases, but I can't remember a time == ever came back to bite me. (Yea, you can point to strpos(), but everyone knows that example and it's marked with a big red box on php.net.)
I'm a Drupal dev by trade, and I consider any day that I don't have to get into the guts of Drupal and write PHP a good day. Recently, however, I had to get in there. This was a few days after I upgraded my local environment from 5.3 to 5.5. I've been writing Ruby for fun for a while now, and I love how I almost never have to look API related questions up, at least in comparison to PHP API questions. So I just wrote…
I'm a Drupal dev at my day job, application dev at home. I love getting into my codebase for my sidejob, but D7 is awful under the hood. PHP isn't what makes it messy, it's the procedural hook system.
And yes, PHP 5.5+ is awesome to have.
Earlier quoted context omitted.
The web server is explicitly for development purposes. It is not meant for production. > It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place. This is profoundly ridiculous. It's the equivalent of saying Home Depot shouldn't sell power tools because some do-it-yourselfer might saw his foot off. Just because a tool can be misused is not an argument ag…
> The web server is explicitly for development purposes. It is not meant for production. Doing that would mean the dev/prod environment is different, which is not that great of an idea. Keeping them as similar as possible leads to less chance of "but it worked on the dev server" sort of problems.
> generators for simpler iteration, namespaces, and variadic functions and argument unpacking. With PHP 5.4, traits were introduced (a la Scala or Perl) to allow code reuse in single inheritance languages, as well as closures, which allow you to code PHP in a functional style. "The new Java" It's good to see PHP maturing. However sometimes the most important features of a language are the features you don't add. I th…
> It contains powerful new features and helpful developer tools, such as a built-in web server I haven't finished the article yet, but really? Is that what PHP needs? A built-in web server? It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place. How long until we start having security releases for the PHP web server, because so many clueless devs decid…
The web server is explicitly for development purposes. It is not meant for production. > It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place. This is profoundly ridiculous. It's the equivalent of saying Home Depot shouldn't sell power tools because some do-it-yourselfer might saw his foot off. Just because a tool can be misused is not an argument ag…
You're incorrectly characterizing the argument: it's actually like saying Home Depot shouldn't sell power tools without safety guards, fuses, emergency shutoffs, SawStop, etc. PHP has a number of misfeatures which make it extremely easy for all but the most vigilant of developers to make mistakes with security consequences (https://eval.in/108854 was making the rounds just this morning) or simply increasing the likelihood of creating bugs (i.e. the inconsistent parameter ordering across the similar array_* functions). Most of these complaints date back to the late 90s but now are much harder to make both because the core developers don't take them seriously and because there's now a huge backwards compatibility problem.
The most interesting development in PHP is the HHVM hack mode or similar concepts where an actively-maintained codebase can opt-in to safer behaviour. For the sake of anyone who has to secure code on the internet, I hope this catches on.
EDIT: See slide 15 onward in http://www.slideshare.net/skamerman/ipc-2013-high-performanc...
> It contains powerful new features and helpful developer tools, such as a built-in web server I haven't finished the article yet, but really? Is that what PHP needs? A built-in web server? It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place. How long until we start having security releases for the PHP web server, because so many clueless devs decid…
Before : Install php, write php, install apache / mod_php, refresh.
After : install php, write php, refresh.
[1] no need to install/configure a complex standalone server, focus on embedded thus more cohesive routing systems instead of fragile rule-on-top-of-regexps as seen in apache.
Earlier quoted context omitted.
The web server is explicitly for development purposes. It is not meant for production. > It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place. This is profoundly ridiculous. It's the equivalent of saying Home Depot shouldn't sell power tools because some do-it-yourselfer might saw his foot off. Just because a tool can be misused is not an argument ag…
Just because a tool can be misused is not an argument against it nor its inclusion. I used to believe this, but now I couldn't disagree more. People can and do misuse things all the bloody time, and the more you enable them to do that, the worse your tool is. How people use what you make is every bit as important, possibly even more important than the technical merits of what you make. I'd rather a builder use a seco…