| Functional programming is more intuitive for many pure data transformation tasks. It's not more intuitive for the entire system. When you make a new file in a file system, you're already violating functional programming, even if you atomically create that file with all the content specified, and make it immutable. You must construct a new file system which is like the old one, but with that file, and then have the entire system tail call into a world where you pass that new file system as a parameter, so that the old one is not known (garbage). Unix has been the most successful system in getting partial functional programming into ordinary people's hands. A Unix pipeline like < source-file | command | command | ... | command > dest-file is functional except for the part where dest-file is clobbered. Or at least can be functional. The commands can have arguments that are imperative programs (e.g. awk) but the effects are contained. In the famous duel between Doug McIlroy and Knuth in solving a problem, in which McIlroy wrote a concise Unix script combining a few tools, McIlroy's solution can be identified as functional: tr -cs A-Za-z '\n' |
tr A-Z a-z |
sort |
uniq -c |
sort -rn |
sed ${1}q
Nowhere is there any goto statement or assignment. |