The Main Scenario for Functional Programming
[Table of Contents] [Next Topic]
Certain types 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.
This blog is inactive.
New blog: EricWhite.com/blog
Blog TOCHere are some examples of scenarios where functional transformations apply:
• Transform of a collection of word documents that contain embedded data into a clean and more usable form of the data.
• Design and write your own transform of a word processing document to HTML. In the near future, I want to transform my source document for this tutorial so that you get the "Copy Code" buttons above code.
• Transform of a spreadsheet that contains messy data into a clean spreadsheet.
• Transform of a collection of word processing documents that contains embedded C# or VB code into a report of whether the code compiles and runs properly. The transform consists of extracting the code samples one by one, compiling them, running them, collecting the output of the code, validating the output against the output shown in the document, and producing a report. You can see an example of this idea here.
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#/VB 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.