I’m another functional programming (and type theory) afficionado, but I don’t think they are the future for the whole of computer programming.
Some problems, such as real-time interaction with a user through a GUI, are inherently procedural and object-oriented.
And there are some problems in distributed and/or massively parallel computing that will be more common in the future, and these problems will also demand both functional and procedural aspects for their efficient and robust solution.
And the functional languages I have played with are still very weak in dealing with error and exception handling—particularly ‘hardware-like’ out-of-memory conditions or network timeouts.
I need to disagree, though, with your inclusion of “Static typing helps (and requires) you find and correct a large fraction of trivial bugs without running the program” in your list of the advantages of functional programming. The issue of static vs dynamic typing is completely orthogonal to the question of functional vs procedural control flow. There are statically typed procedural languages (C++) as well as dynamically typed procedural languages (Smalltalk). Similarly on the functional side of the fence.
I also have to disagree that it is an advantage of functional programming that “Program evaluation is defined much more directly on the syntax of the language.” I’ve always understood that it is the direct opposite—evaluation order in a procedural language is explicit in the program syntax, whereas functional languages (being side-effect free) leave much more scope for the compiler to shift evaluation steps around.
Functional programming can do procedural programming as well (monads), you just to be more more explicit about the state thats being modified.
I agree static typing is somewhat orthogonal, but it seems to be the case that functional languages have much more powerful type systems than procedural ones. I don’t know enough to say whether similar powerful type systems can be developed for procedural languages.
What I meant by ′ program evaluation is defined …” is that in many functional languages, a term is evaluated by transforming it into another term in the same language (such as via beta reduction), but this isn’t true in procedural languages. You are correct that functional languages have a lot more options about the order in which this is done.
I’m another functional programming (and type theory) afficionado, but I don’t think they are the future for the whole of computer programming.
Some problems, such as real-time interaction with a user through a GUI, are inherently procedural and object-oriented.
And there are some problems in distributed and/or massively parallel computing that will be more common in the future, and these problems will also demand both functional and procedural aspects for their efficient and robust solution.
And the functional languages I have played with are still very weak in dealing with error and exception handling—particularly ‘hardware-like’ out-of-memory conditions or network timeouts.
I need to disagree, though, with your inclusion of “Static typing helps (and requires) you find and correct a large fraction of trivial bugs without running the program” in your list of the advantages of functional programming. The issue of static vs dynamic typing is completely orthogonal to the question of functional vs procedural control flow. There are statically typed procedural languages (C++) as well as dynamically typed procedural languages (Smalltalk). Similarly on the functional side of the fence.
I also have to disagree that it is an advantage of functional programming that “Program evaluation is defined much more directly on the syntax of the language.” I’ve always understood that it is the direct opposite—evaluation order in a procedural language is explicit in the program syntax, whereas functional languages (being side-effect free) leave much more scope for the compiler to shift evaluation steps around.
Couple of comments:
Functional programming can do procedural programming as well (monads), you just to be more more explicit about the state thats being modified.
I agree static typing is somewhat orthogonal, but it seems to be the case that functional languages have much more powerful type systems than procedural ones. I don’t know enough to say whether similar powerful type systems can be developed for procedural languages.
What I meant by ′ program evaluation is defined …” is that in many functional languages, a term is evaluated by transforming it into another term in the same language (such as via beta reduction), but this isn’t true in procedural languages. You are correct that functional languages have a lot more options about the order in which this is done.