Putting the “FUN” back in functional programming (or at least taking the “FU” out of it)
Randall Thomas kicked off the morning with a talk on Functional Programming. I have seen a number of talks on functional programming but was really looking forward to Randall’s take on it as he’s not only smart but he’s really entertaining.
The basis for functional programming was that there were a group of guys that were trying to figure out how to mathematically prove that an application was correct. This had strong basis in lambda calculus. The interesting idea here is that since the program can be mathematically proven, you can do things in a almost any order and it will still work. This means that you can
This is a big deal with systems that deal with concurrency. The reality is that any web application has to deal with concurrency. 3D video games deal with concurrency. Distributed computing, cloud computing and many of the things that we are doing on a daily basis have to deal with concurrency.
FU(Thinking) is when you start thinking functionally and solve a given problem in different way than you would have in the OO world.
Recursion is an example of this. Everyone has had to written and messed up a recursive function. The example that he used was calculating a Fibonacci sequence. In straight Ruby, the demonstration was 10-15 lines of code with a while loop, counters that were incremented and decremented and so on. The functional version of that was 4 lines with no looping,
I loved his quote “Amateurs copy, professionals steal” as he put up a demo that he borrowed from someone.
Honestly, he lost me a little on the deltas between procs and lamdas in Ruby.
He brought up the topic of Monads. When he asked the crowd who understood Monads and Jim Weirich didn’t raise his hand, I knew that we were in trouble. Then Randall admitted that he didn’t fully get Monads either. At that point, I knew that I wouldn’t get it probably ever. But he went on to say that mostly people talk about Monads in context of the obfuscated code contests and the like.
List processing is at the core of the things that we do on a day to day basis. There are three things that we do to lists every day.
- Transform everything
- Extract everything
- Combining (everything or something)
Functional programming is really good at list processing.
“iteration is the life blood of ruby – and now a word from some bad ass functional code.”
#Ruby magic – f(x) style
(1..10).reject{ |x| 0 == x%2 }.map.join(‘,’)
So what does that do? It prints out all of the odd numbers from 1 to 10. Notice that there’s no initialization, no main and so on. This is at the core of why people love Ruby. It’s an extremely expressive language.
I was partially nervous that this talk was going to be a pitch for a “Functional” language such as Haskell, Scala, F# or Clojure. But it wasn’t. It was explaining functional programming and help us bend our head around thinking like a functional programmer but accomplish what we need to do *most* of the time in Ruby.
Modeling Workflow Concepts in Ruby or (almost) Everything I Needed to Know about Workflow I learned from Schoolhouse Rock.
David Bock is a workflow consultant. He’s a great speaker and just a fun guy to hang out with.
State-Based verses Process-Based workflows is one of the core concerns in workflow camps.
State-based workflow – this is the thing that reminded David of Schoolhouse Rock. He was thinking about the example of getting a bill passed (http://www.schoolhouserock.tv/Bill.html). There are a lot of different states that a specific bill can be in at any given time. But how things progress from one state to another is the interesting bits. The states are just the points that you would tell your boss if he asked you how things are going. It’s been “Submitted”, it’s “In progress”, it’s “On order”, it’s “Completed”.
To implement a State based workflow, you can do it easily in Rails. David is also working on a project called “Stone Path”
Process-based workflow flips things on it’s head compared to the state based workflow. Or as David said, Process based workflow says that Schoolhouse Rocks was wrong. The state is not what’s an issue, what matters is who does it and how it’s done. This deals with what things can be done in parallel and more. These are things that state based models don’t deal with. There’s a fair amount more handholding and strictness to a process-based workflow engine as it really deals with the “How” of what you are doing, not just the end results.
There’s a project that deals with it well called Ruote.
If you users are novices, you need to choose process-based workflow. This will give them a lot more handholding and rules that they will have to follow.
If you users are experts, you need to choose the state based work flow. This will give them the freedom to skip around, push the boundaries, take shortcuts and anything it takes to get from one state to the next. This can be a good and a bad thing.
“Workflow” is not a tool, it’s a bunch of domain concepts that you can apply and implement yourself.
Playing Nice With Others
Jeremy Hinegardner did this talk about playing nice with other languages and data stores and the like. He talked about the idea that there are three types of persistence that are out there. None, Snapshot and Lifetime. There are times that we need one verses the other
Then he talked about a number of different tools that accomplish various bits along the path there.
Memcache – This is a memory based object caching scheme that is used heavily in a number of different languages including Ruby, Python and PHP.
Tokyo Cabinet – This is a set of libraries that cover a fair amount of ground. They can fit in either the Zero or Lifetime persistence.
Redis – “Redis is a key-value database. It is similar to memcached but the dataset is not volatile, and values can be strings, exactly like in memcached, but also lists and sets with atomic operations to push/pop elements.” – from the Redis home page.
Beanstalk – This is fast, distributed, in-memory work-queue service.
ZeroMQ – This is a memory based messaging system.
The most interesting part of the presentation to me was when Jeremy started showing how understanding what your persistence needs were and how that helped you make your decisions on which of the frameworks to pull down. For example, if you need
Lifetime persistence, you should look at Tokyo Cabinet and so on.
Building Native Mobile Apps in Rhode
The last talk of eRubycon was done by Adam Blum on writing mobile applications. The Rhodes framework is an application framework that all allows you to build applications in HTML and Ruby and deploy that application to iPhone, Windows Mobile, BlackBerry, Android and Symbian.
Their tag line is “The Open Mobile Framework”.
The architecture is that they built a small web server and Ruby implementation for each of the platforms. The framework actually loads up the HTML/CSS from the small web server and runs it in the local device’s browser control. I asked him if they ship a browser control or not and he said that they haven’t had to. Specifically he talked about the fact that Blackberry is actually the hardest to work with. They were surprised by the Windows Mobile browser. In their experience, as a browser is not fantastic compared to Webkit based browsers but as a browser control it’s actually very light and works well.
They have a public beta of RhoHub which is a deployment as a service for mobile.