ENTRIES TAGGED "functional"
Flow-based, functional, and more
“Small pieces loosely joined,” David Weinberger’s appealing theory of the Web, has much to say to programmers as well. It always inspires me to reduce the size of individual code components. The hard part, though, is rarely the “small” – it’s the “loose”.
After years of watching and wondering, I’m starting to see a critical mass of developers working within approaches that value loose connections. The similarities may not be obvious (or even necessarily welcome) to practitioners, but they share an approach of applying encapsulation to transformations, rather than data. Of course, as all of these are older technologies, the opportunity has been there for a long time.
The Return of Flow-Based Programming
“There’s two roles: There’s the person building componentry, who has to have experience in a particular program area, and there’s the person who puts them together,” explains Morrison. “And it’s two different skills.”
That separation of skills – programmers creating separate black box transformations and less-programmery people defining how to fit the transformations together – created a social problem for the approach. (I still hear similar complaints about the designer/programmer roles for web development.)
The map-like pictures that are drawing people to NoFlo, like this one for NoFlo Jekyll, show how the transformations connect, how the inputs and outputs are linked. I like the pictures, I’m not terribly worried that they will descend into mad spaghetti, and this division of labor makes too much sense to me. At the same time, though, it reminds me of a few other things.
Let the environment do more of the work
Functional programming keeps growing. While it has long been a popular topic in academic circles, and many of my CS-educated friends wonder why it took me so long to discover it, the shift in approach that functional programming requires made it a hard sell in the commercial world. As our computers have become more and more powerful and our problems more complex, functional programming approaches and environments seem better able to shoulder those loads.
Neal Ford, Meme Wrangler at ThoughtWorks, has been showing developers how to shift from classic imperative models to cleaner functional approaches. I was lucky to get to talk with him at OSCON, and we’ve also posted his OSCON talk, with many more concrete code examples.
How close to the metal must programmers be?
Recursion predates computers, but computers’ ability to repeat the same task over and over made recursion a common approach to solving complex problems. Factorials might be a classic example of what recursion can do, but recursion enables many more divide-and-conquer approaches, as well as useful approaches to infinite loops.
You may be nodding your head, thinking “sure, but we don’t need to think about that any more.” Or you may be nodding your head, thinking “if only anyone remembered this stuff any more.”
Until a year or so ago I was in the first camp. I knew the basics of recursion, applying it once in a while to calculations and tree-walking, but it didn’t seem central. Loops and queries of various kinds seemed to make recursion a marginal topic. Usually, seeing recursion was a sign for me to move on, marking a story as “more magic than I needed to know about.”
Erlang forced me to learn recursion—well beyond factorials and trees. Single-assignment variables are a stern master, making me rethink most of the logic I’d used for the last thirty years. There were pleasant surprises, too, like the usefulness of infinite loops in Erlang processes. By the end of writing Introducing Erlang, I had my first genuinely fond feelings for recursion.
Now that I think I have a handle on recursion, I’m paying much more attention to it than I used to, and suspecting I’ve crossed a line. It seems like every language has its own dividing line between amateur and expert, but recursion seems to be a line that crosses programming broadly. Languages meant to be approachable go out of their way to make recursion invisible, while languages meant for experts (or those aspiring to be experts) leave recursion in the open.
A few iterations make even functional programming digestible
Programming gets easier and easier as you do more of it. Languages and logic become familiar, in ways that extend from looking up less and less all the way to muscle memory in your typing. The first few iterations in a new language are often difficult, as everything seems odd. Shifting not just to new languages but to new approaches makes practice even more important.
One of my worst features has been that I never liked to practice. I understood rehearsing, working together in a group, but practicing? Exercises, especially for the sake of exercise, were never my thing. That character flaw has hobbled my writing. I can come up with examples for books, focusing tightly on an issue I’m explaining. But then, really? I have to ask readers to go solve a particular (already solved) problem?
I’m not alone in this—too many writers have inflicted that attitude on their readers. Exploring sample code is not the same as writing your own code. Miguel de Icaza points out that:
When you finish a chapter in a modern computing book, there are no exercises to try. When you finish it, your choices are to either take a break by checking some blogs or keep marching in a quest to collect more facts on the next chapter.
During this process, while you amass a bunch of information, at some neurological level, you have not really mastered the subject, nor gained the skills that you wanted.
We can fix this.
Steve Vinoski on when to make the leap to functional programming.
Functional programming has a long and distinguished heritage of great work — that was only used by a small group of programmers. In a world dominated by individual computers running single processors, the extra cost of thinking functionally limited its appeal. Lately, as more projects require distributed systems that must always be available, functional programming approaches suddenly look a lot more appealing.
Steve Vinoski, an architect at Basho Technologies, has been working with distributed systems and complex projects for a long time, first as a tentative explorer and then leaping across to Erlang when it seemed right. Seventeen years as a columnist on C, C++, and functional languages have given him a unique viewpoint on how developers and companies are deciding whether and how to take the plunge.
Highlights from our recent interview include: