I used to think that general-purpose technologies would evolve and eventually become superior to their special-purpose counterparts.
Take XSLT for example: Somewhere, sometime, I think I heard that the .NET Framework’s XSLT implementation could generate an in-memory assembly from an XSL transform, that was fully compiled IL code. Given enough optimization, a solution like that should be able to out-perform any manual transformation using XPath and a StringBuilder.
I have since given up that idea.
I don’t think the power of general-purpose technologies is in their ability to solve every problem the best possible way. Rather that they make it possible to data-drive otherwise typically programmatic scenarios, which lends itself well to plugin behavior without compiled code.
Continuing with the XSLT example, consider how relatively easy it is to allow your code to transform an XML document using a user-provided XSL stylesheet, rather than having them implement a separate assembly that you can load dynamically and execute code from.
This is all well, but the reason I bring this up is: unless you need that level of pluggability, hand-crafted code will probably be both faster and easier to maintain and test.
General-purpose technologies such as SQL and XML sometimes seem so prevalent that using them just seems natural. But sometimes, maybe it’s better to use alternative technologies or, for that matter, roll your own.
I’ve been lured into the web (no, not the web) of general-purpose stuff too many times without proper evaluation, that I need this as a reminder for myself:
Never introduce a dependency on a general-purpose technology until there is no way around it.
This is neither politically correct nor an accepted best-practice, so when in doubt, it’s probably safer to disagree with me.