How to (and not to) give a talk on F#

---

Michael Easter called me out over Twitter tonight, entirely fairly. This blog post
is to attempt to make right.

Context: Tonight was a .NET
Developer Association meeting in Redmond, during which we had two presentations:
one on Entity Framework, and one on F#. The talk on F#, while well-meaning and delivered
by somebody I've not yet met personally, suffered from several failures that I believe
to be endemic to Microsoft's approach to presenting F#. I don't fault the speaker—I
think Michael was set up to fail from the very beginning. Thus, I decided that it
was time for me to "put up" and describe the structural failures I've seen
in several talks attempting to describe F# to the general .NET computing community.
(I think these could probably be generalized to presenting a new language to any general
computing community, but I'll keep it focused on F# for now.)

In no particular order:

• DON'T use a demo based on a mathematical principle (like Fibonacci,
  factorial, or some other exponent-hugging formula). I ask you, how many developers
  find themselves writing that kind of code on a daily basis? If you offer up purely
  mathematical examples, you will create the impression that F# is only good for high-scale
  numerical and mathematical computing, such as what scientists use, and you will essentially
  convince everybody in the room that F# belongs in that class of programming language
  that doesn't have anything to do with them.
• DO use a demo based on real-world environments or problems. Use
  domain types that could have come from a regular line-of-business scenario; my favorite
  is "Person", since that can serve as a base type for other, more domain-specific,
  types (like "Student", "Instructor", "Employee", and
  whatever).
• DON'T stress the F# Interactive environment. Yes, it's great
  that F# has an interactive environment and a REPL. But accept that this is not what
  the general development community cares about, or even sees value in. In fact, the
  more you stress the REPL/interactive window in F#, the more likely you are to get
  a question at the end of the talk asking you to compare F# to Python or Perl. Then
  you end up having to argue the benefits of static typing and type inference over dynamic/duck
  typing, which really makes no sense in a scripting tool, which is only on the questioners'
  mind because you put it there by stressing the REPL.
• DO show F# code being called by other assemblies, and vice versa. At
  the end of the day, the watchword here should be "interoperability", because
  no matter how eloquent your presentation, you're not going to get the audience to
  suddenly abandon their C# and Visual Basic and switch over to writing everything in
  F#, because there's just too many scenarios where F# is not the right answer (UI "top
  of the stack" kinds of things being at the top of my "not great for F#"
  list). Stress how an F# type is just a class, with methods that can be invoked from
  C# and vice versa.
• DON'T answer the inevitable "why should I care?" question
  with the word "productivity". I hate to be the one to point this
  out, but every language ever introduced has held this up as a reason to switch
  to it, and none of them have ever really felt like they were a productivity
  boost, at least not in the long run. And if you answer with, "Because I just
  think that way", that's a FAIL on your part, because I can't see how your thinking
  changes mine. (You may also like the Pittsburgh Steelers, while I know they can't
  hold a candle to the New Orleans Saints—now where are we?)
• DO answer the inevitable "why should I care?" question
  with tangible real-world scenarios or examples. Give two or three cases,
  abstract or concrete, where F# makes the developers' life easier, and how. And frankly,
  I would sprinkle in a few cases where F# isn't a net win, because everybody
  knows, deep down, that no one language is perfect for all scenarios. (Only marketing
  and sales people seem to think there is.)
• DON'T jump straight into all this functional jazz. I
  hate to tell you this, but most of the developer community is not convinced that functional
  programming is "obviously" the right way to program. Attempting to take
  them deep into functional mojo is only going to lose them and overwhelm them and quite
  likely convince them that functional programming is for math majors. Use of the terms
  "catamorphism" or "monad" or "partial application" or
  "currying" in your introductory talk is an exercise in stroking your own
  ego, not in teaching the audience something useful.
• DO stress that F# can do everything C# or Visual Basic can do. Developers
  like to start with the familiar—it's why every programming language starts with the
  "Hello World" example, not only because it's simple and straightforward
  but because developers have come to expect it. F# can build types just like C# can,
  so do that, and use that as a framework from which to build up their understanding
  of the syntax and semantics.
• DON'T assume you can give an introduction to a programming language
  in 20 minutes. I don't care how good you are as a presenter, it can't be
  done. 50 minutes would be pushing it. 90 minutes is maybe just enough to get through
  enough syntax to get the audience to the point where they can read a commonplace F#
  program. Maybe.
• DO tease the hell out of them for 20 minutes. If you only
  have 20 minutes, then create a super-sexy demo (not a math-based or scripting-based
  one), show them the demo, then point out that this is written in 35 lines of F#, and
  if they want to understand what's going on in that 35 lines, here's some resources
  to go learn F#. Leave them wanting more.

Again, I'm not faulting Michael (tonight's speaker): I think he bravely attempted
what was likely to be a failure regardless of who was giving the talk. My hope is
that as others start to step up to talk about F# to their coworkers and fellow user
group members, this will help avoid a few more "Oh, so F# is totally irrelevant
to me" reactions.

---

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.