Artie Gold writes:
One way to think of it is to look at a program as a partially ordered set of calculations; some calculations need to occur before others, other groups can occur in any order. In an imperative language you specify a total ordering (which is overkill).
This is a weak argument. First of all it is not the case that imperative coders always specify a total ordering: multitasking, threading and interrupts (and their projections into software as in Unix signals and asynchronous exceptions) are ways of specifying partial ordering when a total ordering would lose. The potential execution speedups of the partial ordering are probably quite real, emphasis of potential, and people having been trying to exploit it for decades now, yet the fast languages are still the imperative ones and the impure functional ones because they have the best fit to modern hardware designs. There is so much wealth invested in these modern cpus designs that it would cost 100s of billions of dollars to create competitors best fitted to pure functional languages. Hint: you need to write a new OS design to go with your new hardware design, then attract users and developers to the OS. And nobody's going to invest that dough there because no single organization stands to gain anywhere near what it would cost. Note that modern cpu designs use "out-of-order" execution strategies; so on micro-second timescales they ignore the total ordering when doing so suits them and when it preserves semantics. There's a case for FP, but parallel execution opportunities is not it. The case for FP is superior abstracting ability. See John Hughes, Why Functional Programming Matters. I guess you could view not having to specify instruction ordering when you do not need to as a sort of abstracting, but I have yet to see code that profits from that kind of abstraction. If that's your argument, show me code examples; that's what Hughes did in his paper. No grudge against you, Artie Gold. This is pent-up frustration at many posters who've made the same argument
"May you keep turning the pages. And may the book never end."
You, too. -- Richard Uhtenwoldt