3 ms·

Do you "hack" every utility you use? Is that a predicate on you using that utility? Would you not investigate a utility you like to see whether you can easily "

Do you "hack" every utility you use? Is that a predicate on you using that utility? Would you not investigate a utility you like to see whether you can easily "hack" on it or not? (I dislike the term “hack” as it denotes to me irresponsible way to throw code, rather than properly design features and implement them in a considerable manner.) I agree with most of the things you say above, they are very important. I just don't think it should be part of the name and identity of a utility. A tool should not have to scream to the world "I am a fast tool because I was written in C++ and not JS"—that should be a given for every utility.

coldtea 8y ago
>Do you "hack" every utility you use? Is that a predicate on you using that utility? No, but not all the utilities I use are open source either. When they are, and for some domains (e.g cli text manipulation tools and development utilities) I like to be able to hack them, even if I don't, so for that (and for the other reasons) the language they are written in is important to me. I never said it's the sole criterion. >I dislike the term “hack” as it denotes to me irresponsible way to throw code, rather than properly design features and implement them in a considerable manner For deployment code, yes. For utilities, usually that's exactly what I want though: to irresponsibly throw code for my own purposes, when I find it convenient to fix an annoyance or bug in utility I use or add some small feature I want to it.