I can’t help but notice…

… that functional programming might be the next big shift in general purpose development paradigms.

The other day I realized a trend that may be decisive for the evolution of our development environment in general: Functional Programming! It is not that I did not see the symptoms. It is just that it took that long to realize the breadth of it. (I’m in good company, though.)

Yesterday…

… it started quite unobtrusive.

We got generics and with them (hardly mentioned as more than syntactic sugar) type inference.

In retrospect it even seems misleading that generics were discussed as something akin to C++ templates. The technical differences may seem superfluous at first, yet some advanced techniques with templates, orthogonal libraries such as STL (only recently available as STL/CLR for managed code) and template meta-programming have never been broadly considered for generics. Rather type inference plays a major role with generics, effectively pushing the burden of type safety from developer to compiler.

We got anonymous methods, which was at that time hardly worth the effort and not at all a justified language change — if looked at in isolation.

We got iterators, which was again a feature no one had missed, much less asked for.

Several features, seemingly unrelated, some rather tiny unmotivated additions to the language.

Today (the obvious)…

… we have LINQ.

LINQ has been introduced at the PDC 05 by Anders Hejlsberg et al. as kind of “complied SQL statements”, “type safe SQL”, and “unified query language”, thus the name of course.

The language features that make up LINQ rely on the above language features. And with LINQ those pieces suddenly fall into shape. Type inference for anonymous types and together with generics as general foundation, anonymous methods for lambdas, iterators for deferred execution. A concise system.

And this is how LINQ is seen by many people: Type safe queries. Something to replace ugly ADO.NET code over SQL strings with beautiful and compiler checked C# statements. Who can blame them, that’s how it got introduced.

What those people miss is the less obvious force behind LINQ. It’s functional programming, as Anders itself explains — not the other way round, as presented in “The Evolution Of LINQ And Its Impact On The Design Of C#”.

It’s not that the trend to functional programming is kept secretly. Matter of fact, the term is mentioned quite frequently in relation to LINQ. And there’s other evidence, like the new .NET language F#, incidentally written by Don Syme, the man who built generics for .NET. And there’s enough bloggers out there, talking about the topic.
It’s more that the average corporate developer, the kind that has more than enough to do getting his job done, is not directly exposed to this information. Therefore he picks up only occasional hints at best, not connected, not nearly enough to identify a larger trend. Many of them may not even be aware about the degree to which they have already exposed to functional programming bits and pieces.

Today (the not so obvious)…

… there is a lot of talk around functional programming going on in the blog sphere. Some examples:

Regarding lambdas have a look at Wes’ blog to learn about currying, continuations, monads. Other bloggers have written about other language features (e.g. extension methods). Luca tries to bring F# features to C#.

Also there has been a lot of noise around one of the tenets of functional programming: immutable data types. Just as we got new collection classes with generics, we may get immutable ones sometime in the future.

If you like to read up on immutable data types, Roy has compiled a list of related blog posts; I found Erics series to be the best, as he addresses not only the purpose but also the feasibility (consider the insolence, a list that does not change, how can that be feasible?). And he addresses null values (not exactly part of the functional universe) better than the others.

Another interesting application is MoQ (if not by itself, then as an example for the functional approach), a LINQ based mock framework. It may serve as indication that even stuff that is not directly related to functional programming may come in a functional shape.

Tomorrow…

… — and this is strictly a personal guess — the trend will continue. If anything it will diverge in different areas. Functional programming in general and F# idioms in particular may contribute to our languages, the patterns we use, and the libraries. F# may not only be the first functional language to decisively enter the .NET environment, it may be the very first functional language with at least the potential to become a mainstream language. 

The driving force behind this is something that Anders hinted at it in his interview above, and that Pat Helland pointed out quite clearly at the TechEd: The future is parallel. And functional programming is so much more suited to parallel processing than imperative programming. Matter of fact, Parallel LINQ (PLINQ) is already working in that direction.

Right now…

… that’s enough gazing in the crystal ball. What’s the consequence (provided you share my view)? Today probably nothing. None of my daily work is affected, beyond using LINQ as a nice tool. Tomorrow perhaps still nothing, as I may be totally wrong. All I can recommend is this: Try to see the bigger picture behind LINQ and keep watching for the trend. For if it’s the other way round, you may be tomorrows next VB guy, like the one in the next cubicle that never mastered inheritance and exceptions.

As an afterthought: I’m not aware that this functional programming trend happened somewhere outside the Microsoft space. This is contrary to the dynamic languages trend. And I’m honestly not sure what the implication is.

That’s all for now folks,
AJ.NET

Advertisement