4 ms·
I was a Drupal developer for a year or so. That was at the end of my stint as a PHP developer, and presaged the end of my use of PHP as a language, and my intr
by ddellacosta 14y ago
I was a Drupal developer for a year or so. That was at the end of my stint as a PHP developer, and presaged the end of my use of PHP as a language, and my introduction to the larger world of software engineering.
Thinking about it now, I'm really not sure what Drupal is good for. All in all it is a pain-in-the-ass to work with. Having switched to Rails after that (and please don't get me wrong, I'm not trying to insist that Rails is the be-all-end-all, but for the sake of comparison...), I know now that the same amount of development time in Rails can yield far greater results, despite the fact that you can essentially build functionality through a GUI in Drupal--a GUI which is as incomprehensible as the codebase is. This is something the author of this piece acknowledges when he talks about trying to customize Drupal.
This has to do with two things, I feel. One is that, fundamentally, Ruby is a more expressive language than PHP, and you can accomplish a lot more with less code. I say this not to start a language war but simply because I think it is true--the same way I feel that Lisp is more expressive than Ruby by a significant factor.
The second, and much more significant reason, is that Drupal doesn't have any sort of sane architecture to let you safely plug in modular code. You are essentially hot-loading code into arbitrary points within the system. Frankly, it suffers from the same problem a lot of PHP apps do (and more Ruby and Python apps than many of us would care to admit) which is that it's people re-inventing the wheel from the ground up, all over again, poorly. The fact that they are now talking to the Symfony guys about putting some of those ideas in place suggest to me that someone on the Drupal team finally realized MVC exists. I have this vision of someone in the PHP community at some point randomly picking up the Gang of Four book and being like "holy shit, check this out people...they had a solution to some similar problems 20 years ago..."
I'm joking a bit...but after years and years doing web development, I only finally realized the whole world of software engineering that was out there, and how out of the loop I truly was (and still am). Many developers exist in a little bubble consisting only of their language or worse, their platform. The Javascript folks, Rubyists and Pythonistas (fill in your favorite language/platform here I suppose) can all suffer from this.
Point being, any of us who consider ourselves "software engineers" should be constantly reviewing our own skill set, and while we should certainly be refining our skills in our particular language(s) and toolsets of choice, we should also be constantly reviewing other languages and ways of thinking about architecting software for guidance, inspiration, and to combat our own tendencies towards small-mindedness. We should be refining our knowledge of algorithms and comp sci fundamentals if we are lacking (as many web developers are, especially self-taught ones).
After all, "those who don't know history are destined to repeat it." This is just as true--if not moreso--in software engineering as it is in any other discipline or domain.
- mylittlepony 14y agoThese stupid generalizations about PHP devs have to end some day, right? Symfony2 (as example) is a piece of software that is probably light years away from anything you have done in software engineering. And its community is way better both in knowledge and openness than the Rails one (I've been a Rails dev too, and have my own rants to make, but I don't go around saying Ruby devs are all noobs) IMO. Yet here you are, making generalizations based on having written code in plain php, working in a piece of software that I don't even know when it was created, but I guess it was here before we even started programming. And for the sweet downvotes, I'll just drop this here: Tell me more about how you read the GoF book, and applied the patterns in a language that does not even have interfaces or type-hinting. What a joke. On a recent article, another "Ruby expert" (who writes and sells programming books) was shocked by the fact that you can reuse code with inheritance. You should read it.
- pretoriusB 14y ago>Tell me more about how you read the GoF book, and applied the patterns in a language that does not even have interfaces or type-hinting. What a joke. I don't see any joke. Jokes are of the type "Knock knock, who's there", etc. Using GoF patterns in a language without interfaces or type hinting? Not so much. Most of the design patterns can be applied in any language, some languages even have inherent support for some of them. Not much to do with types or interfaces (besides them offering extra checks). Facade, Decorator, Flyweight, Iterator, Proxy, etc... Equally at home in Java, C++, Smalltalk, Python or Ruby... >On a recent article, another "Ruby expert" (who writes and sells programming books) was shocked by the fact that you can reuse code with inheritance. You should read it. I guess you are referring to this: http://clayallsopp.com/posts/the-story-of-pull-request/ http://clayallsopp.com/posts/the-story-of-pull-request/
- strlen 14y ago>Tell me more about how you read the GoF book, and applied the patterns in a language that does not even have interfaces or type-hinting. <tongue in cheek> If you're interested in examples of GoF patterns implemented in a language without typehints or interfaces, I highly suggest getting ... the GoF book -- it has examples in Smalltalk! </tongue in cheek>