Functional Brighton: "What functional programming means to me"
The Functional Brighton meetup for May was a set of short demos and talks on the subject of "What functional programming means to us". Kit kicked off the evening with an F# show-and-tell of a 3D flocking simulator (complete wth 3D glasses); Eric spoke about why he uses Haskell; Andy showed us some Scheme code and made it progressively more functional; and Tom jumped up with a code tour of a Haskell project of his. A good evening with plenty of Q&A.
I had every intention of recording what I said about Scala, but failed. So here goes with a reconstruction of what I said or intended to say.
"What functional programming means to me" has been a fun assignment. I have no background in functional programming—and the funky languages I have used for any period of time were never described as functional. So the way I've approached this is to report on three things I've noticed during my transition from mostly-Java to Scala, and consequently I'm not sure how much of this is really about functional programming.
Approach to problem solving
The first of the three things is very general. It's about how I seem to approach problems. It's also the hardest one for me to explain, and probably the most waffly.
Here (slide 2) is an example of the kind of problem I had to deal with last year, and what we're doing is taking a tweet and adding a hashtag to it if it's not already there. I'm not sure how I used to solve these problems, but I think it would have dived in with a loop and maybe a string buffer and I'd test and append.
Now what I seem to find myself doing is thinking about what I have, and what I want to get (slide 3). What do I have? Some tags and a tweet. What do I want to get back? A tweet. Which really means (slide 4) I have a list of strings and a string, and I want a string back. By thinking about what types are involved, I find myself asking what kinds of transformations will get me the result I want.
So in code (slide 5) if we have a List[String] and a String, and we want to get a String back, then a fold is a reasonable choice. This is Scala, we're defining appendTags which takes our tweet which is of type String, and the tags of type List of String, and it returns a String (although I've left that off as it's being inferred).
AppendOne solves the simple case: it expects a string and a tag and does the obvious thing. As luck would have it, the two parameters appendOne wants are the parameters that foldLeft gives it for each of the tags and the current tweet.
(At this point I think we dropped to the REPL and tried this out)
I find these solutions preferable in terms of clarity, LOC, also happiness in not writting the same old loop I've written many times before (slide 6).
That was the first thing: thinking in terms of transformations, and how it sort of suggests solutions in terms of functional programming constructs.
Concurrency
The second thing is about concurrency. From what I recall, in C it was just plain hard to write concurrent code at all. In Java, it's easy, but even easier to get it wrong. It looks to me that the functional world want to address this problem, being both correct and easy to use. Maybe this quote (slide 7) alludes to why, as concurrent problems boil down to coordinated access to shared mutable state. As functional tends to point you away from mutable state, part of the battle is over.
These are facilities I take advantage of today, and it makes it easy to bring not-insubstantial improvements to applications. I have a code base (slide 8) that makes multiple HTTP requests to web APIs. In this example the function yahoo, if you call it, hits Yahoo's site and brings back address book entries (let's say). And the google one does the same to Google's API site. They don't take very long, but they absolutely can happen concurrently.
I have a list of two functions, the underscore telling us the functions aren't actually being called yet. I turn them into a parallel collection and then call the apply function on them. They are executing in parallel and the result will be a List containing two lists: one for the results from each site.
This is one-liner stuff. There's no barrier to going concurrent.
Actually, that example is from Scala 2.9, and I don't use Scala 2.9 yet, so I do something a little more involved (slide 9).
Useful concepts
The third thing that "functional is" to me, is the set of constructs functional programming assumes. Facilities like Option, comprehensions, flatMap, pattern matching which, as I've said here (slide 10), are astonishingly useful every day and yet I'd never heard of them before using Scala.
Initially they seem like esoteric, academic, hard to understand. They're not hard: they're rich. It takes time to appreciate them. But it's time well spent.
I've blogged about this example (slides 11 and 12), but it's accessing the Google contacts API. Comparing the Google Java code and the the corresponding use of Option and for comprehensions are much easier to read, and easier to write. They make a big impact in day-to-day code.
Summary
Those were the three things (slide 13) that functional programming appears to mean to me at the moment.
- Thinking in terms of transforamtions changed my approach to problem solving for the better.
- Concurrency without any barriers to use.
- The facilities in functional programming that let you write better programmes.
Comments 3 Comments
I've never read your blog before, so I don't know if you are one of the people trying to convert folks from OO to functional or not, but let me suggest that if you are, you should talk to potential converts in terms they are going to understand.
It seems like you ought to be able to do this since you claim that you used to be a Java programmer.
What are some headaches that Java (or other OO language) practicioners face? How does functional/Scala solve them better?
Also, if you don't want to sound like someone preaching the coming apocolypse, you should also mention what functional/Scala don't do well. If you aren't aware of the weaknesses of a paradigm/language, then you haven't been studying it at length or very deeply.
Your prose here seems to kind of wander, and you introduce terms but not in context (neither do you explicitly define them) so that your reader can discover their meaning. I know what pattern matching is because I've fooled around with Erlang. Beyond introducing those terms, you don't really convey their utility or bother to explain why they may be more useful than programming techniques found in other languages. Why is pattern matching better than switch statements or if/else blocks?
The developer's #1 battle is against the clock. Couch your arguments for why "functional is great" in terms of time savings, whether that savings comes at reduced time to write, time to debug, or time to maintain, and I think you will find a lot more converts.
I see a common thread running between most people who write about computer science, programming, or math: they are generally speaking abysmal at explaining what they know to other human beings. The problem is not lack of intelligence, but rather the lack of experience in effective communication. Don't describe something from your perspective. You are simply preaching to the choir then. Think about a friend you want to convert. Think about what knowledge and experience
they have and then write as though you were talking directly to that person. This is not talking down to someone, this is really talking to someone.
I've heard the arguments about functional being better for concurrency since you don't have to deal with locking threads, but are most people going to deal with problems of significant enough scale to necessitate learning an entirely new paradigm not to mention a language?
Please, if you are willing, I implore you to do a better job explaining this stuff than others have for those of us in the audience who haven't yet made it to "Aha!" with functional.
One of the things that I do differently from your approach when coding is the first thing I look at when coding is what I want, then look at what I have, then plan on how to get what I want from what I have.
That's basically because what I want is the solution to my client's problem. They are generally very good at saying SOME of what they want.
They are very poor at telling me what they have that can help me get what they want. They also don't tell me what I already have that applies to what they want. Usually I'll break what they want into parts and work through each part to find out what I have.
There is an opportunity for someone to outline, generally, what the real, hard benefits of functional programming and what the limitations are. That's a long way from all that I'm doing, which is throwing out small experiences I have :-/
The more general writings or presentations in this area that I've seen tend to be about one language compared to another, such as Bill Venners's "The Feel of Scala" at a Java conference [1]. Or they are introductions, like the wonderful Erik Meijer C9 lecture series [2]. LOC, ways of thinking, new techniques... there are details out there, but no-one has really brought them all together. Not that I've seen yet.
Personally, I find functional to be a useful tool and one that I enjoy. Scala is my day-to-day language of choice, and it allows me to mix functional and OO: I don't subscribe to a view that there's an "apocalypse" on the way.
I'll try to share some of the benefits on this blog, taking into consideration your comments, but I'm not actually out to convert anyone.
References:
1. http://www.devoxx.com/display/JV08/The+Feel+of+Scala
2. http://channel9.msdn.com/Shows/Going+Deep/Lecture-Series-Erik-Meijer-Function...