18F/tech-talks

Tech Talk: Functional Programming in Ruby

beechnut opened this issue · 2 comments

Tech Talk Submission

Thanks for offering to give a talk at a Tech Talks meeting! We just need a bit of information from you.

Name

Matt Cloyd

What's your talk title?

Functional Programming in Ruby a.k.a. I Elm'd My Ruby and So Can You!

What's your talk about?

Building off the last two Tech Talks about functional programming, we'll first learn about the Haskell-inspired, functional language Elm and the wonderful things Elm does for us (like guaranteeing zero errors at runtime!?). And while we don't (yet) use Elm at 18F, we can learn a lot about good programming from Elm, and apply it in a language we use more often, like Ruby.

What can we learn about writing an interpreted, dynamically-typed, object-oriented language from a compiled, statically-typed, functional language? Come find out! Topics include: "Confident Ruby" style, immutability, monads, union types and type safety with RBS, simulating compiler guarantees in an interpreted language, error messages, and code format.

How long is your talk?

  • Lightning talk (5-10 minutes)
  • Short tech talk (20-25 minutes)
  • Long tech talk (40-50 minutes)

Do you have any preferred dates for it?

March 15

Todo for the MC:

  • Update the TTS Guilds calendar entry for this talk to add the talk details.
  • Request captioning
  • Announce the talk(s) in #tech-talks, #dev, #18f, #18f-dev-announce when date is set
  • Announce the talk(s) in same channels on Slack in the morning, and follow up with a reminder just before they're about to begin.
  • Upload video and transcript to Google Drive.

Waiting to reschedule until @beechnut has less workload - hang in there.

Closing for now, since I'm prioritizing Consulting Guild work over everything and can't promise this talk.

Note to future self or whoever opens this issue. This talk was going to be, "What are the most interesting things about Elm and how can we implement them in Ruby?"

The agenda was starting to shape up like this:

  • Elm guarantees zero runtime errors. It does this through:
    • a type system (in Ruby, that's RBS/Sorbet)
    • pure functions (which you can do in Ruby if you try or lint a lot)
    • immutability (which you can be intentional about and/or lint)
    • pattern matching (which is now a Ruby feature)
    • a system for managing side effects (which you could theoretically write a library for, and dry/monad provides some of what's needed)