[fleitz]

I took a look at that, it appears that you unzip the framework and then start modifying it directly. After you "upload it to your webserver". Deployment? Source Control? No, not in PHP, you just modify shit right on the webserver.

I'm sure this process makes upgrading painless, just unzip the framework and... wait... all your changes just got overwritten.

This kind of crap is exactly why everyone with a clue laughs at PHP.

[memla]

No. Everyone knows that you do not modify the framework files. Hell, everyone knew that you do not touch the framework system files years ago with older frameworks like CodeIgniter, so it makes me doubt that you have any experience with PHP frameworks at all.

You would upgrade your Laravel framework with composer, which runs on Git. And it'll most likely just work without any "Gem hell" that i've come to experience with some other languages.

[fleitz]

Yet the framework docs say none of this. Look at rails, it tells you, put your gems in the gemfile.

Laravel says, hack shit directly on your webserver.

If you're supposed to use composer, why don't the docs say this? Instead the docs say, unzip and hack.

[memla]

The docs don't say that you would update the framework via composer (though this may change when Laravel 4 is released) but they do say that you should just replace the "laravel" folder with a new version using whatever method suits you best, which can be even easier. It certainly seems easier than upgrading Rails, since then you can update your whole remote application code and framework in a single push.

The docs clearly explain that your bundles go to the "bundles" directory, controllers go to the "controllers" directory, views belong in "views" and so on. And your whole application resides in a directory called... "application". You'd actually have to be pretty advanced and amazingly stupid at the same time to make a functional app in the framework core folder and than destroy it by overwriting.

Rails docs don't tell me to unzip the framework and start hacking, but they do instruct me to run "gem install rails", wait a couple of hours till it's done, then run "rails new blog", "cd blog" and then start hacking. Neither set of docs tell me how to setup version control before i begin my work, and they shouldn't. That's not the job of the framework docs.

And of course you're gonna hack your application directly on the server, albeit a local one, as PHP applications are typically developed. This in no way prevents you from using version control and proper deployment techniques.

[aw3c2]

Nothing stops you from using source control with PHP. Nothing stops you from working locally and then pushing changes up to the server. You make no sense.

[jtreminio]

Wow, you're the type of developer who would leave an absolute mess in his wake.

Everything you said I rail against daily. Stop bringing your bad habits into PHP, we have enough of them already.