That's an insightful comment and an important point. Because the underlying computation is physical, there's no such thing as side-effect-free computation. Any attempt to treat programming as purely mathematical, i.e. pure FP, is going to run up against this physical substrate. You can't abstract it away completely, and it gets complicated if you try. So I don't think pure FP is likely to be an ultimate solution to the core problems of minimizing complexity and building scalable abstractions. It would be, if programming were math, but math is not executable.
I believe one can even see this in the OP. Some of those examples seem more complicated than the side-effecty, loopy code that they're replacing. Maybe it is all habit and my mind has been warped by years of exposure to side effects and loops. But what if those things are more "native" to programming than pure FP can easily allow, and we need a more physical model of computation?
I've often thought it would be interesting to try teaching programming as a kind of mechanics in which values are physical commodities that get moved around and modified—to see whether it would be more accessible to beginners that way. I also wonder what sort of programming languages one might come up with out of such a model. It would be an interesting experiment. One would use mathematical abstractions to reason about such a system, but would not think of the system itself as a mathematical one.
> That's an insightful comment and an important point. Because the underlying computation is physical, there's no such thing as side-effect-free computation. Any attempt to treat programming as purely mathematical, i.e. pure FP, is going to run up against this physical substrate. You can't abstract it away completely, and it gets complicated if you try. So I don't think pure FP is likely to be an ultimate solution to the core problems of minimizing complexity and building scalable abstractions. It would be, if programming were math, but math is not executable.
Oh come on. Is the fact that your processor emits slightly more heat from computing your pure functions, and once in a while a cosmic ray may shift a bit or two, really such a big hindrance? You sound like a die-hard purist, ironically. We might as well ditch the whole idea of applied mathematics since there is always going to be a mismatch between the real world and mathematics. Triangulate? You can't do that, because the degrees you measure isn't going to be measured to the 'infinitely' precise decimal point. The whole theory behind geometry is based on practically unatainable ideals; surely Plato would be turning in his grave if he knew that cartographers had been using geometry to make those (fairly inaccurate) maps. shudder
I think that is an uncharitable interpretation of gruseom's comment. I assumed he was referring to the fact that some programming tasks are inherently stateful, such as writing OS kernels and device drivers.
However, I think that we should be able to, in principle, provide abstractions on top of inherently stateful things that hides their nature. In the same vein, we should be able to architect programs so that we can separate the inherently stateful stuff from the functionally pure stuff. For some applications, this will help. For others, not so much.
> I think that is an uncharitable interpretation of gruseom's comment. I assumed he was referring to the fact that some programming tasks are inherently stateful, such as writing OS kernels and device drivers.
No. The underlying computation is physical is just as true for any computer program, OS kernel or not. What was referred to was clearly the fact that it's silicon at the bottom level of any computation, just as his parent was talking about ("leaky abstraction" and all that).
I believe one can even see this in the OP. Some of those examples seem more complicated than the side-effecty, loopy code that they're replacing. Maybe it is all habit and my mind has been warped by years of exposure to side effects and loops. But what if those things are more "native" to programming than pure FP can easily allow, and we need a more physical model of computation?
I've often thought it would be interesting to try teaching programming as a kind of mechanics in which values are physical commodities that get moved around and modified—to see whether it would be more accessible to beginners that way. I also wonder what sort of programming languages one might come up with out of such a model. It would be an interesting experiment. One would use mathematical abstractions to reason about such a system, but would not think of the system itself as a mathematical one.