4 ms·

But here's the problem: at some point, the user wants the tool to do something beyond what the tool can do. And at that point, the user is stuck. Customer serv

But here's the problem: at some point, the user wants the tool to do something beyond what the tool can do. And at that point, the user is stuck. Customer service recommends posting a feature request in the product forums and all the user can do is wait... and hope something gets implemented that solves their problem, or find a new tool. But with programming, it's possible to execute scripts, make system calls, write to files, and initiate network connections to talk to APIs and invoke other 'tools' to continue the task at hand. The tool is now a shape-shifting collection of code that can take on many challenges, limited only by the creativity of the developer. You can't do that with a WYSIWYG, it would be too complex to allow all these functions, so the next best thing is allowing plugins, at which point the tool now requires programming knowledge anyway.

slantyyz 8y ago
>> But here's the problem: at some point, the user wants the tool to do something beyond what the tool can do. Once again, this depends on the lens you view it with. With any solution that does a good job, it will eventually grow. Sometimes it outgrows what it was already built upon. I see this is as a good problem to have, because it's a validation that the problem was real, and that the solution has value. You can also now justify putting some resources against it. If your starting point is "this problem needs to be solved with programming" and A) you don't have that skill, B) you don't have the money to hire a person to do it, C) your organization isn't willing to give you a skilled internal resource to build it, what are your options? You can either do nothing and live with the problem indefinitely, or you can try to do something that doesn't involve "real programming" to make your life a little easier.
adrianmonk 8y ago
I don't necessarily see that as a problem. When you get to that point, you've proved that this task, whatever it is, was worth automating. You've built a tool and even though it was clunky and limited, people found it useful. So maybe now with that proof that a small investment paid off, it is time to take it to the next level and make a larger investment to do it better with professional grade tools this time. Yes, you have to start over, but if the other alternative was never being able to get to that point in the first place, it's still better overall.
earenndil 8y ago
> But here's the problem: at some point, the user wants the tool to do something beyond what the tool can do. > And at that point, the user is stuck. Customer service recommends posting a feature request in the product forums and all the user can do is wait... and hope something gets implemented that solves their problem, or find a new tool. Is this not the problem with any programming language? It's turing-complete, yet you find something you can't do (I mean, brainfuck is turing-complete, but try implementing a closure in it), you complain to the maintainers, they say it doesn't fit the design criteria. Sure, you might be more likely to fit those limits earlier in a visual code design tool, but that's not a fundamental design limitation, just an implementation one.

slantyyz 8y ago

>> But here's the problem: at some point, the user wants the tool to do something beyond what the tool can do. Once again, this depends on the lens you view it with. With any solution that does a good job, it will eventually grow. Sometimes it outgrows what it was already built upon. I see this is as a good problem to have, because it's a validation that the problem was real, and that the solution has value. You can also now justify putting some resources against it. If your starting point is "this problem needs to be solved with programming" and A) you don't have that skill, B) you don't have the money to hire a person to do it, C) your organization isn't willing to give you a skilled internal resource to build it, what are your options? You can either do nothing and live with the problem indefinitely, or you can try to do something that doesn't involve "real programming" to make your life a little easier.

adrianmonk 8y ago

I don't necessarily see that as a problem. When you get to that point, you've proved that this task, whatever it is, was worth automating. You've built a tool and even though it was clunky and limited, people found it useful. So maybe now with that proof that a small investment paid off, it is time to take it to the next level and make a larger investment to do it better with professional grade tools this time. Yes, you have to start over, but if the other alternative was never being able to get to that point in the first place, it's still better overall.

earenndil 8y ago

> But here's the problem: at some point, the user wants the tool to do something beyond what the tool can do. > And at that point, the user is stuck. Customer service recommends posting a feature request in the product forums and all the user can do is wait... and hope something gets implemented that solves their problem, or find a new tool. Is this not the problem with any programming language? It's turing-complete, yet you find something you can't do (I mean, brainfuck is turing-complete, but try implementing a closure in it), you complain to the maintainers, they say it doesn't fit the design criteria. Sure, you might be more likely to fit those limits earlier in a visual code design tool, but that's not a fundamental design limitation, just an implementation one.