Introduction To Functional Programming with Scheme

I had the honor of presenting at CodeMash this year on Functional Programming in Scheme. Given I picked up Scheme only a few months ago, I thought it best I do an introduction. Hopefully, I will have opportunity to do more presentations on Scheme, Lisp, and Clojure.

As you can see by the slide deck, I have more than 60 slides to get through in no more than 60 minutes. The idea was a relatively fluid presentation where the slides continued to change as I spoke. I had some technical difficulties, which I admittedly did not handle as well as I could have. The audience was patient with me and we were able to cover all of the material including some Q&A within the allotted one hour.

I do hope the session was of value to those in attendance. I had to leave immediately after the presentation to make it to a ThoughtWorks event and I am not aware of a FeedBack mechanism for the speakers other than twitter activity.

Slide Deck

Code Samples
Thank you to everyone who gave me permission to use their code samples in my presentation.

The Kata in the presentation is a variation on Roy Osherove's String Calculator Kata.

You can find the Scheme Kata results presented in the slide deck on my github.

First videos of the SICP replacement course at MIT via @mfeathers
SICP in PDF (direct to pdf link)
    Another version with different formatting (direct PDF link)
    Yet another PDF version with much nicer typesetting (not direct PDF link. courtesy Kevin Taylor)
SICP in MOBI (Reflowable / resizable for the little Kindle)
UC Berkeley's Lecture Series on SICP on ITunesU (requires ITunes on Windows or Mac)

SICP SolutionsHere are some links to some (incomplete) SICP solutions.

Additional Scheme Resources

Simply Scheme: Introducing Computer Science
Practical Common Lisp
How to Design Programs
More: Systems Programming with PLT Scheme
Teach Yourself Scheme in Fixnum Days
Guide: PLT Scheme
Lecture 11: Introduction to Functional Programming and Scheme
Scheme Materails - NU PLT
An Introduction to Scheme and its Implementation - Table of Contents
Programming and Meta Programming in Scheme
Scheme lectures, mostly « programming musings
Scheme (programming language) - Wikipedia, the free encyclopedia

CodeMash 2010 Review

CodeMash was a genuine success.

There were a couple of issues with the communication of session schedules and the WiFi was problematic. But the event coordinators made sure the schedule updates were communicated quickly through the API, allowing the mobile apps we were all using to inform us of the changes. And the Kalahari resort tried to give us the best WiFi experience they could by segmenting us off on our own subnet and providing us a separate pipe from the rest of the resort guests. Hopefully they will be more prepared next year. I suspect attendance will continue to increase. If they can't support the bandwidth demand, the event may need to consider another venue. One final complaint - AT&T coverage was spotty at best, but if you have used AT&T and travelled even the slightest, you know this is common-place.

The rest of the event was fantastic. There were a number of great sessions covering a broad range of topics. Joe O'Brien did a great session on Refactoring the Programmer, Jim Weirich gave a good presentation on a fictitious source management system that had a great deal in common with git,  and Chris Smith's talk on F# was downright hilarious. These are a mere few of the many excellent sessions available this year.

The Open Space, run my Steven "Doc" List was also very successful. I personally participated in a good discussion on TDD/BDD with Functional Languages which lead to a new movement to create the Ruby Koans for F#, Scala, Clojure, Scheme, etc.

Dollar for dollar, this is the best conference I've experienced. I sincerely recommend this one to anybody interested in software development; beginner, intermediate, or advanced.

What if no one reads it?

You should favor readability

Among the books I am currently making my way through is "Exploring Computer Science with Scheme" by Oliver Grillmeyer. The publish date on this particular book is 1998. No matter how often it happens, I feel a twinge of despair for our profession when I read sound advice from a decade or more ago that has yet to be widely adopted; or worse is still hotly contested.

Grillmeyer contrasts a couple different functions that accomplish the same end. One terse, but obfuscated; One verbose, but transparent. In conclusion, Grillmeyer states, "In a tradeoff between readability and length of code, you should favor readability."

Damn straight.

Sure, you can use some Ruby-fu and get those four lines in the controller down to one. Yes, you can in-line the whole damn method call. But to what end? For what purpose? Why are you reducing the lines of code? What is your objective?

Favoring line count

I once completed the Bowling Kata in Ruby. It was approximately twenty five lines of code. It was readable. Each method had a clear and singular intent. I asked a non-developer friend to look at it and tell me what it did. It took him no more than 60 seconds to figure it out. I then told a Ruby developer about the Kata and without even looking at the code he said, "You should be able to do that in seven lines of Ruby."

So I set out to refactor the code down to seven lines. And it was an interesting exercise. I managed to get the code down to about twelve lines; I had cut the code in half. But then I stopped. The intent was no longer clear. One had to interpret the code in order to discern what was happening. My tests were a mess; I could not test behaviors in isolation.

