In the .NET world programmers are constrained in what they can do by the languages available to them. Like Whorf's hypothesis (that you can only think thoughts that are expressible in your spoken language) but, in my view, more concrete than is the case with spoken languages.

Some feel constrained by the limits imposed and are, I'm sure, pleased by the advances that have already occurred in VB and C#. Others probably haven't given it much thought.

I imagine that F# will be another step in that advance and remove some of the constraints that make programmers dumb down their thought patterns.

I picture F# more as a catalyst or platform that will add techniques to a programmers palette, rather than as the result of a trend. With luck, F# will be a cause (of changing approaches) more than a result.

The type of programming your describing sounds likely to be "procedural" or "imperative" but not "functional". If you are not using lambdas, for example, then you're probably not doing "functional programming" by most people's definitions.

My perceptions of the recent trend towards FP is not really a reversal of anything of the past couple decades, and not even really a shift away from OOP. OOP still matters a lot, though nowadays people are favoring a more immutable and lambda-ful style.

See also

[link:lorgonblog.spaces.live.com]

No, not really.

For one thing, "procedural" and "functional" aren't the same - definition of both terms is rather vague, but conventional definitions would in fact place them squarely on the opposite sides of the spectrum.

For another. "functional" and "OOP" are not mutually exclusive, but rather orthogonal, and F# is an OO language just as it is an FP language. It's possible to write pure functional OO programs - so long as your objects are immutable. You still get encapsulation and virtual dispatch, though, which are useful tools.