Anyone who groups CoffeeScript and HAML into the same rhetorical category is plainly oversimplifying and really only positing an argument against the general us

Anyone who groups CoffeeScript and HAML into the same rhetorical category is plainly oversimplifying and really only positing an argument against the general use of abstractions. HAML is so dead simple that if it takes your engineer more than a day to grok it, you have to admit that they're probably not yet cut out for anything but a junior role. HAML has zero debugging overhead because it's not a programming language; it's just not that hard, period. HAML does add an extra step to the build process, but who cares? It's trivial. In a world where CI and single command deploys are commonplace, the idea that an extra build step would prohibit the use of any developer tool seems absurd. It reminds me of people who argue against unit tests because "ugh, just another tool to learn", or "I end up writing more code in tests than actual code, I just want to ship". God forbid you actually have to learn something. While we're at it, please avoid the use of languages that compile to machine code because who the hell wants to deal with a linker in their build process? Now, although I'm a huge CoffeeScript fan, CoffeeScript is an entirely different beast, and requires a deep understanding of JavaScript to use correctly. I can understand not wanting to devote time to teaching engineers about the finer nuances of CoffeeScript, especially if they aren't that experienced with JavaScript to begin with. In an ideal world, they'd pick up CoffeeScript as quickly as HAML since in my experience, CoffeeScript creates very readable code, especially when the script makes heavy use of anonymous functions, sadly, it's not always that simple. However, CoffeeScript debugging is a non-issue for an experienced JavaScript developer, CoffeeScript produces excellent JavaScript code that is easily understood. Individuals who like to minimize context changes can use sourcemaps. Finally, dependencies for both tools are pretty trivial. I'm not sure how the author has managed to introduce 100 different gems into his project in order to support these tools, but it's certainly not a requirement. https://github.com/haml/haml/blob/master/Gemfile https://github.com/haml/haml/blob/master/Gemfile That's like 4 gems for HAML. CoffeeScript is often distributed as a binary, so zero gems required in that scenario. All in all, I'd say the author's case against these tools is pretty weak.