> Eventually you are faced with a task that looks on the surface like the type of task you use tool X for, so you start working. After a while it turns out that

> Eventually you are faced with a task that looks on the surface like the type of task you use tool X for, so you start working. After a while it turns out that it would be best to use tool Y. Now you've wasted a bunch of time using the wrong tool because you used a shortcut to avoid thinking, instead of taking the time to think. I'd caution that for many tasks, using a close enough tool can be good enough, and an experienced user of a "close enough" tool may very well get results rapidly. Regular Expressions are a great example of this. I've done stuff with regular expressions that a proper parser or tool modifying ASTs would be "correct" for[1], and if I learned to use those specialized tools I'd be better off, for that one particular task. But the fact is regular expressions serve to sub-optimally solve a lot of different problems. I'd make the argument that the total time I've spent learning regex's and then solving a lot of problems with them at 80% speed has been a more efficient use of time than if I'd learned a bunch of one off "ideal" tools. [1] I have a ~bad~ habit of generating large repetitive chunks of code using regexs.