In the business world, there's a significant distinction between a scripting language or not: whether it needs a compiler. This is a very relevant and real distinction for enterprise-scale applications and implementations.<p>Code being in a scripting language means that the "operations" data center folks can tweak and poke it. Need an extra parameter passed in or a magic constant changed? Just do it. But compiled code is no exaggeration often an order of magnitude harder to maintain. A whole chain of change requests must come into being, from whoever found the need back to a "developer" who has the right tools and environment and access to the source and even knowledge of what and where the source is. (We don't see that kind of problem at the scale of a YC startup or a well-managed Google-size tech behemoth, but organizational tech knowledge is a gigantic problem for companies whose primary problem domain is not tech. Like say a bank or medical provider or retailer.)<p>I've written significant amounts of code in SQL stored procedures when C# (we're a Microsoft shop) would be a more appropriate platform, simply because my company's culture is that SQL is accessible and open to the business analysts and managers while C# really has a walled-fortress image. It grates on my sensibilities but "scripting" really does save effort in the long run simply thanks to greater transparency.<p>Back to the original article, it's really just saying that a scripting language has lower barriers to entry and maintainability, which is absolutely true.