We aren't in a competition against Gems or CPAN, in what world does that suggestion even make sense?
People use PHP and a package manager is needed to stop people constantly rewriting the same PHP. That means a package manager is required (we have a good one now) and support is required to take it forward (hence this post).
When will people stop the "RUBY DID IT" mentality and learn to get on with what needs to be done?
1. Build stuff.
2. Sell stuff.
3. Learn to make stuff faster.
That is not proper support for PHP, but they have had it in BETA for a while. Pagoda Box is the closest to Heroku around, it even does a lot of things much better.
This absolutely does sound like a troll, despite the disclaimer.
I use Ruby sometimes, it sure is a lovely language. That doesn't detract from the fact that PHP is still the most largely used web programming language around.
I do development work in, consult about, get paid to write about and sell commercial products using... PHP. It has the biggest potential market for me so it has the most potential customers, the most potential readers and the most potential work.
Besides, even if you personally decide to switch to Ruby the PHP community will still exist and still suffer the same problems. Those need to be fixed, no matter what.
Please do not detract from a single topic with a random "PHP v Ruby" thread. I'm not surprised but I am disappointed.
An unframework is designed to give you a set of classes that you can use to build your site. Sure, on that level it works but what about when you need more?
At some point you need to have more classes, and where do they come from? One team of developers cannot forever add in more and more classes, that would be ridiculous.
If they allow other people to add in other classes they have an ever expanding codebase. If they dont allow developers to add in other classes then you are back to the original problem: where do I find new classes that will work with my code.
By using a package management system you distribute the workload to people who need a class, and so make it. People who have a vested interest (client project, some web service they are making, whatever) are responsible for working on a set of classes that really benefit them, like a payment library that works with Recurly, Spreedly, whatever. That should be made buy one developer, and a second developer could add in a new driver - instead of building the whole damn thing from scratch.
That is the approach package managers take, and they are much more useful than a one-man-army trying to build all the libraries.
Again if Flourish meets your requirements then great, but it certainly doesn't meet all potential requirements of the whole PHP community, package managers can with the "use whats there, build what isn't" approach.
I think you misunderstand. Packages are not built to fix missing features in the core of a language, they are built for everything else.
OAuth, Authentication, Twitter API interaction, ORM's and all that jazz. None of that fits into the core at all.
You say that if the core of PHP got better then we wouldn't need MVC frameworks? What about things like ASP MVC? PHP is a language. A framework is an architecture that allows websites to be built in a certain way.
Building Composer is not "splintering by building yet another package manager", it is building the package manager we never had. Barely anybody in the community uses PEAR (I have met one PEAR developer ever, and I meet a lot of PHP developers) and there are not other existing options that work.
Composer works, so the more packages can be made generic and reusable instead of just depending on one framework the better it is for the whole community. This is the only way to reduce splintered efforts.
That is all entirely beside the point of "Adding various new good features would be good". Of course it would, but I'm not talking about trying to make every PHP developer learn C and send a pull request. That is outside the scope of this article.
I have of course seen that, but it doesn't fill potential users with much hope when they see it. I'm sure it's lovely, but in the scope of the article it is just not solving the problem unframeworks set out to solve.
It has also failed to keep up with progress, for example: fDate is basically the same as the recent DateTime object in PHP, as are many other classes now.
That is what PHP are doing, but slowly. When features are added they are often as PECL or included as classes, and not as proceedural functions.
Moving forwards it seems like PHP is making the right calls, but backwards compatibility is important to the project as PHP has more legacy code than any other web language. That doesn't mean it's dead, it just means they can't say "sod it, lets re-write everything overnight".
Primative Objects for all basic data types would be lovely, but that is another "Wishlist Feature" that may or may not happen at some point.
The point of this article is not "What languages should PHP copy to get better", I am talking about "What PHP developers can do today with the available tools to fix things for tomorrow".
PHP has everything it needs to move to a more package-based way of working, it just needs the community to take it up.
PEAR and PECL are great, but they add requirements to your application that live outside of the system.
You have to worry about your application being compatible with the version installed on the server and all sorts of other madness. Through this incredibly simple system (which will shortly become more powerful with its own interface) we can basically just install a package into your application in the same way most people would normally download, unzip, etc.
php oil install foo
Then add it to git, push and you're all good. Otherwise you have to run around installing dependencies and all sorts of other junk.
Right you are, but Alfie based this almost directly on CI. You recoded some of it, but the initial purpose and feeling of the class remains as essentially a copy of the CodeIniter Helpers. The sort of thing that is so similar it was just easier to call a port. :)
Yes we've been perfectly open and honest about every sigle class or library that has been taken from another framework. We have several of the Kohana developers hanging out in the #fuelphp IRC channel and we all get along just fine, so no issue there. If something works well, why change it? :)
I understand this, really. Dan is under a great deal of pressure, as are we all. Most of the developers run several OS projects that have a large following, but when threads like this pop up it's hard not to get frustrate. Fuel already has an amazing community with an IRC already far more active and tolerant than any framework support I know.
Try asking a question in #rails. Chances are you won't even see anybody post for 3 days, and if they reply they'll call you a fking noob.
There is no reason for us picking a specific templating engine as default. I will eventually (when I find the time) complete my parser package which will make thighs very easy to use a template "parser", with drivers for various engines. Sure you may like Twig, but I might think it sucks. Somebody else might want Dwoo, Smarty, Mustache, etc. Why would any of us be more correct than anyone else?
We use any product that makes sense. Should we be forced to develop an issue tracker in Fuel before launching the framework? And a CMS? And a forum? :)
The development team (of which I am one) all come from the CodeIgniter community and have built lots of applications and sites using CodeIgniter. The Fuel site runs on PyroCMS, which I also develop as both Fuel and PyroCMS belong to the same company. There's no point us developing a brand new CMS just to run the website for our brand new framework right?
People use PHP and a package manager is needed to stop people constantly rewriting the same PHP. That means a package manager is required (we have a good one now) and support is required to take it forward (hence this post).
When will people stop the "RUBY DID IT" mentality and learn to get on with what needs to be done?
1. Build stuff. 2. Sell stuff. 3. Learn to make stuff faster.