Functional Geekery Episode 08 – Jessica Kerr

In this episode I talk with Jessica Kerr. In this episode we talk bringing functional programming concepts to object oriented languages; her experience in Scala, using the actor model, and property testing; and much more!

Our Guest, Jessica Kerr

jessitron.com
@jessitron on Twitter and [email protected]

Topics

Jessica’s ØreDev Talk
Jessica’s Ruby Midwest Talk
Bring Just Enough of the Ideas from Functional Programming Back to Java and C#
Use Static/Class Level Methods to Make Needed Data Explicit
Designate Methods That Modify State When Working in Object Oriented Languages
Isolation as the Dual/Reverse to Encapsulation
Guava library for Working in Java
Readable Code vs Familiar Code
Use Code Reviews to Spread Practices
Scala as a Hybrid Language and the Blessings and Curses Therein
Reasons One Might Choose Scala
Akka
Akka Concurrency by Derek Wyatt
The Actor Model
Testing with Scala
Introducing a Functional Language by Writing Tests in that Language
ScalaTest
ScalaCheck
Property Based Testing
ScalaCheck: The Definitive Guide
Commonalities Between Git and Functional Concepts
Directed Acyclic Graphs
Importance of Immutable Data in Functional Programming
LambdaLounge
F#
Using a Functional Language to do Spikes to Solidify Ideas
Kansas City Developer Conference
Jessica’s Upcoming Appearances
GOTO Chicago
QCon New York 2014
scalaz-stream
GOTO Amsterdam 2014
ScalaDays 2014
Scala Puzzlers
Ribbon Farm

A giant Thank You to David Belcher for the logo design.

Update: May 6th 2014
Added link to Scala Puzzlers.
Also, Jessica has informed me that she had to cancel her appearance at ScalaDays.

6 thoughts on “Functional Geekery Episode 08 – Jessica Kerr

  1. Mark Seemann

    This was the best episode of Functional Geekery yet; very inspiring. Thank you 🙂

    At one time, Jessica talked about how hard it is to write Property-Based Tests, which reminded me that in a sense, what you have to do in Property-Based Testing, is basically the same as Bertrand Meyer’s concept of Design-By-Contract, but instead of writing the pre- and post-conditions into the objects (or functions), you write them into the tests.

    The set-up of a Property-Based Test corresponds to the pre-conditions, and the properties correspond to the post-conditions.

    So, if you’re in the habit of explicitly thinking about pre- and post-conditions, you’ll find Property-Based Testing easier than if you’ve never though about those things before. As a corollary, Property-Based Testing may lead to better code exactly because you’re forced to think about these aspects of design, just as Test-Driven Development may lead to better code because you’re forced to think about how easy your System Under Test is to use.

    Reply
    1. functionalgeekery Post author

      Thanks! A lots of the credit goes to the guests as well!

      The more I have been digging into it, the more I have found, like you, that they are both different ways of expressing the invariants of a function. In the episode with Reid Draper (http://www.functionalgeekery.com/episode-6-reid-draper-2/), I asked him about being able to generate properties from the contracts that can be defined on a method in Clojure, but it sounded like nobody has yet to take it that far yet.

      Thanks again for your comment and tweet!
      –Proctor

      Reply
  2. Arash

    I can’t stress enough how much I’m glad that I found your podcast. It’s been amazing ! As a novice functional programmer, I’m learning a lot from conversations. Your doing great job for FP dude, thanks 🙂
    oh, and BTW, I use @ for methods with side-effect in C#, I can ignore it when I’m calling the method, yet it’s there in methods definition, and reminds me that yeah, this is an ugly method !

    Reply
  3. P J Hancock

    Another meaty podcast, packed with things to chew over. “The actor model is the epitome of object-oriented… It’s what object-oriented was intended to be…” Now there’s a thought to conjure with, thank you for that insight.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *