This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Tutoring FP (was: Re: Report on First Production Scala Project)

1 reply
Justin du coeur
Joined: 2009-03-04,
User offline. Last seen 42 years 45 weeks ago.
A thought, tangenting off of Eric's excellent post-mortem:
On Thu, Dec 8, 2011 at 9:47 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
  1. Most of my team is scared of Scala, probably because of the various Scala presentations I have given over the years. Face it - FP just scares some people.
Just a suggestion for folks to keep in mind: a bit of spoon-feeding and leading by example can help.
I'm by no means a purist: I haven't written any *pure* FP code of any real scale.  But I use FP elements constantly, and have had a lot of luck teaching my team through a mix of occasional lunchtime seminars plus code reviews.
The seminars are for introducing key FP concepts, so that people have the background -- for example, spending 45 minutes on an in-depth look at closures: what they are, how they work in the languages we use (principally C# and Actionscript), and most importantly when and why you would want to use them.  That gets the meme into peoples' heads.
Then there are the code reviews.  I've promulgated a discipline of code reviews before checkins in my team, not so much for catching bugs (although that happens occasionally) as for knowledge transfer -- basically a poor man's pair programming.  (Getting management buy-in for pair programming is typically hard, but there's rarely resistance from above to code reviews.)  I get people to do it mainly through leading by example: when *I* call a more-junior programmer over to review *my* checkins, it removes the common stigma that many folks feel, that they are being judged.  When everyone is getting regularly reviewed by everyone else, it just becomes normal.
These reviews are a great opportunity to teach.  When I'm checking in some code that does something FP'ish -- and trebly when I'm introducing some new FP library function -- I'll walk the reviewer pretty carefully through what is going on.  Even better, when I'm checking in a refactor to do something more concisely and clearly in an FP way, I'll demonstrate how much better the code is when you look at it this way.  (This is how I am slowly teaching folks the joy of higher-order functions.)
This sort of hands-on tutorial mode isn't a very *fast* way to teach FP to the junior engineers, but it's a pretty effective one.  It shows them in very practical terms when and why they should be using these paradigms: those examples tend to stick in ways that a classrooms explanation doesn't.  And it shows them how to use the ideas in the languages they have to deal with every day.
Anyway, just an observation for those who are struggling with getting their teams to use FP techniques.  It doesn't work for a big-bang change, but it can help you get the team and codebase to evolve in healthy directions...
Tony Morris
Joined: 2008-12-19,
User offline. Last seen 30 weeks 4 days ago.
Re: Tutoring FP (was: Re: Report on First Production Scala Proj

I am teaching FP today in Sydney, yesterday in Brisbane, the other day in Melbourne.

The trick is to do the hard and interesting stuff without the student being aware of it. This technique is often parodied by doing nothing more that using euphemisms. Of course, this does not work. The necessary psychology is more involved than that.

Alternatively, you can provide the student with a superficial understanding of the subject matter; it's much easier (and common?) to do this, but far less rewarding.

On Dec 9, 2011 4:05 AM, "Justin du coeur" <jducoeur [at] gmail [dot] com> wrote:
A thought, tangenting off of Eric's excellent post-mortem:
On Thu, Dec 8, 2011 at 9:47 AM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
  1. Most of my team is scared of Scala, probably because of the various Scala presentations I have given over the years. Face it - FP just scares some people.
Just a suggestion for folks to keep in mind: a bit of spoon-feeding and leading by example can help.
I'm by no means a purist: I haven't written any *pure* FP code of any real scale.  But I use FP elements constantly, and have had a lot of luck teaching my team through a mix of occasional lunchtime seminars plus code reviews.
The seminars are for introducing key FP concepts, so that people have the background -- for example, spending 45 minutes on an in-depth look at closures: what they are, how they work in the languages we use (principally C# and Actionscript), and most importantly when and why you would want to use them.  That gets the meme into peoples' heads.
Then there are the code reviews.  I've promulgated a discipline of code reviews before checkins in my team, not so much for catching bugs (although that happens occasionally) as for knowledge transfer -- basically a poor man's pair programming.  (Getting management buy-in for pair programming is typically hard, but there's rarely resistance from above to code reviews.)  I get people to do it mainly through leading by example: when *I* call a more-junior programmer over to review *my* checkins, it removes the common stigma that many folks feel, that they are being judged.  When everyone is getting regularly reviewed by everyone else, it just becomes normal.
These reviews are a great opportunity to teach.  When I'm checking in some code that does something FP'ish -- and trebly when I'm introducing some new FP library function -- I'll walk the reviewer pretty carefully through what is going on.  Even better, when I'm checking in a refactor to do something more concisely and clearly in an FP way, I'll demonstrate how much better the code is when you look at it this way.  (This is how I am slowly teaching folks the joy of higher-order functions.)
This sort of hands-on tutorial mode isn't a very *fast* way to teach FP to the junior engineers, but it's a pretty effective one.  It shows them in very practical terms when and why they should be using these paradigms: those examples tend to stick in ways that a classrooms explanation doesn't.  And it shows them how to use the ideas in the languages they have to deal with every day.
Anyway, just an observation for those who are struggling with getting their teams to use FP techniques.  It doesn't work for a big-bang change, but it can help you get the team and codebase to evolve in healthy directions...

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland