I'm really fat-- there's no way to sugar coat it (if you did, maybe you'd expect me to eat it). I'm at the SF Drupalcon, which means I am carting my digital essentials: a laptop, a power strip and a SLR digital camera, all wrapped in a bike bag and associated with some hard won swag (oh, hosting? tell me more! [reaches for t-shirt]...).
As a fat man the last thing I need is luggage-- it is literally more to lug around. If anything, I need less-- like no laptop bag and some subspace generator that weighs me in at a feathery 160 lbs.-- so that I can move around best.
I came to this epiphany today and then an hour later, Dries Buytaert gave his inspiring key note address. In looking ahead to Drupal 7, he said that it will have more code (read: poorer performance) but be more scalable. That's great... er, sort of. I remember Steve Ballmer talking about how his staff would boast about kloc-- 1000 line blocks of code. The more klocs you wrote, the better you were at programming. This is why Windows 3.1 went from humming a 486 with 64MB of RAM all the way to needing 1GB+ on a screaming machine to run Vista. More lines may be the only solution to some problems, but sometimes the bulk happens for its own sake.
If the code is too bulky it brings in too much overhead before you get to the real source of overhead: content and data relationships.
Drupal needs to make a left turn in its bulking trend. Drizzle is an example of how to go. Drizzle is a fork of MySQL made to be more modular and strip out extraneous code. Most coders pride themselves on how much work they as reflected in their volume of code. Drizzle is priding themselves on how much code they have taken out. They have removed thousands of lines of code. There are data types that no one uses, so Drizzle doesn't have them. Pressflow is a distribution of Drupal 6 that gets rid of the fringe code that is meant to satisfy PHP4 pecadilloes. It has less code which makes it faster and more scalable. It does backport advantages of Drupal 7 and share its own advantages into Drupal 7.
How do you do complex stuff in a potentially free form way without requiring alot of code? That's the devil in the details. Some ideas:
Context: Factor in context to simplify the data set. I hit the url path functions and was amazed that it searched for all matches and never brought arg(0) into the mix as a way to pre-filter the results.
Make Your Function Respond Like a Good Witness: Have you watched those courtroom dramas where the witness volunteers information and suddenly gets implicated in a murder? Less is more. When you look at the node object in Drupal 5 and 6, it brings in the data in many ways repeated off of several trees. That's a lot of bulk to move around and traverse. If the output is just what you expect then you don't have excess to trim, ignore or suffer with. Functions needs to be able to give what is required and have some extensibility capacity.
Lean of the Language and the Environment: Waaay back in Drupal 4.7 we had a glitch in CCK. I leaned on a PHP function to mend the problem-- easy problem to solve with an easy and solid function. . Like a good Drupaller, I suggested the change as a patch. I was scolded by the maintainer that I should not use a PHP function to resolve this function. WTF? I can't use PHP in Drupal? I understand the logic and the strength of abstracting the mysql_fetch_row() but some functions do not need abtraction-- they work fine. In some cases, there is road that does not need to be re-paved. Adding more functions to repeat the work of what is natively available in PHP or MySQL bulks up the Drupal code and will impact performance. It will give the fat man too much luggage.
Looking at Drupal 7's projected big red bar to indicate its code size, I am concerned how much luggage it going to get carried around in the next version.
As a fat man the last thing I need is luggage-- it is literally more to lug around. If anything, I need less-- like no laptop bag and some subspace generator that weighs me in at a feathery 160 lbs.-- so that I can move around best.
I came to this epiphany today and then an hour later, Dries Buytaert gave his inspiring key note address. In looking ahead to Drupal 7, he said that it will have more code (read: poorer performance) but be more scalable. That's great... er, sort of. I remember Steve Ballmer talking about how his staff would boast about kloc-- 1000 line blocks of code. The more klocs you wrote, the better you were at programming. This is why Windows 3.1 went from humming a 486 with 64MB of RAM all the way to needing 1GB+ on a screaming machine to run Vista. More lines may be the only solution to some problems, but sometimes the bulk happens for its own sake.
If the code is too bulky it brings in too much overhead before you get to the real source of overhead: content and data relationships.
Drupal needs to make a left turn in its bulking trend. Drizzle is an example of how to go. Drizzle is a fork of MySQL made to be more modular and strip out extraneous code. Most coders pride themselves on how much work they as reflected in their volume of code. Drizzle is priding themselves on how much code they have taken out. They have removed thousands of lines of code. There are data types that no one uses, so Drizzle doesn't have them. Pressflow is a distribution of Drupal 6 that gets rid of the fringe code that is meant to satisfy PHP4 pecadilloes. It has less code which makes it faster and more scalable. It does backport advantages of Drupal 7 and share its own advantages into Drupal 7.
How do you do complex stuff in a potentially free form way without requiring alot of code? That's the devil in the details. Some ideas:
Context: Factor in context to simplify the data set. I hit the url path functions and was amazed that it searched for all matches and never brought arg(0) into the mix as a way to pre-filter the results.
Make Your Function Respond Like a Good Witness: Have you watched those courtroom dramas where the witness volunteers information and suddenly gets implicated in a murder? Less is more. When you look at the node object in Drupal 5 and 6, it brings in the data in many ways repeated off of several trees. That's a lot of bulk to move around and traverse. If the output is just what you expect then you don't have excess to trim, ignore or suffer with. Functions needs to be able to give what is required and have some extensibility capacity.
Lean of the Language and the Environment: Waaay back in Drupal 4.7 we had a glitch in CCK. I leaned on a PHP function to mend the problem-- easy problem to solve with an easy and solid function. . Like a good Drupaller, I suggested the change as a patch. I was scolded by the maintainer that I should not use a PHP function to resolve this function. WTF? I can't use PHP in Drupal? I understand the logic and the strength of abstracting the mysql_fetch_row() but some functions do not need abtraction-- they work fine. In some cases, there is road that does not need to be re-paved. Adding more functions to repeat the work of what is natively available in PHP or MySQL bulks up the Drupal code and will impact performance. It will give the fat man too much luggage.
Looking at Drupal 7's projected big red bar to indicate its code size, I am concerned how much luggage it going to get carried around in the next version.
Comments