Stewart Stremler wrote: > And actually I'm not averse to minimizing side-effects per se, only with > the idea that it should be /enforced/. > I think it is more accurate to say that FP doesn't so much enforce that (it is entirely possible to introduce more side effects than is necessary with FP, it is just.... darn inconvenient to do so) as it enforces the notion of enumerating all the points where state change happens, so that the developer and the compiler are fully cognizant of what is going on. >>>> State does not have to be a side effect. Nor should it be. >>>> >>> Then it's going to be slow. >>> >> Unproved assertion. Why must it be slow? >> > > How do you make a change to a gigabyte of data without changing the > data you were passed in? You copy it. > I think you misunderstand what happens with FP. It is entirely possible for a compiler/runtime to identify that the old state is no longer needed and as such doesn't need to be kept around. It is also possible to track the new state as a delta/transformation of an old state (very common to do this). Basically all the optimizations that you can think of doing manually are available to a compiler/runtime. Now, it won't *always* pick the perfect solution, but they often are smarter about it than your typical developer. More importantly, they never make an optimization that turns out to actually be a bug, which developers do all the time. ;-)
One of the nice advantages of this approach is that often determining which approach is faster is very contextual. For example, representing new state as a transformation of an old state is typically more computationally intensive, but tends to allow for more parallelism. Now, if suddenly your code switches to a context where such a trade off is desirable, you'll often end up rewriting it in a non-FP language, and it will be far from clear that the old code and the new code are conceptually equivalent (and validating that can be a PITA, even with unit tests). Think of all the pain that this is causing developers right now as they move to multi-core, multi-processor, and multi-node versions of their code. --Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