I had sacrificed clarity at the altar of line count. And I was ashamed.

A (very brief) twitter discussion

So after reading the line from Grillmeyer, I tweeted it. Moments later, a buddy responded.

What if no one reads it?

Interesting question.

So you're working on a pet project; something that only you will ever work on. No other developer will ever see this code. And you're working on a feature where the desired behavior is so well known and immutable that you too will never, ever, under any circumstances need to change it. And the language and platform are absolutes; they too will never change - no new libraries, no change in any of your dependencies; not even a revision tick. You are certain that no one will read it; not even you.

And you can either write it in a terse manner, or a readable manner (but not both). Which is better?

Good code is efficient. Good code is testable. Good code displays an attention to detail. Good code has singular purpose and lacks duplication. Good code is expressive. Good code is written by developers who care. Good code is pleasing to read. Good Code is Clean Code.

Having worked on a system that manages over one hundred thousand purchases per day, I do not believe there are many situations which absolutely mandate performance at the cost of readability. So while I expect the argument, I believe it to be an outlier at best, if not completely fictional.

Given the definition of good code and the likelihood that what we are working on does not require obfuscated code for performance gains, there is no other possible consideration.

Code must be written for readability. If it is not; it is not good code.

Certainly, one can opt to knowingly write bad code, but I cannot comprehend the motive.

Retrospective 2009

Look back to learn, not lament

Life is full of moments; some wonderful, some tragic. Sometimes, you can't assess the quality of the moment until long after it has passed. Not until you've had the opportunity to live in the shadow of the moment and realize the true impact.

I have, for many years, believed that our lives are not governed by the events that occur, but by our chosen responses to those events.

Our inability to accurately asses the quality of a moment, whilst simultaneously being required to chose a response that will certainly alter the course of our lives forever is a fearsome proposition. Yet, however fearsome, I choose this belief every day. I choose it over the notion that all is random and I am a mote of dust blowing in the winds of fate; without cause and without choice and without effect. I choose it over the notion that all is predetermined and I am merely following a foreseen path; without choice and without effect.

With this belief, I march forward. Looking back only to learn lessons that better equip me for my next decision. There is no purpose or value to lament the past. The decisions I make right now alter my future course. And as a result, I know that decisions in the past need affect only my past.

2009 Timeline

First Quarter
  • Working at The Samara Group (subsidiary of Wayne-Dalton)
    • Parent Company is suffering and is not committed to success of TSG
    • Work situation is extremely poor; low trust, no autonomy.
    • Suspect we are being shut down
    • Feel obliged to my co-workers and employees.
    • Concerned how "failure" will look to others.
  • Losing faith in my technical/leadership abilities.
  • Negligent of personal health
    • Running very little
    • Not lifting
    • Eating habits are poor
Second Quarter
  • TSG is Closed by Parent Company
    • Laid off
    • Self-esteem very low
  • Decide not to rush into next job
  • Need to figure out what makes me happy
  • Pick up side jobs
  • Focus on Ruby and Development
  • Start working with LeanDog and Pillar on job in Detroit
  • Get calls from ThoughtWorks and several others to interview
  • Join running club and Men's group
  • Re-building my self-esteem
  • Personal Health gets attention
    • Run daily
    • Lift daily
    • Eat right
Third Quarter
  • Start at ThoughtWorks
    • Planning to stay for six months at most
    • Discussing emergent opportunities in Cleveland with LeanDog
  • Move in with my brother Rick
    • Sleeping on air mattress in his home office
  • Side Jobs get no attention
  • Start Scheme Study Group
  • Personal Health good
    • Running almost exclusively
    • Some lifting
    • Experience mild back pain
    • Ease up on strict eating habits
  • Enjoying life, but miss my family
    • ThoughtWorks pays for flights home and back so I can see family (WOW)
Fourth Quarter
  • Decide to stay with ThoughtWorks for as long as they'll have me
    • Like so many things about the company
    • Feel "at home" for first time in over a decade
  • Get (much needed) help with side projects
  • Moved into Corporate Housing
  • Personal Health Suffering
    • Back Pain is chronic
    • Running limited
    • Lift very infrequently
    • Eating habits are poor

Starfish for 2010

Do More
  • Communicate with Family and Friends
  • Show Appreciation to Others
  • Active participation in family finances
  • Work Out - run, yoga, lift
  • Study / Learn / Teach
  • Blog Posts
  • Ruby and fun languages
  • Eat Well
Do Less
  • Java
  • Side Jobs
  • Consuming Alcohol
  • Daily Journal
  • Help Wife with Career
  • Join 401k at work (saving)
  • Working long hours
  • Worrying about what others think
  • Involvement in Technical Community
  • Building Personal Brand
  • Working on relationship with Family