|
I'm having a bit of cognitive dissonance here. I've also been following recently the release of a new programming language, "go" by several of Google's best and brightest. Many people are in an active debate over their design choices. This isn't "please add this feature" but rather a spirited discussion along the lines of "if you could pick seven tools for your toolbox, what would they be?" There's an art to making a design both simpler and more powerful at the same time.
Now imagine what those seven tools would be if instead they were chosen by lawyers worried about liability.
I've been getting this nagging sense for years that SD! is intentionally limited in its interface for the sole reason of minimizing support issues. For example, I spent good money on an inferior sync program to back up one folder to another, because SD! only backs up volume to volume. How many thousands of dollars did other people like me spend on a redundant application, for the same reason? But SD!'s command line tool SDCopy that carries out the actual copying is able to back up any folder to another folder. What is the rationale for locking users out of this functionalilty?
So if SD! were the "go" language, hoards of people would be observing that if one option besides "ignore" was "preserve" (leave alone existing folder, neither delete nor copy), then the logical reach of SD! scripts (in the sense of possible boolean expressions) would be greatly magnified. And the authors would be very curious to hear this.
Why do I feel you have no interest in fixing this bottleneck on SD!'s reach? It isn't feature creep, it's picking seven tools for maximal utility.
|