Plato, Aristotle, and Drupal
Plato invented Object Oriented Programming. And Aristotle invented Functional Programming. And the centuries-long debate carries over into Drupal today.
Plato was an architect. The world, to Plato, was best expressed as an elegant system of well-ordered ideal objects. Motionless and unchanging, these "forms" composed the world of perfection. But when it came to the real world, "runtime" was messy, full of complicated, ugly, and error prone "copies" of the forms.
In contrast, Aristotle saw the world as a dynamic place, a constantly evolving runtime. What makes the world beautiful, functional, and exciting is the dynamic nature of things.
While Drupal has never been (truly) functional, much of our approach has been more inline with functional design than with OO or even standard procedural design. Like Aristotle and LISP programmers, Drupal is about what is happening in the moment. Hooks, callbacks, builders. Drupal takes full advantage of PHP's runtime offerings.
Drupal is caught between our Aristotelian roots and Plato's enticing world of OO perfection. And this is not necessarily a bad thing. As we begin using Drupal 7 in earnest, and as Drupal 8 development hits full stride, we must ask -- and answer -- what kind of philosopher Drupal is.
Speakers
Time slot:
Tuesday 5:00pm-6:00pm
Track:
Drupal community
Experience level:
Intermediate
Questions answered by this session:
How can Drupal's inherent and vibrant dynamic model adapt to Plato's "architect-first" approach? Or should it?
In what ways is Drupal functional? And to what extent should it be?
What are the real debates regarding Drupal's architecture?
Is OOP good for Drupal?
Presentation slides:
Comments
I believe the key reasons
I believe the key reasons Drupal is a popular CMS are?
- passionate and active open source community
- tons of contributed tons of code
- one can take an existing code base core and contrib modules and quickly build a highly functional website using hooks.
(In short we can treat these core and contrib components as OO components)
- we can incorporate our own custom modules (hooks) and customize it to meet the needs of a complex, highly functional custom website.
- we can easily get into the core and contrib module and hack them if desired. Of course this approach should be one of last resort and desperately avoided.
In the long run your code will become incompatible with future Drupal updates..
Some key questions we need to ask is:
1) how will a migration to pure OO alter the behavior of the open source developer community contributions? Will it alter it?
2) will it raise the learning curb and time it takes write and contribute code to Drupal core and contrib modules?
3) will it raise the learning curb and time it takes create custom solutions - "replacing hooks"
From my personal experiences, OO is an investment. You need to take the time upfront to define all your objects, states, etc..
The web in general is very dynamic, need to adapt and change continuously to meet your clients needs and keep up with the trends.
If we loose this capability in Drupal I'm thinking web creators/developers will migrate to some other platform?
These are just my opinions...
Excellent presentation and
Excellent presentation and excellent audience questions. The forelast question made me realize what is my frustration with developing in Drupal 7. You often cannot predict how you should implement a system or feature; can you do X with a hook, or do you need to use entity API, or maybe provide a custom data structure outside of entity API, or maybe you can leverage existing tools e.g. views/feeds/panels or whatever.
This can reduce confidence in the hours you put in your development work and a grand unified system in the form of a design pattern would be a huge improvement.
Or should I say in the ideal of a design pattern.