> 100% pure functional programing doesn’t work. Even 98% pure functional programming doesn’t work. But if the slider between functional purity and 1980s BASIC-s

> 100% pure functional programing doesn’t work. Even 98% pure functional programming doesn’t work. But if the slider between functional purity and 1980s BASIC-style imperative messiness is kicked down a few notches — say to 85% — then it really does work. You get all the advantages of functional programming, but without the extreme mental effort and unmaintainability that increases as you get closer and closer to perfectly pure. This is how we (try to) write code where I work. Pure algorithms, immutable data types, single point of change. D is pretty good for this, but could be better; ranges allow you to be pretty expressive when composing operations, but immutable types have a lot of problems still. It actually combines well with OOP. We tend to mostly use classes to group methods and express domain dependency, rather than manage a tiny state subset. So in maybe half to two thirds of our classes, all the fields are set once on startup and then never changed again.