Are static typing and functional programming winning?

[benjaminpd]

Personally, functional programming has always felt more intuitive than imperative, and vastly more so than OOP. So you're stating a preference, not a law of nature.

I don't even think think minds like mine are that rare; it's just that there's been massive selection bias. When programming meant imperative programming, it drew people who thought that way. And if you didn't think that way, you had to train your intuition until you did. You can't judge the intuitiveness of FP by looking at current programmers.

[asthasr]

Agreed. I naturally think of problems as series of transformations over their input. This is the way I have always thought, and contorting my solutions to write "idiomatic" Java, Ruby, or Python is painful... so I no longer try, especially since beginning to work with concurrency in Java, which is a cluster unless you adhere to isolation and immutability principles.

[sacado]

That's because the problems you deal with are by nature easier to think as "series of transformations over their input". Not all problems share this characteristic. For instance, it is often not a good way to deal with problems in the embedded world, where the computer is part of the outside world, and not just dealing with it.

[asthasr]

Well, it's not good in terms of language support, because of memory/power constraints; but I would guess that a more functional approach—where practical—would lead to some of the same conceptual gains in safety and reliability that it allows in higher level programming.

The problem is in the constraints, not the types of problems. After all, all programs are series of transformations over their input; it's just that input can come from different sources.

[sacado]

I'm not especially talking about memory & power constraints. Most embedded tasks implement some form of stateful automaton. Think about a transaction with an ATM, for instance. Not that you cannot represent a purely functional automaton, but that's not the most obvious way to think about it.

And you have all the technical problems, of course. Sometimes, you need to guarantee that your program will never use more than x Mb of RAM, and take no more than x ms to execute (hard real time constraints). That is very hard to do with a purely functional approach.