Live data from Hacker News

Drupal's Golden Handcuffs

mikecr.it

141–148 of 148 posts

Re: Drupal's Golden Handcuffs

#141

Earlier quoted context omitted.

I'm not going to claim up-to-date in-depth knowledge of the PHP ecosystem since my daily work ended in the 4/5 transition era, 6 years ago. So PHP is loads better, I'm sure, but I've seen the announcements of new features such as namespacing and closures, and it's clear that this stuff is shoehorned into the language and good use of these features is not ingrained into PHP culture. In the case of rails, beyond the ea…

> and it's clear that this stuff is shoehorned into the language and good use of these features is not ingrained into PHP culture. Every major PHP framework uses both namespacing and closures. > The ruby OO model with its mixins, implicit metaclass (eigenclass), and dynamic nature (ie. class definitions are just executable code), and standard functional features like lambdas w/ closures are all designed into the lang…

> Every major PHP framework uses both namespacing and closures.

No True Scotsman argument.

> The PHP OO model is more traditional and Java-like, but that doesn't implicitly make it worse or behind the times.

I don't care for fashion, so "behind the times" is neither here nor there, however a Java like OO model is definitely worse on most axes except foot-shooting and style-uniformity for large teams. If I want strong typing I want a system that leverages its power such as Haskell, not something like Java where compilation errors are mostly trivial things and I still end up with null pointers all over the place which is exactly the same as the most common type of error in more powerful dynamic languages. Beyond that, saying PHP OO is like Java is doing PHP a huge service because Java started out as OO with quite a strong vision. It may not have been perfect, and it's certainly developed its warts over time, but the seed of conceptual integrity in Java's OO is an order of magnitude more robust than PHP's.

> I can't speak for the Ruby side, but on the PHP side you couldn't be more wrong.

I was specifically making a comparison between PHP and Ruby. Making a one-side claim is a nonsensical response.

Re: Drupal's Golden Handcuffs

#142
post #129

Earlier quoted context omitted.

Not really, a CMS is good because you don't have to build the same thing multiple times. However, if you plan on using a CMS as a tool to create solid, scalable, efficient applications, you will need to understand how to use the CMS properly. Many times that means understand what the CMS is doing behind the scenes. Any good programmer should be able to code a project like Drupal, granted that would take time, but the…

You're confusing Drupal with a CMS. It's much more, and less.

I'm not confusing it with a CMS at all, it is a CMS. You can use it more as a framework, but as a framework it really kind of sucks when compared to Code Igniter or zend, or even Yii.

Re: Drupal's Golden Handcuffs

#143

Earlier quoted context omitted.

> and it's clear that this stuff is shoehorned into the language and good use of these features is not ingrained into PHP culture. Every major PHP framework uses both namespacing and closures. > The ruby OO model with its mixins, implicit metaclass (eigenclass), and dynamic nature (ie. class definitions are just executable code), and standard functional features like lambdas w/ closures are all designed into the lang…

> Every major PHP framework uses both namespacing and closures. No True Scotsman argument. > The PHP OO model is more traditional and Java-like, but that doesn't implicitly make it worse or behind the times. I don't care for fashion, so "behind the times" is neither here nor there, however a Java like OO model is definitely worse on most axes except foot-shooting and style-uniformity for large teams. If I want strong…

>No True Scotsman argument.

Kind of, but not really. The two major framework players in the PHP space right now are Zend Framework 2 and Symfony 2. This isn't really a "No True Scotsman" argument because both are headed up by reputable development shops (Sensio and Zend). Both use namespaces.

> I don't care for fashion, so "behind the times" is neither here nor there, however a Java like OO model is definitely worse on most axes except foot-shooting and style-uniformity for large teams. If I want strong typing I want a system that leverages its power such as Haskell, not something like Java where compilation errors are mostly trivial things and I still end up with null pointers all over the place which is exactly the same as the most common type of error in more powerful dynamic languages. Beyond that, saying PHP OO is like Java is doing PHP a huge service because Java started out as OO with quite a strong vision. It may not have been perfect, and it's certainly developed its warts over time, but the seed of conceptual integrity in Java's OO is an order of magnitude more robust than PHP's.

