PHP has reached its limit(sloblog.io)
sloblog.io
PHP has reached its limit
http://sloblog.io/~zynisch/qI3DyGJd0yo/php-is-dead-jim
14 comments
OK so weirdly, he claims PHP is dead but actually specifically says he's comparing two frameworks. So, does that mean because Rails recently had a heap of vulnerabilities, Ruby is automatically insecure?
No.
There is a difference between a language and a framework. That Flow is yet another attempt at an "Enterprisey" mvc framework for PHP is a fault of the developers of Flow, not the language it's written in.
No.
There is a difference between a language and a framework. That Flow is yet another attempt at an "Enterprisey" mvc framework for PHP is a fault of the developers of Flow, not the language it's written in.
A limited templating language forces you to behave. More importantly, it also forces other people to behave. It stops people from creating ugly hacks in the middle of templates that become impossible to track bugs. It stops Joe Random Designer from being able to break your database when he works on a new header design.
If you need a templating language to force you to behave, you are not likely to understand why you need to "behave".
If others "misbehave" fucking tell them not to - why does everyone look for a technical solution to a human problem?
If others "misbehave" fucking tell them not to - why does everyone look for a technical solution to a human problem?
I totally agree with this. To many times developers of frameworks or other reusable components seem to try to protect developers from themselves.
I understand that there is a good argument for this but in the end it's making everything more complex and limited for developers who do understand what they're doing.
I understand that there is a good argument for this but in the end it's making everything more complex and limited for developers who do understand what they're doing.
I don't think PHP will die off for a long, long time. The low barrier to entry and ease of deployment means that beginners will be able to hack together solutions to their problems and even experienced programmers are able to use it for short and simple tasks.
The article makes a rather poor case for PHP being dead. It focuses on some syntax issues and doesn't touch on the strong business case for using PHP for many types of smaller projects.
If you're a small business that needs a couple of forms setup, say an order form and a contact form, PHP is a very reasonable choice. A small business that sells something online isn't making money by producing the most elegant possible code - they make money by setting something up to solve their problem, using cheap shared hosting they don't have to worry about setting up or maintaining, and focusing on selling their product. PHP is a great choice for that - and really that's what most small businesses actually need.
My suggestion would be to use the right tool for the job. For a simple small business website with a couple of forms, PHP might be the best choice. For a complex web application, Rails is a much better choice.
The article makes a rather poor case for PHP being dead. It focuses on some syntax issues and doesn't touch on the strong business case for using PHP for many types of smaller projects.
If you're a small business that needs a couple of forms setup, say an order form and a contact form, PHP is a very reasonable choice. A small business that sells something online isn't making money by producing the most elegant possible code - they make money by setting something up to solve their problem, using cheap shared hosting they don't have to worry about setting up or maintaining, and focusing on selling their product. PHP is a great choice for that - and really that's what most small businesses actually need.
My suggestion would be to use the right tool for the job. For a simple small business website with a couple of forms, PHP might be the best choice. For a complex web application, Rails is a much better choice.
PHP is not Java.
PHP is not Ruby.
PHP is not Python.
PHP is definitely not Perl.
Developers need to stop trying to force it to look and act like the languages they would rather be using. It doesn't have to be as ugly as Flow appears to be, at all, and in some PHP frameworks, it isn't. Because as has been mentioned already, comparing a framework with a framework is only valid when you pick the best framework, and as the Rubyists are fond of pointing out that Ruby Is Not Rails, well, PHP Is Not Flow. Nor is it Symfony or Yii or Laravel or Zend or the framework I'm building in my spare time which is still not quite as ugly as Flow. This article's argument is as arbitrary as it its conclusion is irrelevant.
The reasons PHP is not, and will not soon be, dead have to do with its ubiquity and utility in its one and only purpose -- preprocessing html. It does this perfectly adequately for many many use cases, provided you approach it like a donkey and not a horse. It is the animal that it is. Otherwise, you wind up with a swift kick in the shins. It's ugly, and ornery, and it stinks but it does its job and it's cheap and simple and it's not going away anytime soon.
Developers need to stop trying to force it to look and act like the languages they would rather be using. It doesn't have to be as ugly as Flow appears to be, at all, and in some PHP frameworks, it isn't. Because as has been mentioned already, comparing a framework with a framework is only valid when you pick the best framework, and as the Rubyists are fond of pointing out that Ruby Is Not Rails, well, PHP Is Not Flow. Nor is it Symfony or Yii or Laravel or Zend or the framework I'm building in my spare time which is still not quite as ugly as Flow. This article's argument is as arbitrary as it its conclusion is irrelevant.
The reasons PHP is not, and will not soon be, dead have to do with its ubiquity and utility in its one and only purpose -- preprocessing html. It does this perfectly adequately for many many use cases, provided you approach it like a donkey and not a horse. It is the animal that it is. Otherwise, you wind up with a swift kick in the shins. It's ugly, and ornery, and it stinks but it does its job and it's cheap and simple and it's not going away anytime soon.
What is this... comparing a framework with a language? Compare Laravel with Rails, or PHP with RUBY... not RAILS.
While the use of terms rails and ruby is confused in the article, the actual content is using two frameworks with similar goals and similar sounding philosophies to compare what what the languages can offer for a framework developer.
That to me sounds like a fair way to approach it. Having said that, my experience of the PHP framework is this post, and while the goals sound similar, the teams behind them could be interpreting them in very different ways, which wooild lead to the differences seen.
That to me sounds like a fair way to approach it. Having said that, my experience of the PHP framework is this post, and while the goals sound similar, the teams behind them could be interpreting them in very different ways, which wooild lead to the differences seen.
The homepage for the Flow framework has this in the title:
TYPO3 Flow Enterprise PHP Framework
> I’m getting paid to post here
That says it all.
That says it all.
Presumably by the word.
Sarcasm.
So i just had a quick look at the Flow Doco and found http://docs.typo3.org/flow/TYPO3FlowDocumentation/Quickstart... - then I found http://guides.rubyonrails.org/getting_started.html#hello-rai...
Seriously, what the fuck is this? Why would you need or want a "welcome" screen for a FRAMEWORK?
Seriously, what the fuck is this? Why would you need or want a "welcome" screen for a FRAMEWORK?
I'm perfectly happy with PHP. I'd rather concentrate on what I'm actually shipping instead of worrying about how efficient my language is.
Good article, I guess PHP certainly isn't the most elegant language but it serves it's purpose; an easy to understand tool to add some dynamic features to html. The huge amount of resources available do make it kinda easy to hack something together. For larger more complex applications it would certainly not be my first choice either.
All this article demonstrates is that PHP is more verbose than than Ruby with a good DSL. This exact same logic could be used to argue against Java.
There's plenty wrong with PHP. Verbosity is the least of its sins.
There's plenty wrong with PHP. Verbosity is the least of its sins.
Sorry but even myself that don't like PHP that much turn to it for my own web site.
It is just good enough for what it was conceived to do, plus all ISPs offer cheap PHP plans, what cannot be said for other languages.
It is just good enough for what it was conceived to do, plus all ISPs offer cheap PHP plans, what cannot be said for other languages.
I don't see how comparing Flow vs. Rails proves PHP as a language has reached its limit relative to Ruby as a language. Most of the examples seem to be syntactic vs. anything "limit" related.
It's not about what instruments to use, it's about how to use them. PHP is definitely not dead and won't die soon.
There should be a Coffee PHP like CoffeeScript for Javascript. PHP will overcome its limit ;)
> Metaprogramming and reflection have to be implemented by the framework as they’re not part of the language.
Every example there seems to relate to a framework called "Flow", and the author sums this up quite succinctly:
> It took them five years to experiment and find something that works for them
The key words are the last three. WORKS. FOR. THEM. I've never heard of Flow before, and from what I've seen in this blog alone, it looks like more PHP developers who want to be Java developers.
I agree completely that the examples shown are fucking horrific, but thats not a fault of the language.
Let's take the "Fetch a record" example. It's perfectly possible to have a php model that works like so:
As for the templates, yes the Flow templates are fucking stupid. That's still not a fault against PHP - I've given up trying to understand why people feel the need in PHP - which is itself an excellent templating language - to create new, more complex and yet limited template languages.