I can't even count the number of times I made a short script/tool for some task that could have been accomplished by stringing together some highly arcane command line invocations. Sometimes, I had legitimate reasons for this because the "unix way" had weird edge cases or unwanted behavior. Other times I just felt like it, or I didn't know a viable alternative existed.<p>I remember when I was working on a web server project in the late nineties, one of my first commercial gigs, the whole thing was done in Borland Delphi. As the maintenance programmer came in to take over, he berated me publicly several times for not using regular expressions to do string manipulation. The language did not even have regex support as far as I recall, and as he replaced my very simple and easily-debuggable string routines with absurd regexes in combination with an arcane regex library, I felt like the most worthless programmer ever. Worse yet, people were praising him for his assertiveness and competence. And then following his "refactoring", over the next weeks, horrible string manipulation bugs and exploits started happening in production. Turns out, he introduced lots of problems and nobody could fix them. As far as I know the project was plagued with these kinds of bugs until it went offline years later.<p>The loudest hecklers are often the most successful at projecting an appearance of competence that may not necessarily be warranted. They derive energy and peer recognition from publicly berating colleagues for decisions. Whether they are factually correct or not, little is gained by letting them drag you down.<p>It's not the end of the world. Most of the time, there are many ways to achieve a result in programming. Writing a little script is certainly a valid solution, and if it makes you more productive for doing a specific thing, or even just as a learning exercise, why not?
I feel a little uncomfortable about this being posted again. The whole incident was very unpleasant, but everyone involved regrets it deeply. Steve Klabnik particularly has commented several times how greatly he regrets the role he played in discouraging a fellow programmer (as well as of course making a public apology). He's currently doing an admirable job encouraging newbies and making the Rust community a welcoming place to all. He is the primary author of <a href="https://doc.rust-lang.org/book/" rel="nofollow">https://doc.rust-lang.org/book/</a>, which many of you may have read.
I wonder to what extent the abuse she received was just due to her having used JS. Klabnik and Haines are both huge Rubyists and Rubyists seem extremely hostile to JS and those who use it, probably because of Node.js stealing Rails' (and by extension Ruby's) thunder and a growing awareness that JS has inherent advantages over Ruby for which Ruby will likely be unable to compensate, such as shipping in every major web browser and having a modern, efficient, jitting VM in the form of V8 that's an order of magnitude faster than MRI.
Especially strange because the project in question seems to be pretty simple, useful, and decently documented. It doesn't even seem to be near the "laughable" threshold to me, and I'm a pretty spiteful and cynical person.<p>I have a hunch that maybe some people interpret a GitHub project page as a claim that "this project is amazing and better than other things and you should use it," when actually the only implicit claim is "here's a free thing."<p>A related question has to do with package namespaces, e.g. npm. This project claims the name "replace" on npm. What does that entail? How do we decide if it's a "legitimate" claim? If someone makes another replace utility that's way more sophisticated or beautiful or whatever, should the name be reassigned?<p>Npm has a policy: <a href="https://www.npmjs.com/policies/disputes" rel="nofollow">https://www.npmjs.com/policies/disputes</a><p>Even more abstractly, it's pretty interesting how names, versions, URLs, and publishing becomes an area where "politics" come into play, more than one might expect given the nature of the code artifacts. That stuff brings up all kinds of policies, claims, etc.