I ran across an post by David Altenburg about the enumerate, map, filter, accumulate pattern. These are certainly common functional techniques, but they're also common Smalltalk techniques. We call them do:, collect:, select:, and inject:into:.

He showed a Java implementation of a simple and common programming problem...

int maxSalary = 0; for (Employee employee : employees) { if (Role.PROGRAMMER.equals(employee.getRole())) { int salary = employee.getSalary(); if (salary > maxSalary) { maxSalary = salary; } } }

Comparible to a C# 1.0 version...

int maxSalary = 0; foreach(Employee employee in employees) { if(employee.Role == Role.PROGRAMMER && employee.Salary > maxSalary) { maxSalary = employee.Salary; } }

Then he does a Scheme version using a more functional style...

(define (salary-of-highest-paid-programmer records) (accumulate max 0 (map salary (filter programmer? records))))

And a Ruby version of similar style, note the Smalltalk'ishness of it...

employees. select {|emp| :programmer == emp.role }. map {|emp| emp.salary }. inject {|m, v| m > v ? m : v}

And for comparison here's a Smalltalk version...

(employees select: [:emp | emp role = #programmer ] thenCollect: [:emp | emp salary ]) inject: 0 into: [:a :b | a max: b ]

Though if I found the pattern that common I'd define a quick helper method on Collection to clean up the syntax to this...

employees select: [:emp | emp role = #programmer ] collect: [:emp | emp salary ] inject: 0 into: [:a :b | a max: b ]

What's interesting about them to me is really the difference between the Java/C# approaches and the more composable Scheme/Ruby/Smalltalk style. Because Java/C# 1.0 lack first class functions (C# actually has them now in 2.0 and a nice lambda syntax in 3.0) and a literal syntax for declaring them, everything ends up being a special case of for/foreach. They lack the ability to factor out common patterns like select:, collect:, and inject:into: into higher order functions.

As a side effect, select: turns into nested if's and a loop, collect: into a temporary variable and a loop, and inject:into: into both an if, a temporary variable, and a loop. You end up writing these patterns inline over and over rather than just reusing existing versions from the base library.

Languages that can't support and make idiomatic the use of higher order functions, aren't worth using these days in most domains. They're just too damn much work. However, using functional techniques doesn't at all mean using a functional language. All of these work quite well in good object oriented languages like Smalltalk and Ruby.