Lambda calculus & functional programming - the view from Ruby

People,

I have a general understanding of lambda calculus & functional programming but I want to know how Ruby fits into this paradigm - is there a summary doc somewhere (preferably with concrete examples) - I couldn't find anything. What are the advantages/disadvantages, strengths/weaknesses etc of the approach? I am gradually getting a feel for "the Ruby way" and I thought this might help the process.

Thanks,

Phil.

···

--
Philip Rhoades

Pricom Pty Limited (ACN 003 252 275 ABN 91 003 252 275)
GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil@pricom.com.au

Philip Rhoades wrote:

People,

I have a general understanding of lambda calculus & functional programming but I want to know how Ruby fits into this paradigm - is there a summary doc somewhere (preferably with concrete examples) - I couldn't find anything. What are the advantages/disadvantages, strengths/weaknesses etc of the approach? I am gradually getting a feel for "the Ruby way" and I thought this might help the process.

Well, right off the bat, Ruby allows for global state and side effects (i.e. variables really do vary, and even constants may not be so constant), so while you *could* (I think) do strict functional programming in Ruby, you would have to be pretty deliberate about it.

And since Ruby is ostensibly a message-passing OOP, you might be fighting the language quite a bit.

On the down side, even with all that no-side-effect effort, you still won't get the benefits of a type system as found in, say, Haskell.

A strict functional style still may reduce bugs and make the code easier to reason about though.

···

--
James Britt

www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

Philip Rhoades wrote:

I have a general understanding of lambda calculus & functional programming but I want to know how Ruby fits into this paradigm - is there a summary doc somewhere (preferably with concrete examples) - I couldn't find anything. What are the advantages/disadvantages, strengths/weaknesses etc of the approach? I am gradually getting a feel for "the Ruby way" and I thought this might help the process.

I gave a presentation on this recently. Because Ruby is an object oriented language, it clashes philosophically with many things that functional programming holds dear. However, if one can live within these limitations, then there are ways to make effective use of the functional style in Ruby, such as chaining methods as if they were functions, which the Facets library (gem install facets) really helps with.

The key lesson is that you want to go with what's most readable and easiest to maintain for you and your co-workers. In my examples, I progressively went further over the edge into less natural Ruby code, till the final examples looked so weird that you'd never realistically want to write code like that, although it's nice to know that we have the option. So some of this is useful, and some isn't. :slight_smile:

Code from my presentation:
* http://www.pastie.org/224206 -- Functional one-liners with their imperative equivalents.
* http://www.pastie.org/224228 -- Reimplementation of something like UNIX "du" in three different styles, with the FunctionalInPlace being generally agreed to as being too weird.

-igal

James Britt wrote:

A strict functional style still may reduce bugs and make the code easier to reason about though.

I don't think that's ever been tested, mostly because every time someone makes a serious proposal in favor of "strict functional" programming, the naysayers jump on it and stomp it to death.

Case in point: Read John Backus' Turing lecture on functional languages, and contrast attempting to read his code with reading the Rails code. I think you'll find it's easier to reason about the Rails code than it is to reason about the examples in the Backus paper, or a long string of combinators in the SKK calculus, or maybe even Scheme code.

It all boils down to this: if somebody will pay me to write in a functional language, I'll do it. But I'm not holding my breath, nor am I seeing great numbers of "Help Wanted" ads looking for Haskell, OCaml or Erlang programmers.

M. Edward (Ed) Borasky wrote:

James Britt wrote:

A strict functional style still may reduce bugs and make the code easier to reason about though.

I don't think that's ever been tested, mostly because every time someone makes a serious proposal in favor of "strict functional" programming, the naysayers jump on it and stomp it to death.

Not sure what you mean by that, given the existence, and flourishing, of Haskell.

However, my best argument would end up being anecdotal, and largely defendant on assertions by, for lack of a better term, the "LtU Crowd".

Case in point: Read John Backus' Turing lecture on functional languages, and contrast attempting to read his code with reading the Rails code. I think you'll find it's easier to reason about the Rails code than it is to reason about the examples in the Backus paper, or a long string of combinators in the SKK calculus, or maybe even Scheme code.

I don't see that ad hoc empirical comparisons are going to make a case either way. Again, I don't have a formal proof of my claim; it's more of an evolving intuition about code, state, and side effects.

I'd be happier looking at Ruby code that minimized passing around state and used isolated metaprogramming.

It all boils down to this: if somebody will pay me to write in a functional language, I'll do it. But I'm not holding my breath, nor am I seeing great numbers of "Help Wanted" ads looking for Haskell, OCaml or Erlang programmers.

I recall when people used that same argument for knocking Ruby. No job listings, so how [good|important|useful] could it be?

:slight_smile:

···

--
James Britt

www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff