From: Steve Klabnik <steve@...>
Date: 2011-04-20T19:55:49+09:00
Subject: Re: anonymous closures with Proc,new, lambda and ->

--00151747343055e6fc04a1577716
Content-Type: text/plain; charset=ISO-8859-1

I would highly reccommend Haskell, and http://learnyouahaskell.com/ .
On Apr 20, 2011 3:24 AM, "Robert Klemme" <shortcutter@googlemail.com> wrote:
> On Wed, Apr 20, 2011 at 8:03 AM, Stu <stu@rubyprogrammer.net> wrote:
>> Lots of helpful information in this thread. Thank you all for helping me.
>
> You're welcome!
>
>> Since I am new to functional programming I am slowly experimenting with
what
>> I know and building slowly from there. In the same fashion that object
>> oriented is no more than the sum of it's parts I am interested in
learning
>> as much as I can about this paradigm.
>
> In my understanding closures are not that essential for FP - at least
> not for storing data. The Wikipedia article sums the core properties
> of FP up pretty good IMHO:
>
> "[...] functional programming is a programming paradigm that treats
> computation as the evaluation of mathematical functions and avoids
> state and mutable data. It emphasizes the application of functions,
> in contrast to the imperative programming style, which emphasizes
> changes in state."
>
> http://en.wikipedia.org/wiki/Functional_programming
>
> Also a frequently seen feature is first class and higher order functions.
> http://en.wikipedia.org/wiki/Higher-order_function
> http://en.wikipedia.org/wiki/First-class_function
>
>> I understand the concept of closure. I imagine the best use for it would
be
>> to build one and embed it in another and so one( correct me if I'm wrong)
>
> That entirely depends on the use case. With currying that is
> certainly what happens.
>
>> I have read and experimented with ruby's Proc#curry method. There is a
>> tutorial online which explains haskell's monads in ruby I plan on
grokking
>> as well.
>>
>> Are there any other facets of functional programming theory I should look
at
>> to take advantage of?
>
> One interesting thing that you can take away from FP is that some
> things do get easier even in OO if you avoid side effects. For
> example concurrency has less issues if objects are immutable. Of
> course the downside is that you pay with GC overhead and frozen
> instances in some way go against the paradigm of OO because one of the
> major aspects of OO is encapsulation of state with functionality; and
> this typically means _mutable state_. But on the other hand in
> certain areas (e.g numbers and arithmetic) the concept of immutable
> state is quite common in OO languages (Ruby and Java both have it).
>
> If you really want to dive deeper into FP you should probably not use
> Ruby but rather a first class FP language. I won't recommend one
> because others know that area far better than I do. There were some
> recommendations recently:
>
>
http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-talk/380949?380902-381876
>
> You can also find a pretty neat list here:
> http://www.cs.nott.ac.uk/~gmh/faq.html
>
> Kind regards
>
> robert
>
> --
> remember.guy do |as, often| as.you_can - without end
> http://blog.rubybestpractices.com/
>

--00151747343055e6fc04a1577716--