Re:Drupal's Golden Handcuffs
by berkes on Thursday October 04, 2012 @12:43PM
(#4613140)
I think author is switching cause and effect:
Move a few paragraphs around and the problem becomes clear. It is right in his article!
> Drupal just isn't a great system to code for.
And then
> No debugging your custom code
Proper, well architectured custom code is not hard to debug. At least not anywhere near as hard as debugging Drupalcode. Due to, yup "Drupal just isn't a great system to code for."
> No digging through the docs trying to find the API function you need for an odd task
"Drupal just isn't a great system to code for."
> A discoverable UI--click around until you find what you're looking for, rather than digging through code
Hmm. there is a pattern here: "Drupal just isn't a great system to code for."
> A team of thousands of users and contributors testing the code in ways you never would have imagined and fixing the bugs
Klicking Monkeys testing stuff? Where are the unit-tests? CI? They are there, somewhere in Drupal, but in reality unusable, because, yup "Drupal just isn't a great system to code for."
> A much much smaller risk of security breaches due to that team
Well, to an extend. But the most security comes from your arcitecture. And 90% of the Drupal-security-anouncements can be tracked back to, yup "Drupal just isn't a great system to code for.".
> Holy crap, so much faster
Yes. Faster then coding. But that is only true for Drupal, because, "Drupal just isn't a great system to code for.".
It certainly is not faster then your average RAD-framework for many, many sites. There may be some cases where Drupal is faster, but only when you don't have to write a line of code, nor need to debug and find why Module Foo and Bar don't work together, because.. well. See above.
Move a few paragraphs around and the problem becomes clear. It is right in his article!
> Drupal just isn't a great system to code for.
And then
> No debugging your custom code
Proper, well architectured custom code is not hard to debug. At least not anywhere near as hard as debugging Drupalcode. Due to, yup "Drupal just isn't a great system to code for."
> No digging through the docs trying to find the API function you need for an odd task
"Drupal just isn't a great system to code for."
> A discoverable UI--click around until you find what you're looking for, rather than digging through code
Hmm. there is a pattern here: "Drupal just isn't a great system to code for."
> A team of thousands of users and contributors testing the code in ways you never would have imagined and fixing the bugs
Klicking Monkeys testing stuff? Where are the unit-tests? CI? They are there, somewhere in Drupal, but in reality unusable, because, yup "Drupal just isn't a great system to code for."
> A much much smaller risk of security breaches due to that team
Well, to an extend. But the most security comes from your arcitecture. And 90% of the Drupal-security-anouncements can be tracked back to, yup "Drupal just isn't a great system to code for.".
> Holy crap, so much faster
Yes. Faster then coding. But that is only true for Drupal, because, "Drupal just isn't a great system to code for.". It certainly is not faster then your average RAD-framework for many, many sites. There may be some cases where Drupal is faster, but only when you don't have to write a line of code, nor need to debug and find why Module Foo and Bar don't work together, because.. well. See above.