Lambda calculus & functional programming - the view from Ruby

[Philip Rhoades]

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: (e-mail address removed)

 

[James Britt]

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

 

[Igal Koshevoy]

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.

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

 

[M. Edward (Ed) Borasky]

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.

 

[James Britt]

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?





--
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