Functional programming addresses this by eliminating mutability, but at the cost of losing many valuable algorithmic approaches. (The "quicksort" example usually used to illustrate Haskell doesn't perform a true quicksort and is horrendously slow).
Rust deals with it by eliminating sharing via its affine type system. I have only just started exploring Rust but I'm very impressed, it seems the perfect blend of theory and practicality so far.
It's also mostly straightforward to implement a fast Quicksort using mutable arrays in Haskell.
The difference is that all that stuff is formulated within a theory based on pure evaluation of functional expressions.
Loosely speaking it's like how the math that physics uses doesn't have mutable variables, but it still manages to express time varying phenomena...
Do you know of one? All the fast array-based quicksorts I have seen in Haskell have been very awkward compared to implementations in imperative languages with good array support (and they have been quite slow as well).
I don't feel like this is much of an indictment against Haskell. Sure, a functional language isn't a good fit for a very imperative algorithm, but that's not really its target domain.
Most implementations on Rosetta code in other languages [2] seem to be about as long.
[1] https://gist.github.com/harpocrates/bbed7b6837d524aafa02
[2] https://rosettacode.org/wiki/Sorting_algorithms/Quicksort
I'm curious, can you elaborate on this? If you view time as discrete dimension, mutable state is clearly not necessary. But since we cannot travel through time (yet), nature seems quite mutable in practice. For example, when microwaving food, it is extremely hard to put it back to the same temperature gradients.
Similarly with functional programming: if you adhere to it purely, provenance of every state can be traced back. If not, state changes are non-trivial to reverse. So it seems like modelling physical phenomena with immutable states is a choice of perspective rather than a law of physics that can be empirically tested.
In some sense I'm saying that Haskell's immutability is superficial, just a semantic choice of perspective...
I'm agreeing with you about the difference of perspective.
Time is more like a function variable or implicit parameter, not a piece of mutable state in the imperative programming sense. Such implicit parameters are also part of Haskell, by the way...
E (between the sheets) = sigma/epsilon0
E (outside) = 0
assigning two different values to the variable E.
In applied math, there are many expressions in which a variable y is treated as a value (depending on implicit parameters) or as a function y(t) depending on explicit independent variables. This is a matter of convenience, not principle.
If Feynman had used something like imperative programming in the Lectures, I wouldn't have been as baffled as (most of?) the rest of a class of physics undergraduates confronted with "LET I=I+1" in the introductory programming class. So I have some empirical evidence from the time when your first computer might be a PDP-10 down the road from Tony Hoare, that imperative programming is really unnatural for physicists.