[Blog Map] [Table of Contents] [Next Topic] This blog is inactive. New blog: EricWhite.com/blog
So I mentioned that certain type of problems lend themselves to a functional programming approach. What are these types of problems? Transformations.
Any time that you have some collection of data, or multiple sources of collections of data, and you need to transform it into another shape, you have a transformation, and you can write it in the functional style.
Here are some examples of scenarios where functional transformations apply:
But there are many opportunities to treat a programming task as a transformation. There is a chunk of code that I really want to write where you transform from some internal data structures into another collection of data structures that define method calls into a graphical drawing library. You might use this approach in a render engine for DrawingML, say. Actually, I would not be surprised at all if many rendering engines are implemented in this fashion. Many years ago, I owned a company that developed and sold a grid custom control. The custom control had extensive capabilities, and the internal data structures were complicated. The rendering code was by far the most complicated chunk of code in the widget. I'd really like to rewrite that code using the approach detailed in this paragraph. Maybe someday.
In the past, I've also written multiple report writers. These report writers were driven from a non-procedural, declarative definition of the report. I believe that it is possible to write such a report writer in maybe 500 or 1000 lines of code. In other words, this would be a sample program, not a real development effort. And of course, the report writer could output an Open XML word processing document or spreadsheet. My intention is to do this implementation (sooner or later) and include it in an appendix to this tutorial.
Another transform that I'm itching to write is the hi-fidelity LINQ transform of an Open XML word processing document to HTML. I believe that this transform could be written in maybe 500 or 1000 lines of C# FP code. This transform is pretty simple, but you have to pay attention to a myriad of details. It is not hard, just a bit tedious.
Functional transformations are stateless transformations. Graphical user interface programs are stateful programs. When you click a checkbox, you change the state. When you enter text in an edit control, you change the state. I know that there are techniques using FP approaches to write UI code. It's been years since I wrote much UI code, but I might give the FP approach a try if and when I ever do. Even when writing such programs in a stateful way, you can write chunks of FP code embedded in the stateful object-oriented code. Including both styles of code, even in a single module, is a natural way to code.
[Blog Map] [Table of Contents] [Next Topic]
PingBack from http://blogs.msdn.com/ericwhite/pages/FP-Tutorial.aspx
[Table of Contents] [Next Topic] Some time ago, I was talking to some members of a team that used LINQ
Many types of documents contain code, including API documentation, tutorials, specifications, technical