I don't buy that "shepherding" is a strong inherent quality of a language, except in the negative sense that a language can make a particular style of programming impractical, and I don't buy that calling for "discipline" in a language is a denial of its inherent nature. "Discipline" boils down to acceptance of the lessons of experience, and it becomes easier over time.<p>Around the turn of the century, Java seemed to require a lot of "discipline" because the people who were embracing OO at the same time they were embracing Java did all kinds of stupid things. They created deep object hierarchies with unnecessary layers and strained relationships, and their systems were slow because simple operations like formatting a date required ten different object allocations and acquiring a mutex lock or two. The GoF patterns book, a good and well-intentioned book, was co-opted as a kind of extremist OO programming handbook, so that if you got stuck trying to apply OO to a problem, you could always find a way to move forward by adding <i>even more OO</i>. Languages like Java enabled this (some said encouraged it) and a lot of people thought it was impossible for programmers to rein in the tendency for Java codebases to blow up with OO excess. Meanwhile, a lot of fanboys thought that OO shouldn't be reined in, that the way out was through, and they doubled down on their principles.<p>In other words, OO was the hot new thing, and early adopters using OO languages like Java had a tendency to spiral into an OO frenzy that created ridiculously convoluted codebases and slow, complex systems.<p>But this wasn't inherent to Java. It was a combination of Java's ability to write that kind of code, along with a naive zeal for exploring the kind of solutions you could build using inheritance-based OO. Even the fanboys warned that you could, if you weren't sufficiently dedicated to OO principles, write procedural code in Java, putting your logic in static methods and your data in behavior-free, non-encapsulated record-style classes.<p>Twenty years later, we no longer think of Java as a language that infects people with an insatiable desire to create inheritance spaghetti, which they can only resist through discipline. It selects for people who are infected with that desire, sure, but an average programmer coming to Java will be leery of building complex inheritance hierarchies and using inheritance to solve problems it isn't well-suited for. It isn't discipline any more; it's just something people know to do, for their own sake. Building deep inheritance hierarchies and FactoryFactoryFactoryFactories is foolishness, not the one natural way to use Java.<p>Right now, I think something similar is happening in functional programming. I wouldn't be surprised if every fundamentally new programming model suffers from the same growing pains, until the lessons are learned, blind optimism becomes educated appreciation, the zealots are forced to find something else to be fanatical about, and we no longer say it takes "discipline" to avoid the pathologies but merely an awareness of what has been learned from past mistakes.