“Mostly functional” programming does not work

- lazy evaluation with side effects - replacement optimisations based off of referential transparency when there are side effects - general side-effectiness

This is basically saying that functional programming doesn't work when it isn't functional... but we can still have functional "chunks", and monads _are_ an effect system.

I don't really understanding what he's trying to prove, of course purely functional semantics fall apart when side effects are introduced.

Pure functional programming is programming with mathematical functions. ... Calling a function with the same arguments will return the same result every time.

That leaves a whole lot of other functions, the non-mathematical ones, the real-life ones where you read files or I/O or user input out of the "Pure" definition, if I understand it correctly that is. And by that logic, means '"Pure functional" programming does work, but only if...'. Or, in other words: '"Pure functional" programming does NOT work in real-life software'

Edit: I see there are quite a few. Please tell me about one :)

In some ways the reason it isn't used a lot is for historic reasons as much as anything else. Functional programming, for a long time, was seen (often rightly so) as more computationally expensive than the same imperative code for most tasks. For a long time, that meant that you weren't going to use functional programming: when every single byte and cycle matters, you're going to go with assembly or whatever is closest to it/translates really well to it. (e.x. C)

We now live in a world with abundant memory and excessive unused clock cycles. If I remember correctly, there's also been a good bit of research and work in the last 20-30 years The historic reasons for not using functional programming are gone for many (but definitely not all; people still hand roll assembly, too) of the original use cases. However, you then have 30+ years of programmers who were largely trained in and almost exclusively used imperative languages over the course of their career. That kind of market share is hard to compete with (because it's similar to market share; if everyone is using imperative languages, you need to be familiar with them too if you want to stay in most parts of the industry), and is self perpetuating (if you want to work in CS, you're going to need to know imperative languages for most jobs).

I'm also fairly certain there's a good number of useful, reuseable programs that're written in functional languages, but I'm in an airport and nothing immediately comes to mind.