41–50 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.
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.
Earlier quoted context omitted.
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
1. Why add complexity when it isn't necessary? Inline output is one of the best features of PHP in that it makes it extremely easy to get started using it. If you want templates you can add them. Not everyone wants them. 2. PHP is dynamically typed, like many other languages, and so you just have to know what types something can be and how they behave together. Even in a statically typed language you need to know how…
And not every project needs them.
PHP has been wildly successful precisely because it can fit in entirely small use cases, as well as big cases.
Someone who needs to create a dynamic footer with a "copyright $year" in it... has no need for MVC, routing, templates, version control, etc. They just don't. It's precisely because PHP has a default content-type output of 'text/html' that this sort of 'throwaway' functionality can be done with PHP and pretty much no other language. Not that other languages couldn't do this, but everyone seems to turn up their nose at this market. And yet... this is where the majority of the next generation of developers (and the current gen, and the one before) come from.
Let the hate begin
1. Developers complain a lot, and that's a good thing. While it can seem unproductive at times and devolve into flame wars, the truth is you're not likely to choose this profession if you aren't curious and care about the right damn thing happening.
It's just a byproduct of what it takes to be a good dev. We research, we understand, and then we want to stand by our opinions because of that research and understanding. But we can also get lost in that sometimes. It's important to have pragmatism in our toolbelt.
At the end of the day, core maintainers or contributors make sure to cherry pick the best from those arguments. Pull requests are made. Merges happen. Things improve. It's not always pretty, but discourse is like that.
2. The world isn't perfect. Neither are languages. PHP has its share of rough spots, but then it's how you use it. We've all seen some truly awful Ruby on Rails code, just as we've seen some solid, testable PHP code. Your job is understand the deficiencies of a language (any language!) and craft the best code around those limitations.
3. Shiny new things give us blinders. The antithesis to ad hoc PHP might be Ruby on Rails. Yet people discount some drawbacks that are unique (from PHP) to RoR. Do generators, which are encouraged, really help teach a programmer about how their application stack is operating? Maybe you could tell someone to avoid scaffolding. Is Rails faster than well-architected PHP? Hell no, but maybe you could teach someone how to tweak middleware or use JRuby. But you'll notice the same pattern I mentioned in #2: understand deficiencies, create workarounds to those limitations. It's not unique to PHP, or any other language/framework.
And finally...
4. When you are building things meant to be consumed by the general public, more goes into a language decision than the features of that language. You might, for example, have a business requirement to hire up and move very quickly. Are you going to round up a bunch of seasoned, veteren Go engineers in a few weeks to build the next sprint of some great app? It's probably not impossible, but it's not likely either (today). The trick is to solve the problems you actually have.
I'm not advocating everyone use PHP. I'm advocating everyone use the language that best suits their personal or larger business needs. If you care about improving PHP, help make it better. We, the general dev community, are all too busy, considerate, awesome, hard-working, friendly, and creative to spend much time on flame wars. :)
> 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…
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.
Earlier quoted context omitted.
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
1. Why add complexity when it isn't necessary? Inline output is one of the best features of PHP in that it makes it extremely easy to get started using it. If you want templates you can add them. Not everyone wants them. 2. PHP is dynamically typed, like many other languages, and so you just have to know what types something can be and how they behave together. Even in a statically typed language you need to know how…
Predictable !== well defined. If you have to look through a chart for equivalence, it's unpredictable to the programmer. But this is a theme for all of PHP, you can't deduct equivalence, function names and function arguments orders, you have to memorize or peruse the manual. Sure, it works, but it has drawbacks.
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.
The big thing PHP has going for it is the huge amount of open source software, and the number of webhosts which support PHP by default. Most of the webhosts can barely keep PHP updated, and the ones who don't, justify it by wanting to avoid breaking backward compatibility with open source software.
Getting widespread adoption for a PHP alternative would be a serious feat.
I don't get it. Why people can't just admit the fact that PHP had his time and now, no one with common sense would not start new project (except simple wordpress stuff) in 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.
Look at Py3 vs Py2.
At the end of the day, the way I see it, the true advantage of PHP was its lower barrier to entry. Now that this has mostly been resolved via PaaS hosting, it seems to me we're moving to a word where Node is the new default, because Javascript.
I don't get it. Why people can't just admit the fact that PHP had his time and now, no one with common sense would not start new project (except simple wordpress stuff) in PHP.
Is that really what you meant?