All of your points cover the code you write too, except possibly for the intimate understanding of the guts of the code. Thus I cancelled them out in the equation.
My core business isn't writing a templating system. It's writing and editing technical documentation. Thus it's a risk for me to write a templating system. However, part of producing technical documentation is managing and presenting and encoding and formatting text appropriately, so when it came time to produce attractive, well-formatted output, I faced a problem in which (I still believe) creating my own translation utility was the right solution, even though others exist.
I don't particularly want to support it (I wish someone else did), but I understand it and now it exists and I can add features if and when I need them. However, a short period of time into my experiment revealed that I really don't want to write, port, or refine a linebreaking algorithm. Thus I rely on someone else's. It's not perfect, but I have confidence that building on that core will be much easier than reinventing that work.
It's just a matter of what's important. It's really difficult for me to believe that, over time, building your own mini templating system will really pay off. I could be wrong. Like I said, it's not my decision and I definitely know very little about your environment... but I do like to think I understand some of the risks of writing and maintaining software.
In reply to Re^5: RFC: Templating without a System
by chromatic
in thread RFC: Templating without a System
by shmem
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |