| 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. |
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).