Err, what? I'm not sure if I'm misunderstanding you here -- because PHP didn't have OO designs early on somehow that makes it's OO model less robust then Java's? I'm not going to bother arguing that point, but it certainly doesn't make me a less efficient developer. PHP's OO model is more than adequate for most web applications. I'm also not following the null pointer issue. Proper unit testing should vet null value issues out whether you're using a dynamic language or not. PHP has the (arguable) advantage of not completely shutting down when this mistake occurs.

> I was specifically making a comparison between PHP and Ruby. Making a one-side claim is a nonsensical response.

Not anymore of a one-sided claim than your own. You haven't done a lot of research into what's going on in the "popular open source PHP code" if you think your opinion is two-sided -- I'd strongly challenge you to point out what popular modern open source PHP code is inferior to popular modern open source ruby code.

Re: Drupal's Golden Handcuffs

#144
...note... After Mike published the "Golden Handcuffs" post he publicly stated that he did not intend it to be so negative. [yah... I've been there. I start typing and my passion pours out and all the sudden I'm fire up like crazy] So I hope my criticism of this article is pointed in the right direction. ... here goes....

I can not begin to state how much I disagree with the conclusion of this post by @mcrittenden . I believe he feels the way he feels. I believe he has experienced what he says he experienced. But the conclusion is not a typical one. Most of us who are making tremendous earnings in Drupal are NOT bored, unchallenged and lamenting the lack of fun and elegance of coding. We are excited, challenged, evolving, stretched ppl who are having a blast with what we believe to be the BEST community associated with the BEST software out there. [yah... we're pretty biased but THAT is the enthusiasm you run into on a large scale]

I am not saying that he's lying. I believe he is telling the truth when he says he's bored and unchallenged and despises the lack of elegance. I liken that to some one who really misses their horse after trading it in for a Model-T. I get it. We did just find for a very very long long time with the horse. Horses are still used today and not just for entertainment but for very real and practical reasons. There's simply NO WAY that some one is going to have a relationship with a car in any similar manner that they did with their horse. I fully respect @mcrittenden and his position here. When ever some one goes on a rant about what they don't like about Drupal [and OH how often this happens!] I find that many of the points are valid and I can not write them off and dismiss them out of hand. Such is the case here. I will say this.... Drupal is a career and a discipline and a community. I encounter some of the same challenges that @mcrittenden does. I don't have the same reaction. I get better and better at this and I have many friends who I can reach out to. Whereas shops have a lot of BRAIN POWER in-house, we independents stick together and hit each other up with those WTF moments. Between all the DrupalCamp, DrupalCons, local UserGroups, Internet Relay Chat, Skype, Email... I'm very connected to the community and I get answers to my questions when ever I need them. If I know an area of development is going to be extra challenging.. I will factor in some room to pay my friends who know things I do not. Yah... We get freebys from each other ALL THE TIME but I really love it when I tell some one I have a couple hundred bucks to spend on them to teach me something or to architect a solution. I've even spent thousands like this before. I knew the client had needs and I connected them with another shop to handle a very specific piece of the puzzle. It worked well for all concerned. And by the way... this was FUN and Challenging and the solution was very Elegant.

CONCLUSION: I DEFINITELY run into issues with Drupal from time to time. Just like sharepoint and vignette and ez-publish and auto-mechanics and horse-handlers do. My reaction is a little different. I have made the choice long long ago that DRUPAL is my vehicle. I don't want to use Joomla like I used to. I don't want to use Sharepoint like I started to and was studying in 2007. I chose Drupal. Now that I have made that choice I am enjoying great money and great challenges and an even greater community. Our system has its quarks; some are minor and some not so minor. Regardless, this is the path I'm on. We, the community, are continuing to improve "this area" and "that area" and yes I'll even agree that some areas are getting a little worse with each release. This is no secret and I'm part of two different teams that are assessing the situation and proposing action and then encouraging and seeking funds for that re-action. We're seriously on a roll here with this stuff.

@mcrittenden I get it, man. This stuff [called Drupal] can ROYALY piss a guy, or gal, off at times. But what you describe as boredom and click monkeys is a drastically inaccurate description of what I, or anyone I know, do for a living. I do know of many HOBBYIST Drupalers who just want to point and click and they are using Drupal as an overgrown geo-cities but I know that's not who you're talking about here.

I really appreciate the article! This global conversation is sparking other conversations that are enacting change! So.. THNX!

Doug Vann [Drupal Trainer, Consultant, Developer] http://dougvann.com

Re: Drupal's Golden Handcuffs

#145
post #25

I would add this to the complaints: - NOT AMENABLE TO SOURCE CONTROL Half the code lives in the database, configuration is all mixed up with content, and there's no reliable programmatic way to extract it. It makes doing deployment a nightmare. And the worst part? Drupal developers by and large have such a narrow range of experience that they don't even know what they are missing. They have no idea what good coding s…

Right you are @tedsuo There are many ppl not writing tests and not using staging and best deployment practices. This is true in every CMS and WCF. I don't believe it it any more prevalent in Drupal than anywhere else. Drupal invites a lot of BEGINNER types to the arena of web solutions. As such you will certainly find the things you mention.

I don't agree with your suspicion that big shops are hacking core and building custom CMSs upon Drupal in a vain effort to try and gain source control features. Rather... I'm aware of big shops sticking to Drupal bets practices and using Features, Strongarm, Plumber and other modules to get configuration into code and keep it source controlled.

If Drupal deployment were the nightmare you s=describe, then the phenomenal adoption of Drupal that we see today would make no sense. Why would the Georgia Tech Authority decide to move SIXTY-FIVE sites off of a Oracle, Java, Vignette solution and onto Drupal? Well.. It is isn't because they like nightmares during deployment.

Drupal is growing up. The issues that plagued us 5 years ago when I got involved are being solved with varying degrees of success and effort. We're not where we want to be but the market is eating us up. We are bullish about our future and know that out continued improvement will only serve to better our position as the leader that we are in the web space.

Doug Vann [Drupal Trainer, Consultant, Developer] http://dougvann.com

Re: Drupal's Golden Handcuffs

#146
the article refers to being bored. any drupal dev who is bored because they are talented and unchallenged should be contributing to core development. the OPs d.o profile shows contribution but not focused on a particular core initiative. the employer could be giving time over for that. contribution is satisfying and challenging. and much needed!!

Re: Drupal's Golden Handcuffs

#147
the article refers to being bored. any drupal dev who is bored because they are talented and unchallenged should be contributing to core development. the OPs d.o profile shows contribution but not focused on a particular core initiative. the employer could be giving time over for that. contribution is satisfying and challenging. and much needed!!

Re: Drupal's Golden Handcuffs

#148

Earlier quoted context omitted.

Drupal developer with 4+ years of working with it under my belt. The nitty gritty is that we use it in an environment where we basically have 2 teams. One that builds custom code/modules that can be installed and enabled in Drupal to add additional functionality and another that actually deploys sites. The team that deploys sites is savvy, but are not hardcore developers. The thing I've come to over all these years i…

The problem with this approach is later on when the user wants things which don't fit in with the Drupal system, modifications can be a real pain, and the site can become more and more brittle over time. Let's take another real-world example: 1. The client wants a google map of all their content 2. The client wants the content displayed elsewhere too 3. The client wants to filter the content by type 4. The client wan…

The same can be applied to Rails (let's compare to it) too: 1) You're at the mercy of the gem developers and Rails changes versions faster than Drupal, breaking backwards compability. 2) Number of gems also does have an influence on Rails app performance, at least on an app's startup time.
Post reply on HN