[kmiroslav]

Well, you don't get to decide what people find natural, they do.

And deep below, computers work under a model that's anything but functional (assembly language is basically a big mutable state machine).

There is value in understanding both imperative and functional programming and applying each of them wherever they are the best fit and there are some real world situations where sticking to immutability is a terrible choice (e.g. neural networks).

[Koromix]

Programming is about making a piece of hardware do what you want to do. Many people seem to forget that, or treat it as an afterthought. "Oh yeah, it's slow. Hopefully the compiler will do its magic!". Except it does not, because it cannot rewrite your code to match what the hardware wants.

This is why we now live in a world where many programmers don't think there is a problem with running web servers on programming languages that slow down computation by orders of magnitude, in addition to being very cache and memory inefficient. We can scale! Yeah sure, use 50 servers where one could have done it. We would also use Saturn V to launch small individual LEO satellites, you know. Why not? It works!

Taking a functional approach is fine for a lot of tasks, and when you can do it without cryptic or inefficient code, you should do it. But when imperative is easier, use that instead.

[ayberkt]

You seem to have completely misunderstood my point.

> Well, you don't get to decide what people find natural, they do.

I am not contending that functional/declarative is a more natural way to think; I am saying that there is nothing inherently more natural about imperative programming. Since the latter comes from imitating the machine architecture up in the abstraction hierarchy, we should consider for a moment if this is really desirable.

> And deep below, computers work under a model that's anything but functional (assembly language is basically a big mutable state machine).

This is entirely irrelevant. Computers are highly stateful but the languages we design don't have to be stateful because of this. They have to meet the criterion of easily expressing the mental constructions we designate which I would definitely say is much better handled with statically typed functional programming languages.

> There is value in understanding both imperative and functional programming and applying each of them wherever they are the best fit...

We completely agree on this! Not all problems are best solved with functional languages (e.g., things actually involving the machine).

> there are some real world situations where sticking to immutability is a terrible choice (e.g. neural networks).

I don't see why immutability is a terrible choice for neural networks? Could you elaborate on this? It might be that almost all neural network implementations have been imperative so you have come to accept that as more normal.

[kmiroslav]

Typical neural networks have multiple layers of hundreds of thousands of nodes, which then get updated very frequently during the learning phase.

It would be suicidal for these updates to be immutable (e.g. returning brand new neurons with the updated value instead of updating the neuron that's already in the graph).

[tome]

> And deep below, computers work under a model that's anything but functional (assembly language is basically a big mutable state machine).

Acutally, deep below a computer is a massive asynchronous electronic circuit. Your "big mutable state machine" is an abstraction, just like any other.