I came to PHP after long stint with C, C++, Objective C, Java and Javascript - and I was productive from day 1. I have programmed extensively, and have come across few quirks, but never got stuck, nor is my code spaghetti. I do not use frameworks where they can be avoided and write extremely simple code and avoid OOP for scripting. I would not do OOP with a language without strong typing. My take is for short lived HTTP requests which need to spew out some JSON preferably(favor headless coding for frontend), PHP is the apt tool. For heavy lifting, use a strongly typed language which can easily handle complexity.
Do you have an example of a non-trivial project that was written in PHP that is not spaghetti code that doesn't use OOP as it's foundation for organization?
I want to believe that it's possible. When you start introducing even the most basic complexities of a web app (authentication, access control, database connections, reusable CRUD functionality - all the things that make up a non-trivial application) I find it really hard to stay organized in a procedural style.
I'm not being snarky; I'd love to see a good example of this.
When I first encountered the fusebox [1] framework for ColdFusion - that was a bit of an eye-opener for me. I still thunk MVC and derivatives for proper object oriented environments like Smalltalk is superior as a general design pattern, but fusebox is a great match for web development with "template oriented" languages like php and cf. It builds sanely on these languages' strenghts and can be rather plesant to work with.
As a PHP zealot, I'm also really interested in this. I drink the OOP Kool-Aid 100% when I code in PHP since it forces at least some level of structure, but I'd love to see a successful procedural approach.
I believe that Drupal 7 qualifies as a non-trivial PHP application that only uses OO in a minimal number of applications in core (ie, when it's appropriate).
Some would definitely argue that Drupal results in spaghetti code, due to a large amount of module functionality being written in hooks that are invoked to change behavior at runtime. It also has an elaborate theming process that yields many opportunities for module or theme code to modify data as it passes through the layers of data generation, processing, theming, etc.
My personal experience on some large Drupal projects is that with an experienced team that knows "the Drupal way" of doing things, you can write some very well organised code that is easy to maintain and extend. However, I doubt this is the norm with Drupal projects.
I also think that Drupal 8 and beyond will move more and more towards an OO-based methodology, as the learning curve for the current system is very high.
As long as you keep your design to short lived HTTP requests in CRUD fashion - and no deep nesting - It is possible (REST is really procedural in its core). In fact, I would suggest the model for any scripting language. That do not mean you cannot use OOP SDKs for which you can make calls within procedural code. I typically use Java for complex logic which is mostly run as cron/long lived process often with multiple threads. My CRUD files rarely exceed 1000 lines of code and do not do any UI heavy lifting (left to HTML/JS). I use AWS and SDKs wherever applicable to remove heavy lifting from my code and keep things stateless as possible.
In the past 2 years we have developed a Mobile Companion Platform for TV which scaled to many hundred thousand users, a scalable appstore for TV, a Middleware Platform for HTML/Android Set Tops, a mobile Live TV platform and a Campaign Management System for TV. I find it exceedingly difficult to manage and scale containers and would not use them for anything other than strict enterprise stuff.
Our platforms typically have 80-100 CRUD APIs and finish within 10000 lines of PHP with heavy lifting delegated to cloud APIs and Java based crons/long lived processes.
Thanks! We should have some code that can be made open source. Will check if it contains any PHP. Mostly because we work with Businesses and host solutions for them on the cloud, our code base is not yet open sourced. Should try to do that in the future. In the mean time, I would be happy to help out if you have some specific requirement.
Yes, I've built a couple of large PHP applications handing gnarly business logic that did not turn into spaghetti code. The been easy enough to maintain and extend over the years as well. OOP is used for the persistence code only.
The trick to this has been to have minimal code in the MVC layer, and keep most of the logic in functions which are organized in into per topic files.
So when my application wants to find out the price of something, I'll call price($product, $user) from pricing.php, which will then handle all the voodoo business rules about pricing (does the user get a member discount? what kind of discount do they get? do they own a related product? is it Friday the 13th?) price() depends on other functions like has_active_membership() defined in the file about subscriptions, and on membership_discount_pct() in the pricing file.
This function oriented breakdown applies not just to business logic, but authentication, charging credit cards through stripe, sending emails, course status, editing rights, etc.
I deliberately do not use any hooks or other meta chicanery. It's plain functions calling plain functions all the way down.
Comments
I came to PHP after long stint with C, C++, Objective C, Java and Javascript - and I was productive from day 1. I have programmed extensively, and have come across few quirks, but never got stuck, nor is my code spaghetti. I do not use frameworks where they can be avoided and write extremely simple code and avoid OOP for scripting. I would not do OOP with a language without strong typing. My take is for short lived HTTP requests which need to spew out some JSON preferably(favor headless coding for frontend), PHP is the apt tool. For heavy lifting, use a strongly typed language which can easily handle complexity.
Do you have an example of a non-trivial project that was written in PHP that is not spaghetti code that doesn't use OOP as it's foundation for organization?
I want to believe that it's possible. When you start introducing even the most basic complexities of a web app (authentication, access control, database connections, reusable CRUD functionality - all the things that make up a non-trivial application) I find it really hard to stay organized in a procedural style.
I'm not being snarky; I'd love to see a good example of this.
When I first encountered the fusebox [1] framework for ColdFusion - that was a bit of an eye-opener for me. I still thunk MVC and derivatives for proper object oriented environments like Smalltalk is superior as a general design pattern, but fusebox is a great match for web development with "template oriented" languages like php and cf. It builds sanely on these languages' strenghts and can be rather plesant to work with.
1:
http://en.m.wikipedia.org/wiki/Fusebox_(programming)
As a PHP zealot, I'm also really interested in this. I drink the OOP Kool-Aid 100% when I code in PHP since it forces at least some level of structure, but I'd love to see a successful procedural approach.
I believe that Drupal 7 qualifies as a non-trivial PHP application that only uses OO in a minimal number of applications in core (ie, when it's appropriate).
Some would definitely argue that Drupal results in spaghetti code, due to a large amount of module functionality being written in hooks that are invoked to change behavior at runtime. It also has an elaborate theming process that yields many opportunities for module or theme code to modify data as it passes through the layers of data generation, processing, theming, etc.
My personal experience on some large Drupal projects is that with an experienced team that knows "the Drupal way" of doing things, you can write some very well organised code that is easy to maintain and extend. However, I doubt this is the norm with Drupal projects.
I also think that Drupal 8 and beyond will move more and more towards an OO-based methodology, as the learning curve for the current system is very high.
As long as you keep your design to short lived HTTP requests in CRUD fashion - and no deep nesting - It is possible (REST is really procedural in its core). In fact, I would suggest the model for any scripting language. That do not mean you cannot use OOP SDKs for which you can make calls within procedural code. I typically use Java for complex logic which is mostly run as cron/long lived process often with multiple threads. My CRUD files rarely exceed 1000 lines of code and do not do any UI heavy lifting (left to HTML/JS). I use AWS and SDKs wherever applicable to remove heavy lifting from my code and keep things stateless as possible.
In the past 2 years we have developed a Mobile Companion Platform for TV which scaled to many hundred thousand users, a scalable appstore for TV, a Middleware Platform for HTML/Android Set Tops, a mobile Live TV platform and a Campaign Management System for TV. I find it exceedingly difficult to manage and scale containers and would not use them for anything other than strict enterprise stuff.
Our platforms typically have 80-100 CRUD APIs and finish within 10000 lines of PHP with heavy lifting delegated to cloud APIs and Java based crons/long lived processes.
Sounds really interesting. If you have anything open source you can share, I'd love to see it!
Thanks! We should have some code that can be made open source. Will check if it contains any PHP. Mostly because we work with Businesses and host solutions for them on the cloud, our code base is not yet open sourced. Should try to do that in the future. In the mean time, I would be happy to help out if you have some specific requirement.
Yes, I've built a couple of large PHP applications handing gnarly business logic that did not turn into spaghetti code. The been easy enough to maintain and extend over the years as well. OOP is used for the persistence code only.
The trick to this has been to have minimal code in the MVC layer, and keep most of the logic in functions which are organized in into per topic files.
So when my application wants to find out the price of something, I'll call price($product, $user) from pricing.php, which will then handle all the voodoo business rules about pricing (does the user get a member discount? what kind of discount do they get? do they own a related product? is it Friday the 13th?) price() depends on other functions like has_active_membership() defined in the file about subscriptions, and on membership_discount_pct() in the pricing file.
This function oriented breakdown applies not just to business logic, but authentication, charging credit cards through stripe, sending emails, course status, editing rights, etc.
I deliberately do not use any hooks or other meta chicanery. It's plain functions calling plain functions all the way down.