PHP has reached its limit
sloblog.io
sloblog.io
> 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:
BlogPost::findByPK($foo);
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.
If others "misbehave" fucking tell them not to - why does everyone look for a technical solution to a human problem?
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.
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.
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.
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.
TYPO3 Flow Enterprise PHP Framework
That says it all.
Seriously, what the fuck is this? Why would you need or want a "welcome" screen for a FRAMEWORK?
There's plenty wrong with PHP. Verbosity is the least of its sins.
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.